When we originally wrote “Regular Expressions Considered Harmful in Client-Side XSS Filters,” we did not fully understand the design of the NoScript reflected cross-site scripting (XSS) filter. Several factors contributed to this confusion, including a bug that prevented NoScript from working properly in our test environment and the fact that NoScript provides different levels of XSS protection on same-origin requests and cross-origin requests. In this post, we'll present our current understanding of the NoScript's XSS filter design and how it relates to the concepts introduced in that paper.

Mediation Point

The NoScript XSS filter mediates on the HTTP request instead of on the HTTP response. Instead of altering how the response is processed by the browser, NoScript mangles the HTTP request to remove dangerous content. For example, if the request contains a script tag, NoScript will replace the angle brackets with whitespace characters, essentially "mangling" the original request. If the server has a reflected XSS vulnerability, the server will echo the mangled script tag, which will not execute in the browser.

(click to enlarge)

Fidelity

Instead of relying only on regular expressions to detect dangerous snippets of content, NoScript uses a combination of regular expressions and the browser’s native HTML parser. When we did our testing on Mac OS X, Firefox had a bug on Mac OS X that caused NoScript to use the wrong HTML parser. In our experiments, we observed that the regular expressions alone were insufficient to provide XSS protection. However, once NoScript worked around the bug and used the correct HTML parser in NoScript 1.9.9.70, it was correctly able to identify the complex parsing examples in our test suite.

Same-Origin Exception

One disadvantage of the design of NoScript’s XSS filter is that altering the request has a higher false positive rate because the filter cannot consider the content of the response in deciding whether the user is under attack. To compensate for this increased false positive rate, NoScript has a “same-origin exception” similar to that used by Internet Explorer 8. However, the same-origin exception is not without its own risks, as discussed in the paper. Sites that allow users to post hyperlinks should be aware that these links may be used to work around the browser's reflected XSS protection. NoScript does seem to provide limited protection against very obvious attacks in same-origin links, but the <img/src> example we gave in the paper is an example of a link that is allowed in same-origin requests.

False Positives

To prevent the hyperlink injection attack we described in the paper, NoScript blocks a broader range of injections than other filters on cross-origin requests to a site. Aggressive filtering can cause false positives on sites with multiple domains, where the same-origin exception doesn't apply. For example, searching for "alert()" on eBay is mangled by NoScript and a warning is shown, even though eBay has no XSS vulnerabilities in its search box. NoScript has a user interface that power users can use to alleviate these false positives with domain whitelists.

There are other approaches for mitigating the risks of the same-origin exception that may have fewer false positives, such as decoding multiple layers of attack encoding or subjecting requests generated from pages that might contain an injection to further scrutiny. Analyzing the security of these approaches is a promising direction for future work.

“Harmful” considered harmful?

In our paper, we made an effort to describe XSSAuditor’s key design decisions, which allowed us to create a fast and effective XSS filter with few false positives and no need for a same-origin exception. We believe that XSSAuditor’s unique mediation point has a number of advantages, and we have made an effort to explain the rationale for this mediation point in the paper. However, we want to emphasize that there is nothing fundamentally impossible about overcoming the limitations of other mediation points used by regular-expression-based XSS filters. We hope that our discussion of the trade-offs will provide some background and inspiration for browser vendors and researchers who are pursuing further improvements in this space.