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

> Yes, but document.referrer of an IFRAME == parent.location and this has always been allowed.

No, that's only true if the document is the first resource loaded into
the iframe.  If the iframe was navigated, the referrer will be the
previous document.  There are plenty of open redirectors, etc. that
could be used to trick a resource that relied strictly on this kind of
check.

You're asking for is a blacklist, not a whitelist, and it relies not
just on setting blacklisted values, but on collecting cross-origin
data about the user's browsing and associating an reputation with
such.  That has never been explicitly allowed.  Referrer isn't exactly
mandatory to give to any resource, people turn it off, and I while I
see the potential security value of the information, I also see
potential for invasions of privacy that really need to be justified.

The way this is typically done is that each site that wants to embed
the resource passes its own origin as GET param, or the resource
scrapes it from the referrer header, and that value then gets
reflected into the X-Frame-Options or frame-ancestors for the returned
resource if it passes the reputation test.  That allows for arbitrary
embedding, with permission.  it would only break if a site explicitly
decides to change it's policy not to send referrers.  If they want to
do that, you can support and they can set an origin in the GET string
instead.

I think there are plenty of compatibility risks for both embedding and
navigation to setting "none" out there - but that choice should be a
resource's to make, aware of the consequences.  We're not proposing
changing the default policy to "none".

The one edge case I see here is distinguishing between
policy-generated empty referrer vs. empty referrer from bookmark or
address-bar driven navigation.  Perhaps we should set a keyword value
like "blocked" to indicate the difference for resources that need to
key off of it to set embedding policy?

On Mon, Nov 3, 2014 at 11:46 AM, Sean Snider <ssnider@yahoo-inc.com> wrote:
> 2) window.parent.location has always been disallowed from reading
> cross-origin
> Yes, but document.referrer of an IFRAME == parent.location and this has
> always been allowed.
>
> Scenario is. . .frame cannot set x-frame options, or frame-ancestors b/c it
> doesn't necessarily know all allowed
> hosts.
>
> Instead it looks at HTTP referrer/document.referrer, and what level the
> nesting occurs, and logs this information,
> and whenever that parent matches something "untrustworthy" (by monitoring
> logs pseudo-offline), take some action.
>
> In other words, you have some widget that's allowed to be embedded by "most"
> origins, so long as it's embedded
> at the right level and so long as said widget can establish "who" the origin
> is. . .
>
> Sean
>
>
> ________________________________
> From: Brad Hill <hillbrad@gmail.com>
> To: Sean Snider <ssnider@yahoo-inc.com>
> Cc: Frederik Braun <fbraun@mozilla.com>; "public-webappsec@w3.org"
> <public-webappsec@w3.org>
> Sent: Sunday, November 2, 2014 6:43 PM
>
> Subject: Re: Frame Ancestors and Referrer (Re: [webappsec] Call for
> Consensus: Stop work on Content Security Policy 1.0, transition to WG Note)
>
> Sean,
>
> I'm going to repeat Mike's request to clarify against the points he raised
> at:
>
> http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/0110.html
>
> 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?
>
> -Brad
>
>
>
> 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 23:06:26 UTC