Re: CSP: Problems with referrer and reflected-xss

Thanks again for your feedback, Brian!

On Fri, Jun 13, 2014 at 2:12 AM, Brian Smith <brian@briansmith.org> wrote:

> I suspect that this introductory text actually needs to be updated since
> CSP does more than just restrict the sources of resource loads.
>

I agree. We haven't really touched the introduction since 1.0. We should
revisit its claims, thanks for pointing this out.


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

I'd suggest that CSP is a mechanism for controlling a page's security
policy. While it's both true and fortunate that this mostly means locking
things down, I don't think we should limit the the purpose to strictly
negative actions.

As Brad noted, giving developers one box to rummage around in for "security
stuff" reduces cognitive overhead. One really long header means one spec to
read, which means that developers might actually discover that reflected
XSS protections in browsers is a thing.

If I could get HSTS and pinning and everything else ever into CSP, I would,
for that reason.


> That is, adding a CSP policy to a page should never make the page less
> safe than if the CSP policy wasn't there.
>

Let's come back to this: I'd agree that "less safe" is probably a
reasonable thing for us to avoid, but I don't believe any of the features
violate that constraint.

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

"by default" is the key term here; it's certainly possible for sites to
intentionally leak this information today. Consider Twitter, which will
direct users through `http://t.co` in order to ensure that referrer
information is included in navigations away from `https://twitter.com`.
Google, Facebook, and others do similar dances in order to control referrer
information.

I'd claim that these workaround _decrease_ overall user security. Offering
sites the ability to opt-into sharing of referrer information from a secure
origin means that Twitter and others can drop the insecure redirect for
some subset of their users. That helps everyone.

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

This would negate the use-case noted above. There are a variety of services
that intentionally wish to remove the browser's default restrictions on
referrer information leakage, and allowing them to do so without insecure
workarounds increases a user's overall security.


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

It's arguable that 'reflected-xss: allow' is safer than 'reflected-xss:
filter', which is the default in IE and Chrome.

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

Again, I very much agree with this goal, and I don't think the current set
of directives violates it.

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)