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:
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:
<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>
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.