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