Curtisk at 19:29, 4 January 2012

2012-01-04T19:29:41Z

← Older revision		Revision as of 19:29, 4 January 2012
Line 74:		Line 74:
	* granularity for blocking ?		* granularity for blocking ?
	* Implement nuclear mode, at least as an option? riccardo will have to ask jst how to do that.		* Implement nuclear mode, at least as an option? riccardo will have to ask jst how to do that.

			[[Category:SecReview\|XSSFilter]]

Curtisk: Created page with "== 2011.07.28 Items to be reviewed: == * Feature Page: XSS Filter - https://wiki.mozilla.org/Security/Features/XSS_Filter * {{bug|528661}} == Introduce Feature == === Goal of ..."

2011-07-28T20:46:34Z

Created page with "== 2011.07.28 Items to be reviewed: == * Feature Page: XSS Filter - https://wiki.mozilla.org/Security/Features/XSS_Filter * {{bug|528661}} == Introduce Feature == === Goal of ..."

New page

== 2011.07.28 Items to be reviewed: ==
* Feature Page: XSS Filter - https://wiki.mozilla.org/Security/Features/XSS_Filter
* {{bug|528661}}

== Introduce Feature ==

=== Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) ===
* to protect users from XSS
** Injection of whole inline scripts
** Injection of <script src> (with mismatched eTLD+1)
** Injection of partial scripts (like SQL injection) (Chrome doesn't do this)
*** This is the trickiest part. It requires integrating with the JS engine, getting between the tokenizer and the parser. But in Spidermonkey, the tokenizer and parser are tightly coupled.
** For now, testing with a separate tokenizer, but we don't want to ship this because it's slow and unsafe.

=== What solutions/approaches were considered other than the proposed solution? ===

=== Why was this solution chosen? ===

=== Any security threats already considered in the design and why? ===
* Escape partial injections: detecting partial injections can protect against more attacks, but attackers can use a different technique to inject JavaScript in presence of an opportunity for partial injection. Assuming that the web application is written in PHP and contains the code

<script>var username="<?$_GET["username"]?>";
do_login(username);</script>, the attacker can provide the parameter
";</script><script>xss();var a = "

to create a new script. Note that the script is not a substring of the URL, but the URL is also not a substring of the script. One solution consist in decoupling taint-inference from policy enforcement: the matching can happen on the HTML source, and the taint information can be used later when enforcing the policies on scripts. This might be problematic wrt to performance and whole script detection when the url is not parsed correctly.

* Circumvention of approximate substring matching: the effectiveness of approximate substring matching over exact string matching is debatable. Approximate matching is more robust toward unexpected sanitizations and XSS attacks not specifically written for this filter, but can be easily circumvented by attackers targeting this feature: assuming the web application transforms double quotes into single quotes, an attacker can simply use the sanitized character often to increase the distance between the parameter and the script. For exanple:

<script>""+""+""+""+""+""+""+""+...+""; xss();</script>.

Canonicalization, as employed by XSSAuditor, can solve this problem, but it can only account for a small subset of string transformations.

== Threat Brainstorming ==
* Allows an attacker to selectively break one script on a site :( But I guess you can do this by bringing the browser close to memory or recursion limits as well :(
* Interaction with HPP?
e.g.
http://server/?q=<script>&q=alert(1)&q=</script>

depending on the backend this may turn into q=<script>alert(1)</script>
it would be matched against ?q=<script>&q=alert(1)&q=</script>

=== Induced false positives ===

==== Whole scripts ====
* Allows an attacker to selectively break one inline script or event handler :(
** The script disabled might be a client-side security feature that "fails open": framebusting, clickjacking prevention, invisiblly-copying-text protection, anti-spoofing
** As more happens on the client, more security checks happen on the client
** But I guess attackers can already break scripts on other sites selectively, by bringing the browser close to memory or recursion limits as well :(
** Given that other browsers have similar filters, and we feel XSS is a bigger problem, this is a reasonable tradeoff.
** What if we exercise the "nuclear option" of disabling the entire page when one script breaks?
** Privacy?
* Possibilities for reducing induced-false-positives
** Keep track of hashes of scripts that have been seen
** Or request the same URL without the URL parameter, and see if the same script appears
** Seems expensive.
** Seems dangerous for POST, sketchy even for GET.
* interactions with the developer consloe?

==== Partial scripts ====
* extract sensitive information such as a username, CSRF token, recon
** requires a side channel (cpu use, bandwidth use, network cache)

=== Circumvention ===
* If the attacker injects "</script><script>", the URL parameter is not a substring of any script and no script is a substring of the URL parameter.
** Perhaps do taint analysis before HTML parsing, and use information from that taint analysis later while looking at the tokenizer output
Items to be reviewed:
XSS Filter - https://wiki.mozilla.org/Security/Features/XSS_Filter
https://intranet.mozilla.org/XSS_Filter

== Conclusions / Action Items ==
* need to schedule a follow-up meeing to discuss circumvention. Let's reconvene after BH+DC and after riccardo's poster at usenix (aug 11)
* Developers console ?
* granularity for blocking ?
* Implement nuclear mode, at least as an option? riccardo will have to ask jst how to do that.

Security/Reviews/xssfilter - Revision history

Curtisk at 19:29, 4 January 2012

Curtisk: Created page with "== 2011.07.28 Items to be reviewed: == * Feature Page: XSS Filter - https://wiki.mozilla.org/Security/Features/XSS_Filter * {{bug|528661}} == Introduce Feature == === Goal of ..."