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

Much appreciated that you separated this into a separate thread :P

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.

Mike you mentioned:
>> Referrer doesn't help you here; all `evil.org` needs to do is nest the frame inside a `data:` URL, and poof, you've lost your referrer.

Actually in that case, you don't lose the referrer. . . data URI, or about:blank inherit the referrer of the parent if nothing
is there (at least for document.referrer).  And also even if it didn't, you'd get a blank referrer, in which case in my example,
goodguys.org would just take action and not do anything or nuke themselves or whatever. . . 

My point is, content in an IFRAME expects to be able to know who its parent is at least to some degree, and we 
have always allowed that (on purpose or not :P).  Now I completely agree that it's a pretty 
big data leak as well. . and I do think it should be addressed, but having/allowing "none" in my opinion is only 
justifiable if there is a real reason.

I think it's fine to allow referrer to be stripped down (as in no port number, or query string, or even path),
to mitigate data-leak issues, but I'm not really understanding the reason for "none".  

I also think "origin" (as proposed in via ancestorOrigins), should be able to be read
by every frame/window. Again I think you should be able to protect the data a bit. . . and possibly
that needs to be an opt-in scenario and/or be able to be stripped down of information. I'm not so
sure though that hanging that on location is a good idea. . .I think you need a new property in window.
Only potential concern could be history monitor i guess. . .but again it's only origin. . i'm not so 
sure it's that big a deal. . . (matter of fact I can think of a lot of data that really should always
be allowed to be cross-origin, but I'll table that for another discussion :P).

I was wondering if instead of white list of URIs/origins, it might be valid to specify the level that
you are expected to be nested or allowed to be nested. . . and you could even do that with URIs as well.
Certainly there are cases where you only ever want to have your content in an IFRAME if it's a direct
child of someone else. I think we can save that for the next round of CSP though. . . 

But back to referrer. . . what's the valid use-case for "none"?  Is it really just about data-leakage?  If that's
the case, they I'd argue strongly against none, and just allow stripping down.  Rarely do hostname and scheme
contain sensitive information, and in that case. . .really the site itself should be setup differently :P
At the moment, my recommendation is to remove none from CSP 2.0 candidate. . . but let's hear the thoughts. . .


Sean




-----Original Message-----
From: Devdatta Akhawe [mailto:dev.akhawe@gmail.com] 
Sent: Friday, October 24, 2014 12:40 PM
To: Michal Zalewski
Cc: Mike West; Sean Snider; public-webappsec@w3.org
Subject: Re: Frame Ancestors and Referrer (Re: [webappsec] Call for Consensus: Stop work on Content Security Policy 1.0, transition to WG Note)

> Today, both of these get leaked a lot; giving them a browser-supported 
> way to minimize exposure sounds nice.

It is conceivable to design a system on the web where the name of the origin is also a secret you want to keep. For example, imagine a capability-based system that isolates based on whether or not you know a secret value/token. Right now, these mostly rely on tokens in the URL but no reason why they couldn't rely on these tokens in the domain name and you want to keep those secret.* That is likely far more secure since everywhere else the web security model is based on origins.

Sean is right in that this is not very common or needed today, but there is no reason not to have this option since attackers can already rely on other tricks to hide data: URIs. I view this header as giving that option to the "good folks" in a systematic manner.

cheers
Dev

* Although, the Origin header that some browsers send for all requests messes this up a bit

Received on Saturday, 25 October 2014 00:39:21 UTC