User:Mtl

2009-10-21T21:02:43Z

= Overview =

This document defines the CSRFModule, which contains the cross-site request forgery mitigations.
The CSRFModule lets web developers mitigate CSRF attacks by disabling unneeded functionality used by attackers to mount CSRF attacks.

= Dependencies =

This module depends on the [[Security/CSP/BaseModule|BaseModule]].

= Threat Model =

The CSRFModule seeks to help web developers reduce the severity of cross-site request forgery vulnerabilities in web sites. In particular, the CSRFModule is concerned with defending against an attacker with the following abilities:

*The attacker can inject a sequence of bytes into a target web page.
*The attacker can cause the user to visit the target web page.

We further assume the web developer wishes to prevent the attacker from achieving the following goals:

*The attacker causes the user's browser, upon viewing the target web page, to send fraudulent HTTP requests carrying the user's authorization credentials to a different web site.

We assume that the browser properly implements the same-origin policy and does not contain any privilege escalation vulnerabilities.

= Syntax =

The XSSModule introduces the following directives:
<pre>directive = "block-xss" / "block-eval" / "script-src"
</pre>

= Semantics =

This section describes the semantics of the directives introduced in the XSSModule.

== block-xss ==

The block-xss directive is designed to be a first line of defense against XSS attacks.  The csp-policy contains at least one block-xss directive, the directive(s) have the following effects:

#The browser MUST NOT execute inline script in the current web page, including inline script elements and inline event handles.
#The browser MUST NOT load external scripts or plug-in objects into the current web page from URLs other than "self", defined above.
#The browser MUST ignore any JavaScript or Data URLs in the current web page.

The block-xss directive blocks inline script because an XSS attacker can run JavaScript by inject script tags or inline event handlers into the target page.  The block-xss directive also blocks loading external scripts and plug-ins from other origins to prevent the XSS attacker from injecting a script tag that loads a malicious script from attacker.com. 

== block-eval ==

The block-eval directive is designed to mitigate DOM-based XSS vulnerabilities caused by indiscriminate use of eval and other eval-like features.  If the csp-policy contains at least one block-eval directive, the directive(s) have the following effects:

#The eval API MUST ignore its arguments and return undefined.
#The setTimeout and setInterval APIs MUST ignore their argument if the first argument is a string (which would otherwise be evaluated after the given delay).
#The Function constructor MUST ignore its arguments if its first argument is a string (which would otherwise by evaluated when the function is called).

The block-eval directive is not strictly necessary to mitigate reflective or stored XSS vulnerabilities.  However, some web developer might find the directive useful as a second line of defense. 

== script-src ==

The script-src directive is design give web developers more fine-grained control over from where their web page can load external script.  If the csp-policy contains at least one script-src directive, let the ''effective origin-list'' be the intersection of the set of URLs denoted by all the script-src origin lists.  The directive(s) have the following effects:

#The browser MUST NOT enforce the restrictions on loading external scripts or plug-in objects given by the block-xss directive because the script-src overrides those restrictions with a finer-grained policy.
#The browser MUST NOT load an external script into the current web page unless loading that script respects the effective origin-list.
#The browser MUST NOT load an plug-in object into the current web page unless loading that script respects the effective origin-list.

In order to mitigate XSS vulnerabilities, the script-src directive SHOULD be used in conjunction with the block-xss directive.

= Examples =

TODO: Add some examples.

= Open Issues =

This section contains a list of open issues. 

*XBL bindings.  We should disable XBL bindings for the block-xss directive, but they are a non-standard feature, so it's unclear how to write normative requirements for them.
*CSS expression.  Attackers can also embed script in CSS in IE using CSS expressions.  We should figure out how to recommend that this be disabled too.
*Strict MIME type handling for script-src.  I'm inclined to leave that for another directive ("strict-types" or some such).  The attack vector is pretty obscure.
*Password theft.  The XSSModule doesn't help with password theft because the attacker can make a fake password field.  I think we should have a separate module targeted at that issue.