[webkit-dev] Reflective XSS filter for WebKit

Adam Barth abarth at webkit.org
Sat Dec 13 14:54:29 PST 2008


I'm considering implementing a reflective XSS filter similar in scope
to the XSS filter in IE8, and I wanted to gauge interest from folks in
the WebKit community before investing a lot of time into the project.

== Background ==

Cross-site scripting (XSS) is the most common web application
vulnerability.  There are two types of XSS vulnerabilities, reflective
XSS and stored XSS.  The main difference is that the attack string in
a reflective XSS attack is immediately outputted (reflected back) by
the web site, whereas in a stored attack, the attack string is stored
in (and later retrieved from) the site's database.

Many web sites contain very simple reflective XSS vulnerabilities
along the lines of:

<h1>Hi there <?php echo GET["name"] ?></h1>

A web browser can hope to protect these sites by recognizing that a
query parameter in the HTTP request was reflected back in the HTTP
response and was executed as script.  IE8 contains such as reflective
XSS filter, which seems to be fairly effective at mitigating some
classes of vulnerabilities.

== Disadvantages ==

Implementing an XSS filter has a few disadvantages:

1) By nature, such a filter is heuristic and will have false
positives.  We can take steps to reduce the false positive rate, but
there will be some sites that break.  IE8 lets sites opt-out of the
filter via HTTP headers.  We can certainly honor these headers.

2) Because the filter mitigates only some classes of vulnerabilities,
the filter might leave site developers with a false sense of security.
 Those developers might not patch certain XSS holes because they
believe the browser will protect them (which might or might not be
true).

3) By altering the semantics of web pages, the filter might introduce
new vulnerabilities into sites.  We have some specific examples of
vulnerabilities introduced by the IE8 XSS filter, but these
vulnerabilities tend to be much less severe than the vulnerabilities
blocked by the filter.

4) The additional processing done by the filter might degrade
performance.  Without an implementation, I can't say what the
performance impact would be, but we can aim to minimize the costs.

== Conclusion ==

These disadvantages are balanced by the security benefit of
automatically protecting users from some classes of XSS
vulnerabilities.  If enough members of the WebKit community are
interested in an XSS filter, I can circulate a design doc for
comments.

Thanks,
Adam


More information about the webkit-dev mailing list