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 announcementposts 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 "><script>"â€¦ 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 --

<script>alert("XSS")<script>

-- which can be refactored and obfuscated in endless ways to obtain the "IE8 compatible" certification. Yeah, it will be great to see.

Anyway, such a feature being deployed as a built in of a popular browser, rather than as an add-on for an awesome browser, will likely keep script kiddies busy for a while, maybe taking a filter evasion crash course. I just hope it won't give some site owners an alibi not to fix their bugs, though, putting a "This site is best viewed with IE8" badge near to their McAfee Hackersafe logo.

This entry was posted on Thursday, July 3rd, 2008 at 12:03 pm and is filed under IE, XSS, Mozilla, Security, NoScript. You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.

19 Responses to “NoScript's Anti-XSS Filters Partially Ported to IE8”

[...] NoScript plugin writer Giorgio Maone posted a commentary on IE 8’s new filters, drawing compar.... Maone writes: 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. […] [...]

Personally I'm going to wait until I can get my hands on it to test it before I make claims about how it works. For all we know if it filtering all tags and all known attributes, which would go a fair way to helping solve a big part of the problem. It *is* a blacklist, but they already have that list from their own source, so it should be pretty feasible to do...

The part that I'm more concerned about is this sentence: "In performing filtering our code must not introduce new attack scenarios that would not otherwise exist. Ex: Imagine the filter can be forced to neuter a closing SCRIPT tag. In that case, untrusted content on the page might then execute as script.", since it implies that IE lets the request through and oes it's filtering on the response.

@kuza55:
yes, their description is pretty clear about this: they're filtering on the response because they check if the payload is actually echoed.
As I commented elsewhere, this is the most noticeable difference from NoScript, and while it might help reducing false positives on the rare really well behaved sites which still accept HTML tags as legitimate input on a query string, it leaves the door open for a flood of false negatives.This CNN one, for instance, will go surely undetected.

That said, after having seen your impressive presentations, I'm sure that if some side effect of their approach (or of mine) can be turned into a vulnerability, you'll be the one who finds it ;)

Yes, they're definitely not going to catch the JSON issue, they're not going to catch everything, and I wouldn't expect anyone to try to, the fact that you've had so much success with it is the exception to the rule when it comes to blacklisting/heuristics, and even you have had to issue patches.

Personally, I think that those changes are a bit too dramatic for the way web interactions work. Simply because messing around with what the server sends could get very, very messy.
I remember talking to Martin Johns who said one of his students was going to do something very similar to this for a thesis and I remember liking the idea now, but I simply assumed that it would block the page from rendering, rather than rewriting the page. All I can say is that I hope MS have thought this through well enough.

On the other hand, they claim to be working on it since 2001. Actually very early, so I guess they made something worthy for IE surfers. Would be fun to test this feature tough, I'm pretty concerned about the code rewriting but also I wonder if when they modify the code and display it, if it have some reference to certain anonymous functions internally, so that a script could listen for IE to rewrite it, and try to execute a re-written piece to gain permissions. Anyway, my mind runs wild :) But yeah, still like Kuza55 said it's best to wait and sit when they'll release the beta 2 which will be released in August this year.

Once again, Giorgio, why don't you create a separate extension for xss and other security stuff which don't need any interaction ?
I mean I'd like an extension ala Noscript but without all this clicks thing I have to do for all sites...
I'd like an extension which can catch jar flaws, xss things, all other stuff you master, and all I have to do is updating extension (no options needed). I don't want all this Noscript options. :P

ps: do you know comments section don't work if you block all third party content of the web page ? :/
Isn't it a misconception for a website like yours ? :P

@Morgan Storey:
If it used to work (it doesn't at this moment), it's because the site did double url unescaping on the _profile parameter before using it, i.e. a very unusual kind of processing.
Early NoScript anti-XSS filter versions used to perform iterative unescaping until there was nothing else to be unescaped, but this has been dropped later except for nested URLs as a speed optimization, because it was not a general use case.
I'm still not convinced this is really necessary, anyway I've restored a 2-levels deep unescaping in latest dev builds in order to cope with the very rare cases like this with a modest performance impact.

You mentioned how IE8 doesn’t protect well against any type of encoding or obfuscation in use of XSS attacks, but how exactly does NoScript do that?

NoScript uses the SpiderMonkey JavaScript engine itself to check (iteratively across multiple decoding transforms) if the request contains syntactically valid JavaScript, rather than checking against static signatures which cannot take in account obfuscation.

I’ve been looking around your FAQ’s and Features, but haven’t been able to find anything.

[...] protection, as well as omitting ClickJacking defenses and IE8's XSS filter, once pointed out as a less sophisticated alternative to the Firefox-friendly NoScript. Socially engineered malware is not the benchmark for a [...]

[...] Internet Explorer 8’s famous XSS filter can be exploited to perform successful XSS attacks against web sites which would be otherwise safe. In other words, XSS “protection” is helping XSS attackers, oh the irony. [...]