Re: Request for Change to CSP Specification


I'm not rigidly opposed to removing the SOP restriction for report-uri, but there is a case to be made for keeping it which we need to consider before we make such a change.

Comments inline...

----- Original Message -----
> From: "Jason Franklin" <>
> To: "Devdatta Akhawe" <>
> Cc:, "Daniel Veditz" <>,
> Sent: Sunday, December 11, 2011 1:13:03 PM
> Subject: Re: Request for Change to CSP Specification

> I'd like to clarify the discussion surrounding the SOP restriction on
> reports. I'm strongly in favor of removing the restriction and I've
> yet to hear a coherent argument in favor of keeping the restriction.

When the report-uri directive was first specified, there was some quite sensitive data in the violation report that would be a juicy target for an attacker, namely the request-headers field.  Though neither the WebKit or Gecko CSP implementations support this field (Gecko used to, WebKit never did), the spec still includes it in the report format:

/me makes a note to remove it from the spec.

> Since the entity developing the policy is trusted, there is no threat
> to the confidentiality of report data because by definition the policy
> will specify where reports should and should not be sent.

This is false.  The threat model we have always used when specifying this directive includes an attacker-injected policy (header injection, response splitting, injected <meta> element).  If an attacker can inject a policy that would be violated by legitimate page contents, then we want to eliminate or minimize the information that would be revealed in the violation report.

There is, for example, the blocked-uri field in the report.  We made a change to the spec to include only the origin of the blocked URI when its origin is different from that of the document.  One attack scenario that Adam pointed out would allow an attacker to steal, for example, OAuth tokens by injecting content into a page that would violate the page's policy when it redirected through an OAuth service.

You could argue that a non-same-origin violation report could similarly expose sensitive URL tokens if an application was using tokens in their internal (same-origin) URLs.  Contrived example: consider a site that uses XHR with auth tokens in the URL parameters to fetch some resource.  An attacker could inject a policy that says xhr-src 'none' and expose the auth tokens in a cross-origin violation report when the XHR is blocked by the policy.

> If the
> policy creator wants reports sent to another entity, perhaps a report
> collection or analysis service provider, they should be able to
> specify this and it makes no sense for the browser to override what
> the trusted policy creator specifies. If anyone can think of a
> reasonable adversary model and scenario where cross-origin reports
> could cause a security property to be violated, I am interested to
> hear it.

I'm pretty sure I covered that above.

> More broadly, I suspect that maintaining the SOP restriction on
> reports will slow or perhaps prevent the wide-spread adoption of CSPs
> for the following reasons:
> 1. Costs of report collection and analysis: Organizations may need to
> provision hardware, software, and humans to process the stream.

CNAMEs and VHOSTs are cheap.

> 2. One of the critical challenges for CSP violation reports is
> determining how to interpret and respond to reports. For many
> companies, this will likely require third-party experts.

I agree that there would be value in a 3rd party CSP violation report monitoring and analysis service, but there seem to be ways to work around this.  Report collection could be isolated in its own subdomain and that subdomain could be CNAMEd to a server controlled by the third party.  Of course, the application cookies would need to be properly scoped to ensure they weren't exposed during the violation reporting.  That's a non-trivial task to be certain, so I'm not actually sure how viable this "workaround" is in practice.  I'll have to think about it more.

> 3. There are substantial benefits to aggregation and sharing of
> reports to build a global view of threats.

This point seems to restate points 1 and 2.

As I said above, I could potentially be persuaded to remove this restriction, but there are risks to doing so (IOW, there's a reason we added the restriction in the first place), and I would want to make sure we mitigate those risks in whatever model we decide to go with.


> Thanks,
> Jason Franklin
> Stanford University

Received on Monday, 12 December 2011 21:01:04 UTC