W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

CSP: Problems with referrer and reflected-xss

From: Brian Smith <brian@briansmith.org>
Date: Thu, 12 Jun 2014 17:12:11 -0700
Message-ID: <CAFewVt6FzLSCxVovQC=67p1Ci1RnaYs6__KQ1f5fbCECqzz=_w@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>

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

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.


Received on Friday, 13 June 2014 00:12:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC