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

Well that's a good question. . .but my initial thought is no. . . it's not b/c I'd be very worried that without being able to know

who you are sending a message too, you have no way to protect the message (or any intrinsic state) itself. . . 





And further doing it in the query-string would generally mean that you are exposing the host URL anyway. . . 


so why then block it in the CSP policy if you are just going to turn around and give it out. . . ?




But let me take some time to gather some more thoughts about that before I formulate a full response. . .








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: Tuesday, November 4, 2014 11:54 AM
 Subject: Re: Frame Ancestors and Referrer (Re: [webappsec] Call for Consensus: Stop work on Content Security Policy 1.0, transition to WG Note)
   
> 2.) host / parent simply puts something in the URL or data that can be accessed,
>
>  a.) but that cannot be validated at all. . .


You don't have to validate it.  Parent window says in a GET parameter,
"I am example.com"  Child iframe sends post message scoped to
"example.com". (assuming it passes reputation test)

If the parent lied and is not really example.com, the browser will
deny it access to the labeled message.  Isn't that good enough?