Re: CSP: Problems with referrer and reflected-xss

On Mon, Jun 16, 2014 at 1:22 AM, Mike West <mkwst@google.com> wrote:

> On Fri, Jun 13, 2014 at 2:12 AM, Brian Smith <brian@briansmith.org> wrote:
>
>
>> 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.
>>
>
<snip>


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

As I said in my reply to Brad, I fully support documenting everything in
one place. That can be done without shoehorning every (new) feature into
Content-Security-Policy--and in fact, people are already defining new
independent security header fields like HPKP.


>
>> 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 am not arguing against providing some control over referrer handling to
websites; I've even argued repeatedly for Mozilla to increase the
prioritization of adding such features. And, I'm not even arguing against
having referrer control in CSP; I'm just arguing that CSP referrer should
be improved to be consistent with the other already-existing CSP features.


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

I agree that the the redirect tricks are not good for security. I also
agree that it is probably a net benefit to let a secure-origin page opt
into telling non-secure pages what origin linked to them. The part I
disagree with is having that opt-in mechanism be a CSP directive.

Also, your argument has some merit for websites that do the redirect trick.
But, most websites are *not* doing the redirect trick and do not care that
they're not sending a referrer to non-HTTPS pages. For them, referrer:
unsafe-url and even referrer: origin is clearly worse than the defaults.


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

No, it wouldn't negate those use cases. In fact, as far as covering use
cases, CSP referrer's current definition is much more problematic than what
I want to do, because it doesn't allow for controlling the policy at a
fine-grained enough level. When we talked to Facebook they said that a
mechanism like <a rel=originreferrer> to opt in to sharing the page's
origin on HTTPS-to-HTTP navigation would be sufficient for their needs.
(They already use Javascript to manipulate the <meta referrer> when links
are clicked to simulate that feature.) I believe the same work work for
what Twitter does. As far as Google is concerned, sharing (just) the origin
also seems sufficient for the use cases that I've seen Google share, and I
think a <a rel=originreferrer> could work for Google too.

Let's keep in mind, too, that browsers leaking information in the referrer
header can be dangerous. See
https://blog.dropbox.com/2014/05/web-vulnerability-affecting-shared-links/
and also remember why "unsafe-url" has the name it has. But, even when it
isn't dangerous, sharing the referrer information behind the user's back is
not respectful to our users, as they don't (and can't) understand it or
consent to it. I currently support relaxing the HTTPS-to-HTTP rules to
allow sharing the origin simply because websites have shown that they'll do
dangerous things to share their origin in the referrer if we don't, but I
don't support mechanisms for opting in more than that. My bet is websites
will be more willing to sacrifice some control by using <a
rel=originreferer> without redirects (better performance, better security,
able to get credited with the link, but less overall control) instead of
redirects (worse performance and worse security for being able to share
information browsers shouldn't be letting you share in the first place).

FWIW, you can read what I proposed for Firefox regarding referrer policy at
https://groups.google.com/forum/#!msg/mozilla.dev.privacy/wmPzPCdzIU8/PVcRZWhvjlwJ.
That email is a reaction to Sid Stamm's original proposal.



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

I usually argue that way, in fact. :)


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

 Again, I'm on your side regarding the need to get rid of the redirect
abuse, but for sites not doing that, "referrer: unsafe-url" is definitely
worse for their site's security than not specifying anything in the
referrer directive. And, that goes counter to how what users expect from
CSP, which hurts the usability, and it is worth fixing.

Cheers,
Brian