Re: CSP: Problems with referrer and reflected-xss

+Jochen for the referrer policy stuff below.

On Mon, Jun 16, 2014 at 12:45 PM, Brian Smith <brian@briansmith.org> wrote:

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

Let's explore this, then: do you have a suggestion for a header name that
would cogently describe the division you'd like to express?

Would you suggest that we lock the entire 'referrer' and 'reflected-xss'
directives to this new header, or only certain values of each? The latter
seems more consequent, the former more sane. :)


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

If a website doesn't care about referrer information, then it probably
won't set the directive, but will fall back on the default behavior. If we
agree that it's valuable to offer authors in general the ability to opt-in
to this behavior, it's not clear to me where the danger lies.

Also, if a website doesn't care about referrer information, but is already
setting a CSP, it's entirely possible that they'll see the new directive,
and set its value to 'none'. The overhead to adding a directive to an
existing policy is pretty low, even compared to the already-low overhead of
adding a <meta> element. Easy of integration is a pretty big advantage of
glomming new directives onto the existing header.


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

Hey, that's a great suggestion for something to add to the referrer policy
spec! Talk to Jochen (+eisinger). :)

A link attribute doesn't solve the general problem, however. An HTTP header
allows pure redirect responses to do some interesting work that wouldn't be
otherwise possible without instantiating a JavaScript environment.


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

My general feeling is that if developers are capable of doing something via
insane workarounds that use the existing platform in unintended ways that
vendors aren't willing to break, then they'll be unlikely to adopt
platform-supported features that don't offer the same capabilities.

I don't believe that origins are enough for some folks, but I've not been
involved in any concrete conversations about such requirements. Jochen
might have better anecdotes than I do regarding the 'unsafe-url' use cases.


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

I don't agree with the way you're characterizing user expectations of CSP.
I think "Content-Security-Policy:" is fairly generic, and is a reasonable
place for developers to expect to put _any_ security policy, positive or
negative.

That said, I've historically pitched CSP as a whitelisting mechanism, so
there's certainly merit to what you're saying. *shrug* I'm not 100% against
splitting directives into categories. I don't have any idea how to do that
that isn't more confusing than the current framework.

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