Security/Features/XSS Filter: Difference between revisions

Revision as of 23:29, 22 June 2011

Once you have created your Feature page, please remove this paragraph and link to your page from the Features Inbox, where a team will triage it and move it into the appropriate Feature list. If you have any questions, please contact Deb.

Feature	Status	ETA	Owner
XSS Filter	Testing feasibility.	2011-09-01	Sid Stamm

Summary

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.

Team

Who's working on this?

Feature Manager: Sid Stamm
Lead Developer: Riccardo Pelizzi
Product Manager:
QA:
Security: Curtis Koenig
Privacy: Sid Stamm

For implementation questions, ask Riccardo.

Release Requirements

Complete C++ implementation
Test the feature in the beta channel and assess its compatibility with existing websites.

Next Steps & Open Issues

What is the average overhead of the filter?
Can we do anything about induced false positives?

Related Bugs & Dependencies

Links to the feature tracking bug & other relevant bugs; links to related plans (test plan, product marketing plan, etc.); notes about things that depend on this, etc.

Risks

Identify, prioritize, track and communicate any risks associated with this feature/project.

Use Cases

Everyone loves use cases, so you should provide them if you can (and where it makes sense). The Channel Switcher Feature Page has some good examples.

Designs

Any and all mockups, design specs, tech specs, etc. Either inline or linked to.

Test Plans

Any and all test plans and strategies. Either inline or linked to.

Goals

The goal of this feature is to automatically protect users from reflected XSS attacks. The filter should have low overhead, should not rely on the user making sound decisions and should be compatible with existing websites. Moreover, the filter should not introduce new vulnerabilities in existing websites.

Non-Goals

Things we are specifically not doing or building as part of this feature.

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 a script has been provided

Other Stuff

Other XSS filters:

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.

Can include things like:

Competitive landscape
Research & references
Whatever else is useful to the project.

Legend (remove if you like)

	Healthy: feature is progressing as expected.
	Blocked: feature is currently blocked.
	At Risk: feature is at risk of missing its targeted release.
ETA	Estimated date for completion of the current feature task. Overall ETA for the feature is the product release date.

Please remove this line and any non-relevant categories below. Add whatever other categories you feel are appropriate.

@@ Line 18: / Line 18: @@
 == Summary ==
-This feature provides resistance from reflected XSS attacks -- these are the
+This feature provides protection from reflected XSS attacks -- these are the
-attacks where a malicious person inserts script into a URL, and a vulnerable
+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).  A
+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.
-filter can identify patterns in the URL and block them from being executed as
-script on the page.
 == Team ==
@@ Line 28: / Line 26: @@
 * '''Feature Manager''': Sid Stamm
-* '''Lead Developer''': Riccardo Pelizzi
+* '''Lead Developer''': [[User:Rpelizzi@mozilla.com|Riccardo Pelizzi]]
 * '''Product Manager''':
 * '''QA''':
@@ Line 34: / Line 32: @@
 * '''Privacy''': Sid Stamm
-Team list should make it clear who to ask about what, and who to ping when they're needed.  If you do not need someone in a particular role (ie: Security), that's fine, just delete that line.  Contact info for each person would also be handy.
+For implementation questions, ask Riccardo.
 == Release Requirements ==
-Complete checklist of items that need to be satisfied before we can call this feature "done".
+* Complete C++ implementation
+* Test the feature in the beta channel and assess its compatibility with existing websites.
 == Next Steps & Open Issues ==
-Either the next set of tasks that need to happen to move this project along, or (ideally) the full list of project tasks/action items with things crossed off as they're finished.  Including the name of who's responsible for each item, and a rough ETA can be useful.
+* What is the average overhead of the filter?
+* Can we do anything about induced false positives?
-Open issues include unanswered questions, things that need to be explored, decisions that still need to be made, etc.  Again, including the name of who's responsible for each item can be useful.
 == Related Bugs & Dependencies ==
@@ Line 60: / Line 58: @@
 == Goals ==
-The high level goals for the feature (which the release requirements checklist should fulfill).  These are the guiding light and overall vision for the feature.  Refer to this if there is confusion or are disputes about direction, designs, planning, etc.
+The goal of this feature is to automatically protect users from reflected XSS attacks. The filter should have low overhead, should not rely on the user making sound decisions and should be compatible with existing websites. Moreover, the filter should not introduce new vulnerabilities in existing websites.
 == Non-Goals ==
@@ Line 66: / Line 64: @@
 * 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 a script has been provided
 == Other Stuff ==
+Other XSS filters:
+* 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.
 Can include things like:
 * Competitive landscape