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

Navigation only comes into play if the IFRAME itself is navigated.  I'm not worried/considering that piece,

even though you are correct.  I guess I should have said, on 1st load of an IFRAME, document.referrer always == parent.location.

In the scenario i'm describing, navigation of the IFRAME doesn't really come into play. . .


And obviously cannot navigate the parent b/c then the IFRAME itself disappears. . .




Yes fundamentally what I'm talking about is a black list, but that's not really where I was going. . .




What I'm worried about is in terms of cross-origin/document messaging.

As I noted previously, you have an IFRAME, which can be embedded by most anyone, which acts as a widget of some sort.





The IFRAME in question cannot really set frame-ancestors to anything meaningful since we don't really

have a notion of blacklisting, and b/c the whitelist would be unmanageable.




So instead, the IFRAME in question simply checks to see the level which it's embedded (which is also why
I noted it might be a good idea to allow for the level check in CSP as an alternative or supplement to frame-ancestors).




>From there, the IFRAME looks at document.referrer / HTTP referrer, to know "who" the embedder is. . .

>From there, the IFRAME widget, now knows that it should send cross-origin messages to that "who",

rather than being forced to send "*".  Said IFRAME widget doesn't really get navigated per-se. . .(although

even if it did they could detect that case).  Since it's never navigated/always 1st load, document.referrer ALWAYS
(assuming not scrubbed) == the parent embedder, and thereby the origin for sending a postMessage can

be retrieved, and is always valid.





Now if the parent/embedder in question sets up CSP with referrer == "none", then the IFRAME has basically

no way to know at load-time, who the embedding parent is. . . therefore he cannot send postMessage to

that parent with anything other than "*".




There are then only 2 ways around that:

1.) host/parent must send a postMessage down to the IFRAME, so that the IFRAME can send messages back up.

    a.) but this means that said IFRAME has to listen to ALL potential messages, and means that they cant make
         any decisions until that happens




2.) host / parent simply puts something in the URL or data that can be accessed, 


    a.) but that cannot be validated at all. . .        





This is why I say allowing referrer to be set to "none" is bad, b/c the embeddee, has no way to protect themselves or enforce

rules about how they should be loaded or who can send them messages, or who they send messages too. . .

If the hosts and what not are hardcoded whitelists, then it works, but otherwise it doesn't. . .





Now. . the IFRAME widget could simply say "no referrer no access". . . 


As you mentioned perhaps having CSP report "blocked" would be better, since then at least the IFRAME widget knows

the difference between being blocked vs something else scrubbing the referrer.  But either way I think that could be tough

to unwind/debug.




This is why I was suggesting that we don't ever have "none".  You can strip sensitive data out of parts of the referrer (like

username/pwd, querystring, path, port, hash), but the scheme+host must always get reported so as to ensure that

this kind of communication is never broken.




Otherwise, allowing referrer to be set to "none" by some parent basically means that the IFRAME widget

can't setup validated cross-origin messaging. And since the referrer policy could have been set at any 1 level

(as in top level parent always says none, now all other IFRAMEs get none, no matter what), I can see a lot of problems

arising from that. . .





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: Monday, November 3, 2014 3:05 PM
 Subject: 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.
>>
>>
>>
>>
>>
>
>