Frame Ancestors and Referrer (Re: [webappsec] Call for Consensus: Stop work on Content Security Policy 1.0, transition to WG Note)

Forking this into a separate thread.

On Wed, Oct 22, 2014 at 11:09 PM, Sean Snider <ssnider@yahoo-inc.com> wrote:

> I've only mainly been following silently as I haven't had anything to
> bring up. . .
> But now that CSP 2.0 is advancing towards candidate recommendation, I have
> a question
> about the "referrer" directive.
>
> I'm trying to understand the valid use-case for having "referrer" set to
> "none",
> rather at least sending origin (scheme + host).
>
> I can certainly agree with not necessarily allowing a query-string to be
> seen,
> and also the port number.
>
> While the path, and host "could" have sensitive data. . . that's certainly
> not the case normally.
>

http://www.w3.org/TR/capability-urls/ are used all over the place to grant
temporary permissions. Flickr's sharing mechanism uses them, for instance
(or it did back when I worked at Yahoo! :) ).

Preventing referrer leakage in these scenarios is a great thing, and
something we should certainly support.


> Say you have a host/origin like goodguys.org, which has a URL for an HTML
> response,
> which is expected to be embedded in an IFRAME at some-level.
>

As you note, CSP's `frame-ancestors` is generally the right way to govern
how a resource may be framed.


> But then the top-level browsing context is set to evil.org, and evil.org
> has a CSP policy which says "referrer" = "none";
>

Referrer doesn't help you here; all `evil.org` needs to do is nest the
frame inside a `data:` URL, and poof, you've lost your referrer.

WebKit and Blink/Opera implement `window.location.ancestorOrigins`, which
might help you here. Firefox has (quite plausible) privacy concerns with
that API.


> goodguys.org can write script to check to see at what level their window
> has
> been embedded.  But they cannot read the URL of the parent, and only
> document.referrer /
> HTTP referrer of the request tells you that. . . how would goodguys.org
> protect
> that resources/URL from "bad parents" if it cannot always specify a
> white-list of
> frame-ancestors?  Are we saying they can't . . ?  I suppose goodguys.org
> could
> REQUIRE a referrer be set to something in their server-side processing, but
> that seems tricky. . .
>

Given cross-origin restrictions, it's not really clear what the platform
can offer you to protect your site against malicious framing other than
`X-Frame-Options` and `frame-ancestors`, which you've rejected as being
insufficient. Perhaps I simply don't understand the threat model you're
trying to protect against. Could you spell things out a little bit more
clearly?

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