Security/Features/XSS Filter

Status

XSS Filter
Stage	Definition
Status	In progress
Release target	`
Health	OK
Status note	Testing feasibility.

Team

Product manager	Sid Stamm
Directly Responsible Individual	Sid Stamm
Lead engineer	Riccardo Pelizzi
Security lead	Curtis Koenig
Privacy lead	Sid Stamm
Localization lead	`
Accessibility lead	`
QA lead	`
UX lead	`
Product marketing lead	`
Operations lead	`
Additional members	`

Open issues/risks

• [ON TRACK] 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?)

Stage 1: Definition

1. 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).

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.

2. Users & use cases

`

3. Dependencies

`

4. 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).

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.

Stage 2: Design

5. Functional specification

`

6. User experience design

`

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

Initial Security Review

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

bug 528661

Stage 5: Release

10. Landing criteria

`

Feature details

Priority	P3
Rank	999
Theme / Goal	Product Hardening
Roadmap	Security
Secondary roadmap	Platform
Feature list	Platform
Project	`
Engineering team	Security

Team status notes

	status	notes
Products	`	`
Engineering	`	`
Security	sec-review-active	Needs a 2nd review meeting Notes
Privacy	`	`
Localization	`	`
Accessibility	`	`
Quality assurance	`	`
User experience	`	`
Product marketing	`	`
Operations	`	`

• 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.