Internet Explorer 8's XSS Filter examined

Microsoft's Security Vulnerability Research & Defense team (SVRD) have recently posted information online about the Cross Site Scripting (XSS) filter to be incorporated into Internet Explorer 8 when it is released.

There are the three main conditions that the SVRD team have identified as being necessary to be met in order for the filter to be effective.

Compatibility

The filter needs to have as close to zero impact on normal content and Web traffic as possible. The reality is that there will be some level of impact as the filter is tweaked in an ongoing process to find the right balance between security and usability. Too much of an impact to basic traffic could result in the user rushing to turn the filter off as quickly as possible. Not stopping enough XSS attacks and the filter may as well not exist.

Security

Basically the SVRD team are using this approach to describe resistance to polymorphic XSS attacks. It should not be a simple matter to bypass the filter's protection through simple modification of an existing attack.

Performance

Having the filter active should not introduce too much of a performance hit to the browser, or else the user will again rush to disable it. The requirement for performance means that certain models and approaches are not going to be suitable and so some compromise needs to be met.

As with a lot of technology where there are three criteria to be satisfied, it's not going to be possible to have a product strong in all three areas without at least some compromise. Where that compromise ends up being will be seen once the filter reaches widespread usage, but the rest of the architecture post gives some hints as to where those compromises were made.

Performance requirements meant that the implementation method for the filter has moved from being a MIME filter, where it intercepted requests and responses before the rendering engine had a chance to display the content, to actually forming a part of MSHTML.

This little factoid is more important than the in-browser support itself. It means that any future application that is developed to render HTML / Web content using Microsoft's MSHTML should be able to access integrated XSS filtering (provided that Microsoft make the API for accessing it readily available).

To compare, it would be like integrating an XSS filter for Safari into the WebKit system component and making it available for all OS X applications wanting to render HTML, or into the Gecko (Mozilla family), KHTML (Konqueror and original source for WebKit), Presto (Opera, Adobe), or other HTML rendering engines.

One of the more intriguing design decisions is not to assess content that is set to be rendered as an image. Because of IE's historical issues with MIME-type sniffing and mangling, this sounds worse than it actually is. One of the changes to be introduced with IE 8 is a new way of assessing MIME-types, especially if a script is masquerading as an image file (something earlier versions of Internet Explorer, including IE 7, would have tripped up on).

Page Break

Another intriguing decision is to allow requests in the local Intranet zone to happily be made without filtering. If the filter hasn't stopped the initial request, it means that the JavaScript port scanners and network mappers that have been developed in the last 18 months will continue to have a viable means of functioning. It could be argued that stopping this is outside of the scope of a basic XSS filter, but it shows that it is possible to launch attacks against resources that might otherwise be considered in a 'safer' Internet Explorer zone from a remote site.

Yet another interesting aspect is the decision to use a combination of heuristics and signature matching to identify XSS attacks, with the heuristic methods being used to compile and add to the signature database in use. If designed correctly, it could allow users to share and modify their signature database to include defence against XSS attack methods they haven't already encountered. Microsoft could use reports from users to compile a core signature collection that is then updated with the monthly security patches, much as the Malicious Software Removal Tool is.

Microsoft's efforts are to be commended, however with reality being somewhat hostile, Internet Explorer users should not fall into the trap of thinking that the in-browser XSS filter will protect them against any and all potential issues, much as they shouldn't with the many and varied in-browser anti-phishing initiatives that are in use. This is something that is acknowledged in the SVRD post, both in terms of the type of XSS attack to be targeted (basic reflected XSS) and in terms of what will not be protected against (such as the many other XSS methods).

If you take the approach that it is a backstop against accidental user mistakes, then the filter will have a long and useful life and should form part of an integrated defence posture. To achieve this, the development team need to minimise the deviation from the desired design conditions and ensure that the filter doesn't annoy users to the point that they will willingly turn it off to regain normal browser or site performance.

If the development team can deliver a viable solution, it is something that other browser and rendering engine developers should pay attention to and consider implementing their own similar solutions.