Hi, Amit Klein from Trusteer here.


Awhile ago, David Ross from Microsoft SWI contacted me and asked me if I would like to review the new Internet Explorer 8 XSS Filter.  Does a chicken like to peck? ;-) Of course I volunteered.  My review was conducted in a rather interesting manner.  I did not have access to the filter itself. Not sure whether this was intentional or not, but it turned out well, in my opinion. Instead of banging my head against the live filter, David and I engaged in a series of discussions (mostly me asking questions and David answering them) around the filter’s architecture and algorithms. At some point David gave me the architecture overview (which is now publicly available).  Based on the information David provided, I came up with potential issues/vulnerabilities/attacks, which we then discussed, and through these discussions I learned a bit more, leading me to revise my mental model of the filter, and in turn leading to more potential attacks, and so forth. I was much impressed with the work already conducted by Microsoft around securing the XSS Filter. While the beta 2 filter is not perfect, keep in mind that the full version (in IE 8) of the filter will be based on a slightly different implementation, as well as (I hope) on the feedback gathered by Microsoft from all the individuals who reviewed the beta filter.  I do believe this will enable Microsoft to deliver a very powerful filter for the full IE 8 version.


The good

Overall, I think the XSS Filter is a great move from Microsoft in reducing the attack surface of the most prevalent XSS flavor.  And as I said, I’m impressed with the extent of work Microsoft invested in it, and the coverage of the filter. It was apparent from my discussions with David that the Microsoft folks are well versed in the current corpus of knowledge around XSS – they sure did their homework over in Redmond. Now, I’m confident that deficiencies in the filter will crop up, but think of it this way: without the filter, XSS (I’m talking type-1 only here) exploitation depends solely on the existence of the XSS vulnerability in the application.  Find it, and you’re golden.  With an IE 8 client (victim), you need to find the XSS vulnerability in the application, and hope that it will be aligned with the vulnerability in the filter. How likely is that?  Probably not too likely.  So XSS exploitability is drastically reduced.  It’s a classic 80-20-rule decision.


The bad

The XSS Filter only attempts to filter “type-1” (AKA “non-persistent”/”reflective”) XSS. It doesn’t handle “type-0” (AKA “DOM based”) XSS and “type-2” (AKA “persistent”/“stored”) XSS. I want to stress that this is clearly stated by Microsoft (‘The Internet Explorer 8 XSS Filter is intended to mitigate reflected / “Type-1” XSS vulnerabilities’). So handling type-1 XSS (only) is by design. And justly so, as type-0 and type-2 do not necessarily reflect the injected string into the response page. Handling them would have required a totally different architecture.

My fear though is that people (the slightly less technical) will read the title “XSS Filter” for what it is, and as such it will be considered a solution for all types of XSS. In turn, this may lead to frustration and misunderstanding.

In other words, my concern here is more with messaging/positioning, than in the actual performance of the filter.


The ugly

The filter can selectively deactivate client side scripting, which is a bit of a concern to me. The reference threat is a malicious site framing another (victim) site. By carefully crafting the frame URL, the attacker can deactivate some (perhaps all) script tags in the frame. This makes me a bit uncomfortable. However, David righteously commented that this “feature” already exists in a way in the form of setting the frame’s security attribute to “restricted”. So there’s no news here…



The IE 8 XSS Filter is a great step forward in web security. However, it’s not (at least currently) a conclusive solution to the XSS problem, so web developers are still advised to follow secure programming practices when coding their applications.


I truly enjoyed reviewing the filter and working with Microsoft (and particularly with David Ross) on improving it. And while we’re there - I see Microsoft’s openness and reaching out to non-Microsoft security researchers an indication of our web security community getting mature. So there’s still hope after all ;-)


Thanks for reading,