Share via

IE8 XSS Filter design philosophy in-depth

  • Article

It's great to see some positive reaction to the potential of our XSS Filter.  Now we just need to deliver!

In this blog post I’ll try to shed some light on our design philosophy.

To understand how we have arrived at our current filtering approach, it is useful to look back to the XSS Filter’s very beginnings.  Version 1.0 of the XSS Filter prototype, originally released within Microsoft back in 2002, provided users with the following (ugly!) prompt:

XSSFilter v1.0 UI

Clearly this is not something that everyday users would understand or find acceptable!  We needed to find a way to make the filtering automatic and painless and thus provide maximum benefit to users.

The approach we are taking today in Internet Explorer 8 doesn’t simply examine URL / POST data for evidence of XSS – it is capable of validating that an XSS attack has been replayed into the response.  Having identified the replayed XSS, we then have the capability to neuter the XSS on the page in a highly targeted fashion.  Thus, the XSS Filter can be effective without modifying an initial request to the server or blocking an entire response.

The detection of reflections hones our targeting as well – you can’t have “reflected XSS” without the reflection!

Our XSS Filter design goals do not equate success with blocking every conceivable attack technique.  Consider that a reported bug might fall into one of the following categories:

  1. Straightforward implementation flaws.

    Example:  A buffer overrun when a specially crafted URL is passed to the XSS Filter code.

    Any feature, the XSS Filter included, must consider this to be a severe vulnerability.

  2. Mechanisms to bypass the XSS Filter in the general sense.

    Example:  As the XSS Filter was being developed, we identified that URLs that including a %00 were processed by the XSS Filter in such a way that the %00 would decode to a null byte.  This would result in termination of the string we were using to process the URL.  A real attack could then pass through unfiltered after the null byte.

    To be successful, the XSS Filter must address any issue like this that thwarts its overall effectiveness.

  3. Mechanisms to bypass the XSS Filter’s protection for certain specific XSS attack scenarios.

    Example #1: Internet Explorer 7 will effectively ignore the high-bit of each character on a page in the US-ASCII character set.  So when a web page outputs a page in US-ASCII, or can be forced to do so, it was possible to bypass the XSS Filter by setting the high-bit on bytes in the querystring.  (This is resolved in Internet Explorer 8.)

    If we had not addressed this issue, the XSS Filter would be ineffective when the victim page used the US-ASCII character set (either by default or because it was forced).  This would be a serious limitation of the XSS Filter but ultimately it wouldn’t be a deal-breaker – for the growing majority of sites using Unicode the XSS Filter’s effectiveness would remain unchallenged.

    Example #2:  The XSS Filter would not be effective if a web app were to ROT13 decode data from the querystring before replaying it back to the client.  For attacks that depend on application-specific transformations, we will only attempt to make the XSS Filter effective where these transformations are identified to be pervasive.

    We choose not to ROT13 decode URLs.  :-)

  4. Specific new XSS attack vectors.

    Example:  The following use of data binding will result in the execution of script within IE:

    <xml id=cdcat><note><to>%26lt;span style=x:exp<![CDATA[r]]>ession(alert(3))%26gt;hello%26lt;/span%26gt;</to></note></xml><table border=%221%22 datasrc=%22%23cdcat%22><tr><td><span datafld=%22to%22 DATAFORMATAS=html></span></td></tr></table>

    Note there is no SCRIPT tag present.  There are many similar obscure script execution techniques present in all browsers.  These are often called “XSS attack vectors” and many such techniques are archived on RSnake’s cheat sheet.  The XSS Filter does handle this particular XSS attack vector.

    In the general case, we recognize the need to address additional new reflected (Type-1) XSS attack vectors as they are identified.

Observe the distinctions between the different bug categories listed above.  The most important takeaway is our level of pragmatism especially in category #3 above.  We will not be lead to compromise the XSS Filter’s web site compatibility by attempting to address every conceivable XSS attack scenario.

In summary, the XSS Filter will prove its worth by raising the bar and mitigating the types of XSS most commonly found across the web today, by default, for users of Internet Explorer 8.

Comments