18
edits
Security/Features/XSS Filter: Difference between revisions
no edit summary
(Created page with "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 in...") |
No edit summary |
||
| Line 18: | Line 18: | ||
== Summary == | == Summary == | ||
This feature provides | 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). | 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 | |||
== Team == | == Team == | ||
| Line 28: | Line 26: | ||
* '''Feature Manager''': Sid Stamm | * '''Feature Manager''': Sid Stamm | ||
* '''Lead Developer''': Riccardo Pelizzi | * '''Lead Developer''': [[User:Rpelizzi@mozilla.com|Riccardo Pelizzi]] | ||
* '''Product Manager''': | * '''Product Manager''': | ||
* '''QA''': | * '''QA''': | ||
| Line 34: | Line 32: | ||
* '''Privacy''': Sid Stamm | * '''Privacy''': Sid Stamm | ||
For implementation questions, ask Riccardo. | |||
== Release Requirements == | == Release Requirements == | ||
Complete | * Complete C++ implementation | ||
* Test the feature in the beta channel and assess its compatibility with existing websites. | |||
== Next Steps & Open Issues == | == Next Steps & Open Issues == | ||
* What is the average overhead of the filter? | |||
* Can we do anything about induced false positives? | |||
== Related Bugs & Dependencies == | == Related Bugs & Dependencies == | ||
| Line 60: | Line 58: | ||
== Goals == | == Goals == | ||
The | 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 == | == Non-Goals == | ||
| Line 66: | Line 64: | ||
* This feature will not stop persistent or injected XSS attacks (only reflected ones). | * 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 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: | Can include things like: | ||
* Competitive landscape | * Competitive landscape | ||