Chrome reflective XSS protection

Cross-site scripting (XSS) is one of the biggest problems on the web today. There are daily reports of XSS problems in various web sites and web applications (including LWN, see below). So, it is not surprising that browser makers are looking at ways to combat the problem. Previously, we looked at Mozilla's Content Security Policy (CSP), which is one approach, but the Chrome browser team has come up with something different: reflective XSS protection.

There are two basic types of XSS, persistent and reflected (or non-persistent). Persistent XSS is an attack that gets stored at the site, in a comment or some other user-generated content, that can then attack any user viewing that content. Reflected attacks, instead, have the payload stored in the HTTP request itself (as GET parameters or FORM submission values). These attacks are generally disguised and the victim is tricked into submitting them. Reflected XSS flaws well outnumber persistent flaws, so it makes some sense to concentrate on those.

The basic idea behind Chrome's reflective protection is to examine each script before it is run to see if it also exists in the request that was sent. If the page contents contain scripts that were sent in the request, it is likely that it is a reflected XSS attack. For example, if a link or form submission contains a parameter foo with the value:

    <script>alert("XSS!")</script>

It isn't quite as simple as a direct string comparison, of course, as there are any number of tricks used by XSS attacks to obfuscate their intent. By using HTML entity encodings, XSS attacks can often slip by naïve tests. Things like:

    javascript

In fact, a thread on sla.ckers.org shows various types of obfuscation that eludes the Chrome XSS filter. The participants, eventually including Chrome developer Adam Barth, keep attempting—mostly succeeding—to find ways around the filter. Those were then added to a WebKit bugzilla entry and many were fixed. Some of the more complicated cases are not yet handled.

Several comparisons to the Internet Explorer 8 XSS filter were made in the thread, generally unfavorably to Chrome's, but the Chrome filter is still relatively new. Certainly, the Chrome developers can learn from IE8's filter. Barth looked at the IE8 algorithm (by extracting it from the binary) and compared the two:

The whole thread is worth a read for anyone interested in XSS and the various tricks used by those attacks.

While the Chrome reflective protection is fairly recent, with bugs to squash and features to add, it will provide some added protection for users against XSS. It is a much simpler solutions than CSP—and doesn't require web developers to change the way they use Javascript—but it also only handles a subset of the full XSS problem. Both techniques likely have their place, but filtering reflected attacks is something that can be done more quickly than fundamentally changing the Javascript landscape as CSP requires. It seems likely that Mozilla could pick up this technique to add to its XSS protection, while still pushing CSP in the longer term. Given the "popularity" of XSS attacks, it is great to see the browser makers looking at multiple ways to reduce the risk.