Frame access

I'd actually like to propose something else for CSP next if could, but I thought I'd create a thread first(and if there already is another similar one, please someone let me know).
This idea is actually related to both of the following threads:   
   - Frame Ancestors and Referrer
   - Consider directives to manage postMessage and external navigation of iframes [CSP Next] (webappsec issue 69)   


Given the following example:
   
   - foo.com at the top level browsing context
   - 2 IFRAMES within foo.com, both with a bar.org  origin
   
   - 1 level down from top (IFRAME, parent is foo.com)
   - Lets label each frame from bar.org
   
   - bar.org-A (first frame)
   - bar.org-B (2nd frame)   


foo.com cannot access bar.org directly. . .bar.org cannot access foo.com directlyHowever, bar.org CAN access itself, so it can read / write to both IFRAMEs in foo.com.
It can find them by simply scanning the frames/window array-like collection..
Now, if foo.com listens for messages, either bar.org-A, or bar.org-B can send information,and in return bar.org-A and bar.org-B can receive messages.
However, there is currently no way to gurantee which FRAME the message REALLY came from. . . 
I say this b/c. . .
if bar.org-B does:    top.frames[0].top.postMessage("some-data", "http://foo.com");
Then the message event received in the top window, will actually be from top.frames[1] which 
is bar.org-B, and that's correct.

But. . . if both bar.org's have a function, which sends a postMessage to the top, then this changes:both bar.org's have:
function send_msg(m) { top.postMessage(m, "*"); }

Now if bar.org-B, call's bar.org-A's send_msg function, the source window will change to bar.org-A,which prevents the top level from really knowing which frame did the call.
   
top.frames[0].send_msg(m);

What's really gross about this is. . . both IFRAMEs are same origin, so even if you changedwhat the "source" property was on the message event, bar.org-B could just inject code into bar.org-Aas a way of working around the problem.
I should note in IE 8, this actually does not happen b/c postMessage is synchronous (although that's probably bad).And like I said either way, you could just inject code into the frame. . .
Sandboxing the frames also doesn't help, b/c then they both have a "null" origin, and so there is no wayto really identify the origin of the message.
Now something else I found interesting. . . in Firefox (i tested version 30 on the PC), you can set document.domain
with a port number, even if the IFRAME / document has no port number defined in it's originating URL.
so you can do, 
document.domain = location.hostname + ":[some random port number]".
Firefox allows this, and in turn doesn't expose the port number back if you were to ask for it. . . 
In turn this basically breaks same-origin access between bar.org-A and bar.org-B, even whenthe 2 frames actually do have the exact same origin.
No other browser that I can find seems to do / allow this. . . you cannot change the port to somethingelse other than what was originally defined. . . but honestly I think it's really neat b/c it provides a "light
sandbox". . . or in other words, a way to prevent access to 2 different global contexts.
I'm not sure if that behavior is really right or not. . .we can discuss it further. . .but what I'm getting at here
is that it would be nice to have not only a way to specify message channels with CSP (ensuring that messagingcomes from the proper places), but it would ALSO be nice to RESTRICT access to the global context.
Rather than going to full-on sandboxing, being able to restrict sibling access would be very nice.You could even still allow for postMessage (so long as you fix the source part :P), and location setting,and whatever. . . but said frame can define a policy that says "no-one can access me except me"would be great. . and honestly I can't even see anything it would break. . .
Sean









     From: Sean Snider <ssnider@yahoo-inc.com>
 To: Frederik Braun <fbraun@mozilla.com>; "public-webappsec@w3.org" <public-webappsec@w3.org> 
 Sent: Wednesday, October 29, 2014 9:55 AM
 Subject: Re: Frame Ancestors and Referrer (Re: [webappsec] Call for Consensus: Stop work on Content Security Policy 1.0, transition to WG Note)
   
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 knowwho / 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 blockwith 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.