|Status note||Testing feasibility.|
|Product manager||Sid Stamm|
|Directly Responsible Individual||Sid Stamm|
|Lead engineer||Riccardo Pelizzi|
|Security lead||Curtis Koenig|
|Privacy lead||Sid Stamm|
|Product marketing lead||`|
- [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
2. Users & use cases
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).
- 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
Quality Assurance review
Stage 4: Development
Stage 5: Release
10. Landing criteria
|Theme / Goal||Product Hardening|
Team status notes
|Security||sec-review-active||Needs a 2nd review meeting|
- 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.
- 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.