W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

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

From: Brad Hill <hillbrad@gmail.com>
Date: Sun, 2 Nov 2014 18:43:41 -0800
Message-ID: <CAEeYn8iZq1YCPtRTO3Tf-XGt0A8nEarUGAe96Dr2qDZk9ZGBdA@mail.gmail.com>
To: Sean Snider <ssnider@yahoo-inc.com>
Cc: Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>

 I'm going to repeat Mike's request to clarify against the points he raised at:


 In particular, the points that:

1) referrer does not reliably contain the embedding parent window's location,
2) window.parent.location has always been disallowed from reading cross-origin
3) frame-ancestors is the correct way to only allow embedding from
particular origins.

What exactly are you doing and how is it going to break?  If you are,
e.g. using referrer on the incoming request to set frame-ancestors or
X-Frame-Options on the outgoing response, and someone sets
referrer-policy to none in an attempt to do something malicious,
wouldn't the embed attempt safely fail closed?


On Wed, Oct 29, 2014 at 9:55 AM, Sean Snider <ssnider@yahoo-inc.com> wrote:
> OK let me put this another way. . .
> Why shouldn't every single frame be able to know the origin of who did the
> embedding?
> Seems to me that's reasonable, since we've ALWAYS allowed it in the past. .
> .
> Further, if someone did set referrer to none, again the HTML document in
> question has no way to know
> who / or way the embed-er is.. . and if the embed-ee wants to know that, or
> is required to know that. . .
> what are they supposed to do?
> Unless an embed-ee can require that knowledge somehow, (which he cannot
> unless we add something else to frame ancestors),
> I really feel like this is game-breaking. . .
> It's not to say that I don't believe in being able to protect the referrer,
> it's simply that we shouldn't create a 1-way block
> with absolutely no recourse. . .
> Right now the way the spec is setup, even if an embed-ee says to allow
> frame-ancestors of "foo.org", "bar.org", etc,
> but one of those sites set "referrer" to "none", the embed-ee has absolutely
> 0 way to know who did the embedding,
> even though they are trying to establish trust. . .
> Sean
> ________________________________
> From: Frederik Braun <fbraun@mozilla.com>
> To: public-webappsec@w3.org
> Sent: Monday, October 27, 2014 4:01 AM
> Subject: Re: Frame Ancestors and Referrer (Re: [webappsec] Call for
> Consensus: Stop work on Content Security Policy 1.0, transition to WG Note)
> On 25.10.2014 02:37, Sean Snider wrote:
>> Anyway. . . In my very humble opinion. . .
>> I really cannot see a "valid" use-case for "none", and I think it
>> potentially breaks things or creates nasty situations..
> I disagree. There are numerous cases for secrets in the link (aka
> capability URLs) that may want to get a greater deal of leak protection.
Received on Monday, 3 November 2014 02:44:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:42 UTC