NoScript vs. Internet Explorer 8 Filters
I’m happy to learn that IE8 is going to implement a less ambitious version of a feature which NoScript users have enjoyed
for more than one year now. The announcement posts seem not to notice the resemblances of “XSS Filter” with NoScript’s Anti-XSS Protection, the most striking being their non-blocking approach: loading the target page in a “neutralized” form and emitting a warning as an info-bar, which doesn’t require interaction and therefore doesn’t necessarily interrupt user’s workflow. But that’s fine: in facts, under the hood, their filter looks quite less sophisticated than NoScript’s InjectionChecker engine, as it is based on a limited blacklist, apparently targeted to the most common reflective XSS attack patterns as seen in proofs of concept:
The XSS Filter defends against the most common XSS attacks but it is not, and will never be, an XSS panacea. […]
The fact that our filter effectively blocks the common “>”… pattern we see most frequently in Type-1 XSS attacks is inherently a step forward. Pushing that further and blocking other common cases of reflected XSS where possible, as the XSS Filter does, is extra goodness.
Caveats aside, it will be great to see the tens of thousands of publicly disclosed Type-1 XSS vulnerabilities indexed on sites like XSSed.com simply stop working in IE8.
And there I started smiling: you realize, guys, that those listed “on sites like XSSed.com” are not “XSS vulnerabilities” which will “stop working in IE8″, but just minimal exploit test cases —
alert("XSS")— which can be refactored and obfuscated in endless ways to obtain the “IE8 compatible” certification. Yeah, it will be great to see.
Ouch. Read on.
If Giorgio is correct (and I have no reason to doubt his knowledge on the subject), the IE 8’s anti-XSS filters are seriously lacking behind the widely popular NoScript plugin which protects the Firefox browser. I agree with Giorgio, there’s so many iterations of XSS attacks that this becomes extremely difficult to stop without a great amount of effort going into the black list. Here’s a few examples of outlier cases where XSS is still possible due to difficulties finding black list matches:
- Use of alternate encodings, similar to some of the UTF-7 attacks that were seen
- Use of regular UTF-8 encodings, i.e. %3c for < (ok, this is an easy one, they should have this)
- HTML attribute injection
- If dynamic code looks like this:
- Where “USERVALUE” is controlled by the user
- Then attackers can supply an attack string like ” onfocus=alert(document.cookie)
- This results in and an XSS attack
- If dynamic code looks like this:
- Injection straight to JavaScript code
- User supplied input goes directly into javascript code. Attacker must make previous JavaScript valid, but typically requires no <, >, or ” to make the exploit happen.
This all not to mention the numerous HTML tags that can be used, including things you’d never expect, like
This brings up an interesting question… why is NoScript not just a part of the Firefox browser, not simply a plugin?
Finally, is there any protection like this for Safari? I’ll answer that for you. There’s not.
[Source: zdnet]
Post a Comment