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 <> 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.
> 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, 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, and
> has a CSP policy which says "referrer" = "none";

Referrer doesn't help you here; all `` 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.

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

Mike West <>
Google+:, 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.)

Received on Friday, 24 October 2014 09:53:09 UTC