- From: Brian Smith <brian@briansmith.org>
- Date: Thu, 12 Jun 2014 17:12:11 -0700
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAFewVt6FzLSCxVovQC=67p1Ci1RnaYs6__KQ1f5fbCECqzz=_w@mail.gmail.com>
Hi, I just recently read the proposed specification for CSP referrer at [1] and I think it is problematic for several reasons. First, let's remember what the introduction of the spec says: "This document defines Content Security Policy, a mechanism web applications can use to mitigate a broad class of content injection vulnerabilities, such as cross-site scripting (XSS). Content Security Policy is a declarative policy that lets the authors (or server administrators) of a web application inform the client about the sources from which the application expects to load resources." I suspect that this introductory text actually needs to be updated since CSP does more than just restrict the sources of resource loads. However, the intent is still clear: CSP is a mechanism for *adding* limits what the content of the page can do. In particular, I think it is dangerous to add features to CSP that cause a CSP policy to *remove* limits on what the page can do. That is, adding a CSP policy to a page should never make the page less safe than if the CSP policy wasn't there. I think this should be considered a fundamental design constraint for all CSP features, and CSP-like features that violate this constraint should be defined in a *different* header field. However, the CSP referrer mechanism defined in the CSP 1.1 draft does violate this constraint, by allowing the CSP policy to specify that more referrer information should be leaked than the browser would normally do by default. Instead of determining what the final referrer should be, the CSP referrer should instead define the *maximum* amount of information that the referrer can contain. For example, if the CSP referrer policy was "origin" then a browser would never send more than the origin in a referrer header, but it might send less (none), e.g. for HTTPS-to-HTTP navigations. Then, "unsafe-url" would never be unsafe and it could be replaced with "default" since the effect would be "no change." Similarly, "none-when-downgrade" would be equivalent to the default and so it could/should be removed. There is a similar issue for reflected-xss: allow. This shouldn't be part of the Content-Security-Policy header, but rather part of another header. Again, my point is that that the Content-Security-Policy header should only *increase* the security of a page and *never* decrease the security of the page. Otherwise, we'll soon need a Content-Security-Policy-Security-Policy header to restrict what the Content-Security-Policy header can do. [1] https://w3c.github.io/webappsec/specs/content-security-policy/#directive-referrer Cheers, Brian
Received on Friday, 13 June 2014 00:12:43 UTC