User:Mtl

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 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 rendering the target web page, to send fraudulent HTTP requests on the user's behalf.

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

Syntax

The CSRFModule introduces the following directive:

directive               = "anti-csrf"

Semantics

This section describes the semantics of the directive introduced in the CSRFModule.

anti-csrf

The anti-csrf directive is designed to be a first line of defense against CSRF attacks. If the CSP policy contains the anti-csrf directive, the directive has the following effects:

1. When the browser submits any HTTP request in context of the document with enabled CSP anti-csrf directive, where such request is classified as one of:
   1. external resource load (e.g., img src, link href, script src, iframe src, etc.),
   2. link activation,
   3. form action,

the HTTP request SHALL include Cookie request header ONLY when the requested URI is contained in the self set of URIs.

1. For all other HTTP requests in context of the document with enabled CSP anti-csrf directive, the Cookie request header SHALL NOT be included in the request.

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.

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.