Overview

This document is a "straw-man" proposal for breaking Content Security Policies into separate modules.  In particular, this document defines the XSSModule, which contains the cross-site script (XSS) mitigations.  The XSSModule lets web developers mitigate XSS attacks by disabling unneeded functionality used by attackers to mount XSS attacks.

Dependencies

This module depends on the BaseModule.

Threat Model

The XSSModule seeks to help web developers reduce the severity of cross-site scripting vulnerabilities in their web sites.  In particular, the XSSModule 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.
  
• The attacker owns and operates a malicious web site (e.g., attacker.com).

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

• The attacker must not learn the contents of the target web site's cookies.

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:

directive               = "block-xss" / "block-eval" / "script-src"

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:

1. The browser MUST NOT execute inline script in the current web page, including inline script elements and inline event handles.
2. The browser MUST NOT load external scripts or plug-in objects into the current web page from URLs other than "self", defined above.
3. 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:

1. The eval API MUST ignore its arguments and return undefined.
2. 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).
3. 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:

1. 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.
2. The browser MUST NOT load an external script into the current web page unless loading that script respects the effective origin-list.
3. 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.