Personal tools

Browse wiki

From MozillaWiki

Jump to: navigation, search
Security/Features/XSS Filter
Feature accessibility lead `  +
Feature accessibility notes `
Feature accessibility review `
Feature accessibility status `  +
Feature additional members `  +
Feature dependencies `
Feature engineering notes `
Feature engineering status `  +
Feature engineering team Security  +
Feature feature manager Sid Stamm  +
Feature functional spec `
Feature health OK  +
Feature implementation notes [https://bugzilla.mozilla.org/show_bug.cgi?id=528661 bug 528661]
Feature implementation plan `
Feature landing criteria `
Feature lead engineer Riccardo Pelizzi  +
Feature list Platform  +
Feature localization lead `  +
Feature localization notes `
Feature localization review `
Feature localization status `  +
Feature name XSS Filter  +
Feature non-goals * This feature will not stop persistent or* 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.by an input parameter and allow it to run.
Feature open issues and risks *<span style="color: grey; font-size: 8*<span style="color: grey; font-size: 80%; font-weight: bold">[ON TRACK]</span> Complete C++ implementation *<span style="color: grey; font-size: 80%; font-weight: bold">[NEW]</span> Test the feature in the Aurora channel to assess its compatibility with existing websites. *<span style="color: grey; font-size: 80%; font-weight: bold">[NEW]</span> Measure the average overhead of the filter? (Can we use telemetry to find this out?)? (Can we use telemetry to find this out?)
Feature operations lead `  +
Feature operations notes `
Feature operations review ` +
Feature operations status `  +
Feature overview This feature provides protection from reflThis 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). [[File:architecture3.png|frame|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. HTML content that is fed into the parser.
Feature priority P3  +
Feature privacy lead Sid Stamm  +
Feature privacy notes `
Feature privacy review `
Feature privacy status `  +
Feature product manager Sid Stamm  +
Feature product marketing lead `  +
Feature product marketing notes `
Feature product marketing status `  +
Feature products notes `
Feature products status `  +
Feature project `  +
Feature qa lead `  +
Feature qa notes `
Feature qa review `
Feature qa status `  +
Feature rank 999  +
Feature requirements The goal of this feature is to automaticalThe 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).ng websites (i.e. universal XSS a la IE8).
Feature roadmap Security  +
Feature secondary roadmap Platform  +
Feature security health OK  +
Feature security lead Curtis Koenig  +
Feature security notes Needs a 2nd review meeting * [[Security/Reviews/xssfilter|Notes]]
Feature security review [[Security/Reviews/xssfilter|Initial Security Review]]
Feature security status sec-review-active  +
Feature stage Definition  +
Feature status In progress  +
Feature status note Testing feasibility.
Feature theme Product Hardening  +
Feature users and use cases `
Feature ux design `
Feature ux lead `  +
Feature ux notes `
Feature ux status `  +
Feature version `  +
Categories Feature Page  +
Modification dateThis property is a special property in this wiki. 2 August 2012 22:35:56  +
hide properties that link here 
  No properties link to this page.
 

 

Enter the name of the page to start browsing from.