Security/Features/XSS Filter

Please use "Edit with form" above to edit this page.

Status

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

{{#set:Feature name=XSS Filter

|Feature stage=Definition |Feature status=In progress |Feature version=` |Feature health=OK |Feature 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	`

{{#set: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 |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature 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).

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.

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

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and 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?)

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

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 users and use cases=` |Feature dependencies=` |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 functional spec=` |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

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

{{#set:Feature priority=Unprioritized

|Feature rank=999 |Feature theme=` |Feature roadmap=Security |Feature secondary roadmap=` |Feature list=Platform |Feature project=` |Feature engineering team=` }}

Team status notes

	status	notes
Products	tbd	`
Engineering	tbd	`
Security	tbd	`
Privacy	tbd	`
Localization	tbd	`
Accessibility	tbd	`
Quality assurance	tbd	`
User experience	tbd	`
Product marketing	tbd	`
Operations	`	`

{{#set:Feature products status=tbd

|Feature products notes=` |Feature engineering status=tbd |Feature engineering notes=` |Feature security status=tbd |Feature security health=` |Feature security notes=` |Feature privacy status=tbd |Feature privacy notes=` |Feature localization status=tbd |Feature localization notes=` |Feature accessibility status=tbd |Feature accessibility notes=` |Feature qa status=tbd |Feature qa notes=` |Feature ux status=tbd |Feature ux notes=` |Feature product marketing status=tbd |Feature product marketing notes=` |Feature operations status=` |Feature operations 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.