View source for Security/Features/XSS Filter

{{FeatureStatus
|Feature name=XSS Filter
|Feature stage=Definition
|Feature status=In progress
|Feature health=OK
|Feature status note=Testing feasibility.
}}
{{FeatureTeam
|Feature product manager=Sid Stamm
|Feature feature manager=Sid Stamm
|Feature lead engineer=Riccardo Pelizzi
|Feature security lead=Curtis Koenig
|Feature privacy lead=Sid Stamm
}}
{{FeaturePageBody
|Feature open issues and risks=*{{ok|Complete C++ implementation}}
*{{new|Test the feature in the Aurora channel to assess its compatibility with existing websites.}}
*{{new|Measure the average overhead of the filter?}} (Can we use telemetry to find this out?)
|Feature overview=This feature provides protection from reflected XSS attacks -- these are the attacks where a malicious person inserts a script into a URL, and a vulnerable page reflects the contents of the URL into a page (where the script is run). If a user is tricked into visiting such URL, the attacker code runs in the domain of the page reflecting it and has therefore access to sensitive information for the domain (such as cookies). A filter can identify which portions of JavaScript code are generated from input parameters (such as the URL) and refuse to execute scripts containing such portions. Unlike its competitors, this filter attempts to account for arbitrary input transformation (using an approximate substring matching algorithm) and injection of malicious code into preexisting scripts (partial injection).

[[File:architecture3.png|frame|XSS Filter Architecture]]

The picture shows how the filter interacts with the rest of the browser: it is tightly integrated into the Mozilla framework and it is able to interpose on calls to the JavaScript engine, which happens either when (a) a <script> node or some other HTML construct is parsed by the HTML engine, (b) JavaScript evaluates strings as code (e.g. using eval or setTimeout) or (c) JavaScript uses the DOM API to generate new HTML content that is fed into the parser.
|Feature requirements=The goal of this feature is to automatically protect users from reflected XSS attacks. Characteristics:
* The filter should have low overhead. We are currently implementing it in plain C++, avoiding XPCOM overhead where possible.
* The filter should have almost no false positives (that is, it should not break existing websites in absence of an actual attack).
* The filter should not rely on user input. A false positive cannot be considered a "minor annoyance" just because the user can be shown a dialog to decide whether to actually block the script. In fact, if the filter is compatible enough, it should not be easily disabled.
* The filter should not introduce new vulnerabilities in existing websites (i.e. universal XSS a la IE8).
|Feature non-goals=* This feature will not stop persistent or injected XSS attacks (only reflected ones). 
* The filter will not be able to deal with complex string transformations employed by web applications. In this case, it will fail to recognize that the script was provided by an input parameter and allow it to run.
|Feature security review=[[Security/Reviews/xssfilter|Initial Security Review]]
|Feature implementation notes={{bug|528661}}
}}
{{FeatureInfo
|Feature priority=P3
|Feature theme=Product Hardening
|Feature roadmap=Security
|Feature secondary roadmap=Platform
|Feature list=Platform
|Feature engineering team=Security
}}
{{FeatureTeamStatus
|Feature security status=sec-review-active
|Feature security health=OK
|Feature security notes=Needs a 2nd review meeting 
* [[Security/Reviews/xssfilter|Notes]]
}}
*IE8 filter: based on regexps, it is basically a proxy (even though it lives in the browser process) that mangles scripts if they are deemed malicious. Sanitizing the attack through mangling is very dangerous, because it might affect the way the rest of the page is parsed. This made an attack possible on an earlier version of the filter. 
*NoScript XSS filter: this popular Firefox add on comes with an XSS filter. However, the extension interface does not allow developers to predicate on the content of scripts; therefore, NoScript can only detect suspicious patterns in the URL that may represent HTML or JavaScript code, without actually confirming that the maliocious code appears on the page without being properly sanitized. 
*Chrome XSS Filter: Webkit integrates an XSS filter called XSSAuditor. Unlike IE8, it is tightly integrated into the browser, interposing on calls to the JavaScript engine. This allows Chrome to easily sanitize malicious content without resorting to mangling, and improves the filter's accuracy with respect to identifying what content is interpreted as script by the browser. Moreover, it also automatically extends the protection to DOM-Based XSS attacks. Firefox's filter is based on this design.

Research References:
* Chrome XSS paper: Bates, D., Barth, A., & Jackson, C. (2010). Regular expressions considered harmful in client-side XSS filters. Proceedings of the 19th international conference on World wide web - WWW 2010 (p. 91). New York, New York, USA: ACM Press. doi: 10.1145/1772690.1772701.
* BEEP (first solution to use JS interposition): Jim, T., Swamy, N., & Hicks, M. (2007). Defeating script injection attacks with browser-enforced embedded policies. of the 16th international conference on, 601. New York, New York, USA: ACM Press. doi: 10.1145/1242572.1242654.
* Attack on IE8: Nava, E., & Lindsay, D. (2010). Abusing internet explorer 8's XSS filters. BlackHat Europe.
* Implementation of the Approximate String Matching algorithm: Sekar, R. (2009). An efficient black-box technique for defeating web application attacks. NDSS 2010.