Overview

Knowledge of CSP violations can be useful to a website owner. For e.g, reports of violations can indicate to a website owner that his site is under attack and he can take appropriate actions (especially since UAs not supporting CSP can still be vulnerable). During initial deployment reports can be immensely helpful in writing policies.

Dependencies

This module depends on the BaseModule.

Threat Model

The ReportModule is not concerned with defending against any attacker. The ReportModule is concerned about leaking confidential data outside of the protected website.

Syntax

The ReportModule introduces the following directives:

directive               = "report-uri <URI>"

The meaning of the <URI> non terminal is as defined in RFC 2396

Semantics

If a CSP contains a report-uri directive, the UA SHOULD report all CSP violations to the URI mentioned for every report-uri directive. The report will be an XML document with MIME type application/xml sent via POST to the specified URI contained in the value of this directive. Report URI must be from the scheme and port as the protected content, and the public suffix and most general DNS label of the protected content and the report URI must match, ETLD+1 style. For example www.foo.co.uk and reports.foo.co.uk, but not reports.bar.co.uk. Relative URIs are acceptable, and are resolved within the same scheme, host and port as the document served with the CSP. Report URIs that don't match the ETLD+1 requirements will not be sent reports and one error will be logged to an error console. In case of multiple Report URIs, no URI will be sent reports and an error is logged to the console. CSP enforcement will continue as if the report URI were not specified. HTTP 3xx response codes are not honored by the user agent. No redirection from the Report URI is allowed to prevent HTTP header leakage across domains. The format of the report is detailed below.

Violation Report Syntax

CSP supports a reporting mechanism that allows browsers to notify content providers when their policy is violated. When a report-uri is provided and a policy is violated, information about the protected resource and the violating content is transmitted to the report-uri via HTTP POST if available in the employed scheme, otherwise an appropriate "submit" method is used. The user agent must not honor redirection responses. Such a report is an XML document containing the following fields:

request 

HTTP request line of the resource whose policy is violated (including method, resource, path, HTTP version)

request-headers 

HTTP request headers sent with the request (above) for the CSP-Protected content

blocked-uri 

URI of the resource that was blocked from loading due to a violation in policy

violated-directive 

The directive that was violated (e.g., "script-src *.mozilla.org").

original-policy 

The original policy as served in the X-Content-Security-Policy HTTP header (or if there were multiple headers, a comma separated list of the policies)

NOTE: in the case where a protected resource is not rendered ( e.g the frame-ancestors directive was violated), blocked-uri is not sent and is assumed to be the same as the request URI. The reason for this is because this situation is different from other policy violations: no third-party content was blocked, rather the protected content elected not to load since it does not trust the sites that have enframed it.

Violation Report XML Schema:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="csp-report">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="request" type="string" use="required" />
        <xs:element name="request-headers" type="string" />
        <xs:element name="blocked-uri" type="string" />
        <xs:element name="violated-directive" type="string" use="required" />
        <xs:element name="original-policy" type="string" use="required" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

The MIME type of the transmitted report will be set to application/xml.

Violation Report Sample

In this example, a page located at http://example.com/index.html was requested using HTTP 1.1 via the GET method. It provided a policy that included the directive "img-src self", which was violated by a request for http://evil.com/some_image.png. The sample XML data sent to the policy-specified report-uri follows.

<csp-report>
  <request>GET /index.html HTTP/1.1</request>
  <request-headers><![CDATA[
           Host: example.com
           User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061015 Firefox/3.0
           Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
           Accept-Language: en-us,en;q=0.5
           Accept-Encoding: gzip,deflate
           Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
           Keep-Alive: 300
           Connection: keep-alive
  ]]></request-headers>
  <blocked-uri>http://evil.com/some_image.png</blocked-uri>
  <violated-directive>img-src self</violated-directive>
  <original-policy>allow none; img-src *, allow self; img-src self</original-policy>
</csp-report>

Open Issues

• Should we require sending reports for blocks by frame-ancestors and similar ?
• What is the threat model for the attacker here?
• What to do if multiple report-uris present ? I am in favour of sending a report to each .