IE8 XSS filter: what does it really do?

Question

Internet Explorer 8 has a new security feature, an XSS filter that tries to intercept cross-site scripting attempts. It\'s described this way:

The

Answer 1

What does it really do? It allows third parties to link to a messed-up version of your site.

It kicks in when [a few conditions are met and] it sees a string in the query submission that also exists verbatim in the page, and which it thinks might be dangerous.

It assumes that if <script>something()</script> exists in both the query string and the page code, then it must be because your server-side script is insecure and reflected that string straight back out as markup without escaping.

But of course apart from the fact that's it's a perfectly valid query someone might have typed that matches by coincidence, it's also just as possible that they match because someone looked at the page and deliberately copied part of it out. For example:

http://www.bing.com/search?q=%3Cscript+type%3D%22text%2Fjavascript%22%3E

Follow that in IE8 and I've successfully sabotaged your Bing page so it'll give script errors, and the pop-out result bits won't work. Essentially it gives an attacker whose link is being followed license to pick out and disable parts of the page he doesn't like — and that might even include other security-related measures like framebuster scripts.

What does IE8 consider ‘potentially dangerous’? A lot more and a lot stranger things than just this script tag. eg. What's more, it appears to match against a set of ‘dangerous’ templates using a text pattern system (presumably regex), instead of any kind of HTML parser like the one that will eventually parse the page itself. Yes, use IE8 and your browser is pařṣinͅg HT̈́͜ML w̧̼̜it̏̔h ͙r̿e̴̬g̉̆e͎x͍͔̑̃̽̚.

‘XSS protection’ by looking at the strings in the query is utterly bogus. It can't be ‘fixed’; the very concept is intrinsically flawed. Apart from the problem of stepping in when it's not wanted, it can't ever really protect you from anything but the most basic attacks — and the attackers will surely workaround such blocks as IE8 becomes more widely used. If you've been forgetting to escape your HTML output correctly you'll still be vulnerable; all XSS “protection” has to offer you is a false sense of security. Unfortunately Microsoft seem to like this false sense of security; there is similar XSS “protection” in ASP.NET too, on the server side.

So if you've got a clue about webapp authoring and you've been properly escaping output to HTML like a good boy, it's definitely a good idea to disable this unwanted, unworkable, wrong-headed intrusion by outputting the header:

X-XSS-Protection: 0

in your HTTP responses. (And using ValidateRequest="false" in your pages if you're using ASP.NET.)

For everyone else, who still slings strings together in PHP without taking care to encode properly... well you might as well leave it on. Don't expect it to actually protect your users, but your site is already broken, so who cares if it breaks a little more, right?

To see it in action, visit an AOL Food page and click the "Print" icon just above the story.

Ah yes, I can see this breaking in IE8. Not immediately obvious where IE has made the hack to the content that's stopped it executing though... the only cross-domain request I can see that's a candidate for the XSS filter is this one to http://h30405.www3.hp.com/print/start:

POST /print/start HTTP/1.1
Host: h30405.www3.hp.com
Referer: http://recipe.aol.com/recipe/oatmeal-butter-cookies/142275?

csrfmiddlewaretoken=undefined&characterset=utf-8&location=http%253A%2F%2Frecipe.aol.com%2Frecipe%2Foatmeal-butter-cookies%2F142275&template=recipe&blocks=Dd%3Do%7Efsp%7E%7B%3D%25%3F%3D%3C%28%2B.%2F%2C%28%3D3%3F%3D%7Dsp%7Ct@kfoz%3D%25%3F%3D%7E%7C%7Czqk%7Cpspm%3Db3%3Fd%3Do%7Efsp%7E%7B%3D%25%3F%3D%3C%7D%2F%27%2B%2C.%3D3%3F%3D%7Dsp%7Ct@kfoz%3D%25%3F%3D%7E%7C%7Czqk...

that blocks parameter continues with pages more gibberish. Presumably there is something there that (by coincidence?) is reflected in the returned HTML and triggers one of IE8's messed up ideas of what an XSS exploit looks like.

To fix this, HP need to make the server at h30405.www3.hp.com include the X-XSS-Protection: 0 header.

Answer 2

Actually, it's worse than might seem. The XSS filter can make safe sites unsafe. Read here: http://www.h-online.com/security/news/item/Security-feature-of-Internet-Explorer-8-unsafe-868837.html

From that article:

However, Google disables IE's XSS filter by sending the X-XSS-Protection: 0 header, which makes it immune.

I don't know enough about your site to judge if this may be a solution, but you can probably try. More in depth, technical discussion of the filter, and how to disable it is here: http://michael-coates.blogspot.com/2009/11/ie8-xss-filter-bug.html

Answer 3

You should send me (ericlaw@microsoft) a network capture (www.fiddlercap.com) of the scenario you think is incorrect.

The XSS filter works as follows:

1. Is XSSFILTER enabled for this process?
   If yes– proceed to next check If no – bypass XSS Filter and continue loading
2. Is a "document" load (like a frame, not a subdownload)? If yes– proceed to next check If no – bypass XSS Filter and continue loading
3. Is it a HTTP/HTTPS request? If yes– proceed to next check If no – bypass XSS Filter and continue loading
4. Does RESPONSE contain x-xss-protection header? Yes: Value = 1: XSS Filter Enabled (no urlaction check) Value = 0: XSS Filter Disabled (no urlaction check) No: proceed to next check
5. Is the site loading in a Zone where URLAction enables XSS filtering? (By default: Internet, Trusted, Restricted) If yes– proceed to next check If no – bypass XSS Filter and continue loading
6. Is a cross site Request? (Referrer header: Does the final (post-redirect) fully-qualified domain name in the HTTP request referrer header match the fully-qualified domain name of the URL being retrieved?) If yes – bypass XSS Filter and continue loading If no – then the URL in the request should be neutered.
7. Does the heuristic indicate of the RESPONSE data came from unsafe REQUEST DATA? If yes – modify the response.

Now, the exact details of #7 are quite complicated, but basically, you can imagine that IE does a match of request data (URL/Post Body) to response data (script bodies) and if they match, then the response data will be modified.

In your site's case, you'll want to look at the body of the POST to http://h30405.www3.hp.com/print/start and the corresponding response.