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 “><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.

Final thought: echoing the news on his blog, RSnake did swiftly mention NoScript (thanks), but at the end of that post, calling for adoption of his own bright Content Restrictions idea, he forgot to say that one (experimental) implementation already exists… Do these cross-site scripting filters suppress legitimate cross-site references as well? ;)

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

  1. #1 Zero Day mobile edition says:

    […] 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. […] […]

  2. #2 remy says:

    the ie team never get his own ideas :D

  3. #3 kuza55 says:

    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.

  4. #4 Giorgio says:

    @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 ;)

  5. #5 kuza55 says:

    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.

  6. #6 Zach says:

    I think having at least some basic XSS filtering included by default is a fantastic development for browsers. Any chance a subset of NoScript’s features will be included in Firefox 3.x by default?

  7. #7 rvdh says:

    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.

  8. #8 pirlouy says:

    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

  9. #9 dIRTYbRAIN v3 –> MCCCXXXVII powered » Preview: IE8-Sicherheit says:

    […] des XSS-Filters. Zwar wird der Filter die Skript-Kiddies eine Zeit lang beschäftigen. Für Giorgio Maone, Programmierer der Firefox-Erweiterung NoScript, ist es dennoch nur eine Frage der Zeit bis sie den […]

  10. #10 Gökhan Onar ‘ın Blogu » Yeni Microsoft tarayıcısı ne kadar güvenli olacak? says:

    […] saldırganları uzun bir süre uğraştıracaktır. Firefox eklentisi NoScript’i programlayan Giorgio Maone için bu korumanın devre dışı bırakılması an meselesi. Geriye ise zekice gizlenmiş […]

  11. #11 hackademix.net » Heart Touching Thingies says:

    […] face to face in the romantic and adventurous land of Whistler? I guess it’s destiny, even Steve Ballmer had been too shy to declare his love […]

  12. #12 Morgan Storey says:

    I found an XSS that runs even though noscript is installed.
    http://www.citibank.com/domain/contact/index.htm?_u=visitor&_uid=&_profile=%2522%2522%253e%253cimg src=%2522%2522 onerror=%2522alert(1)%2522
    care of http://www.hiredhacker.com/2008/10/31/citibank-xss/

  13. #13 Giorgio says:

    @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.

  14. #14 hackademix.net » Ehy IE8, I Can Has Some Clickjacking Protection? says:

    […] aside, forgiving Microsoft’s habit of forgetting precursors of their “first and unique” technologies, what can we infer from the “few […]

  15. #15 Miles says:

    I like your analysis of IE8, but I have a question. 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?

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

    Thanks.

  16. #16 hackademix.net » Paypal XSS, an IE Exclusive! says:

    […] Microsoft unveiled its IE 8’s “XSS filters”, almost one year ago, we could notice how, despite their impressive resemblance to NoScript’s […]

  17. #17 Giorgio says:

    @Miles:

    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.

    You can look at the source code ;)

  18. #18 Zero Day mobile edition says:

    […] 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 […]

  19. #19 hackademix.net » IE's XSS Filter Creates XSS Vulnerabilities says:

    […] 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. […]

Bad Behavior has blocked 35762 access attempts in the last 7 days.