18
edits
Security/Features/XSS Filter: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 41: | Line 41: | ||
*What is the average overhead of the filter? | *What is the average overhead of the filter? | ||
*Can we do anything about induced false positives? | *Can we do anything about induced false positives? | ||
<!-- | <!-- | ||
== Related Bugs & Dependencies == | == Related Bugs & Dependencies == | ||
| Line 63: | Line 62: | ||
Any and all test plans and strategies. Either inline or linked to. | Any and all test plans and strategies. Either inline or linked to. | ||
--> | --> | ||
== Goals == | == 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 | 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 calls where possible. | |||
* The filter should have zero false positives (that is, it should not break existing websites in absence of an 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 == | == Non-Goals == | ||