As you probably know, the details about the paradoxical behavior of the Internet Explorer XSS Filter, introducing XSS vulnerabilities of its own on otherwise immune web sites, which we hinted at some months ago, have been revealed by Edoardo “Sirdarckcat” Vela and David “thornmaker” Lindsay recently at the Black Hat Europe conference, in Barcelona (on a side note, looks like Sirdarckcat enjoyed his stay there so much that he decided to remotely hack a certain volcano…)
I’ve been quite disappointed by the preamble of their paper, which calls IE8’s XSS filter
a new type of defense and a
somewhat novel approach (before bashing it), when we all know that NoScript came first. Sirdarckcat personally apologized, blaming Lindsay for this and other “pro-big-players” bias, such as the decision of omitting, from the comparative table in their slides, Sirdarckcat’s opinion about NoScript’s being the safest among the in-browser filters and the hardest to bypass.
Notwithstanding, the technical core of this research is very worth reading, if you’re interested in XSS attack and defense techniques.
After the Black Hat debacle got echoes in the press, David Ross, the main XSS Filter engineer at Microsoft, published a Guidance on Internet Explorer XSS Filter document on the Microsoft Security Response Center website, announcing a not better specified “patch” coming in June (mmm, two whole months? need some help?) and making two interesting statements:
In the case of the Internet Explorer XSS Filter, researchers found scenarios that are generally applicable across XSS filtering technologies in all currently shipping browsers with this technology built-in.
This essentially means just two, IE8 and Chrome… but wait, Chrome doesn’t ship with its XSS Auditor enabled anymore because it was dog slow!
Hence the final recommendation by Ross…
Overall we maintain that it’s important to use a browser with an XSS Filter
… can really mean one thing only:
Microsoft maintains that it’s important to use Firefox with NoScript :)