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:
|
http://[server]/[path]/[file].asp?id=70-305zzz<script>alert();</script> |
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:
|
http://[server]/[path]/[file].asp?id=70-305zzz+"+style="background-position-x:expression\0028\0065\0076\0061\006C\0028\0061\006C\0065\0072\0074\0028\0027pwn3d\0027\0029\0029\0029 |
This variation makes use Internet Explorer's support for Dynamic Properties. The character sequence at the end of the URL is an encoded block of Javascript. While the validation put into place at the server prevents an element from being closed off with a greater-than symbol, it does not prevent the addition of a new STYLE attribute on the element which can contain a Dynamic Property that Internet Explorer will then execute.
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.
In Internet Explorer 7, an effort was made to reduce vulnerabilities involving the use of the special “javascript:” and “vbscript:” URL syntax. Specifically, these URLs were disabled in some contexts. This actually wasn’t intended to mitigate XSS per-se, but it was in fact an effective instance of XSS-Focused Attack Surface Reduction. This is because the use of javascript:/vbscript: URLs in unusual places such as IMG or EMBED tags often enabled XSS where it wouldn’t otherwise be possible. It was great to see that after we released IE7, RSnake noticed the change and updated his cheat sheet.
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
