Sunday, July 19, 2009

IE 8 Anti-XSS A Bit Overblown

IE 8's anti-xss filters may help protect users. However, its pretty strict and catches all sorts of random things. It looks like it functions on GETs only - POSTS are excluded. Based on this it would protect users against reflected XSS issues only. Any sort of stored XSS would not be mitigated by this browser control.

Here is an interesting look at some of the false positives:

Firing on just "<script>" in the url
Google: Search for <script> using the normal website. It will work.
But try going directly to the URL
IE 8 XSS filter kicks in.

Here are a few more
Firing on javascript:alert(document.cookie)
Ok, maybe its looking for any sort of javascript in the URL. Even though no real attacker would just pop-up a message box with the cookie.

Firing on javascript:a
Hmm, seems like it fires on "javascript:" followed by anything.

Firing on ";alert(123);
Maybe this is someone looking for an xss issue, but that is stretching it. Again, no real attack would use this.";alert(123);

Firing on ";abc(123);
Oh, nevermind, the far reaching filter fires on any JavaScript looking method following "; Doesn't matter if it actually exists or not.";abc(123);

So it looks to me that the xss filter is firing pretty liberally. The problem will begin when more people adopt IE 8 and websites start to see this filter breaking legitimate functionality. At that point the websites will begin disabling the xss filter by adding the following response header.

X-XSS-Protection: 0

That's right. The website has the ability to disable security controls setup in your browser. Seems a little bit of an odd model right? So don't go and rely on this control for your security. If you want to take action to protect yourself then I recommend Mozilla and noScript plugin.

Also, if you are conducting security reviews and need to use IE 8 then check out this post on automatically disabling IE 8 xss with WebScarab's bean shell.

-Michael Coates


  1. Hi Michael,

    We've been burned by this as well.
    As for the script in the URL, wasn't there some vulnerability which caused IE to crash on this before?

    "That's right. The website has the ability to disable security controls setup in your browser. Seems a little bit of an odd model right? So don't go and rely on this control for your security."

    This made my day and it does show Microsoft's view on security. It's something to pay lip service to, but also to chuck overboard if it gets in the way of doing things the simple way.

  2. Did you have troubles with IE8 when testing an app? Or where you working on an app from the development side and IE8 was throwing false positives with the XSS filter and preventing normal app functionality?

    I'm not sure about the vulnerability. I did a quick search and found some info about a particular script within the page which would crash IE, but nothing about the URL.

    I agree with your last point. If it gets in the way, get rid of it. Clearly we need to address security issues, but there are better ways.

  3. Michael, I have written about the design philosophy of the filter here:, and the architecture here: We've tried to be as upfront as possible about the limitations of our approach. What you're observing here really falls in line with our pragmatic philosophy.

    Essentially the XSS Filter strives to mitigate reflected XSS, by default, for users of Internet Explorer. We optimized our approach to be as effective as possible, bounded by the limits of performance and compatibility. Ignoring these very real constraints, for example by not allowing well-authored sites to opt-out of filtering, would ultimately not allow us to achieve our goals.

    FWIW, we do cover XSS on POST.

    If you have any feedback or questions on the filter, feel free to contact me here:

  4. David,

    Thanks for the comment, I will have to review those links further. I've found that the above examples, when submitted as post variables, do not trigger the IE8 xss filters. I'm not necessarily saying they should, but I'll have to investigate further to understand how the filter works on POST.

    Ultimately, there are 2 main points I'd like to make on the xss filter.

    1. The success of the filter will be its false positive rate. If this gets too high, many sites will disable it by adding the response header.

    2. Applications must not rely on the browser to eliminate XSS. They need to fix these issues in the app.

  5. Michael, I absolutely agree on both points! Regarding #1, fortunately the sites most likely to leave reflected XSS unaddressed are also the sites least likely to go out of their way to disable the filter.

  6. This stupid filter just broke one of my ajax apps that submits to hidden iframe which returns xml of content type text/xml.

    From what I can tell ie8 ignores the header to disable the xss protection.

  7. How to use in asp to by pass XSS setting in IE8?

  8. interesting. caught this one today:') ()

    can you find a shorter one?


Note: Only a member of this blog may post a comment.