Re: CSP: Problems with referrer and reflected-xss

+1


On Thu, Jun 12, 2014 at 6:12 PM, Brian Smith <brian@briansmith.org> wrote:

> 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
>
>