All web browsers expose what have been referred to as XSS “attack vectors” – various techniques that XSS attacks can leverage to achieve script execution. The best and most well regarded list of these behaviors is RSnake’s XSS Cheat Sheet.
The existence of these attack vectors can at minimum present a challenge to filters and other technologies which attempt to block XSS. But more fundamentally, XSS attack vectors enable XSS bugs that would not otherwise exist. This is the essential argument for what I term XSS-Focused Attack Surface Reduction.
Let’s explore one example.
Finding a useful reflected XSS bug usually involves identifying a server that will replay data from a URL which is then interpreted by the browser as script. Often constraints are placed on how the attack must be constructed. This can result from ineffective filtering that has been put in place or simply due to incidental non-security related filtering at the server.
Here is a simple example attack URL:
The script element in the URL is injected into the server’s HTTP response as valid HTML. This vulnerability was addressed with server-side validation. However, the following variation was later identified, demonstrating the validation to be insufficient:
The idea of XSS-Focused Attack Surface Reduction is that we can view each instance of XSS as having been enabled by one of a finite number of XSS attack vectors existing in the browser. Then we can look at ways to regulate each of those vectors in order to reduce the browser’s susceptibility to XSS.
In this example above, the vector is a behavior exposed by the Dynamic Properties feature. The Dynamic Properties feature provides real value as a feature in the browser, so it’s difficult to perform XSS-Focused Attack Surface Reduction without serious compatibility impact. It’s something we have been looking at closely though.
Fortunately, it turns out that in many cases XSS attack vectors are incidental behavior unlikely to be put to use by legitimate web content. In these cases, XSS-Focused Attack Surface Reduction becomes much more feasible.
Essentially, the change described above translates to one less tool available in the XSS exploit author’s toolbox. This is what XSS-Focused Attack Surface Reduction strives to achieve.
I’m happy to report that IE8 is delivering additional XSS-Focused Attack Surface Reduction goodness. For Beta 1 you will notice a small but notable step forward – the US-ASCII XSS attack vector has now been closed. RSnake, feel free to update your cheat sheet once again. J