Re: Frame access

Sean,

 I don't think that we're going to try to define policies that restrict interactions between resources that are same-origin.  There just is no firm isolation mechanism – pretending the frames are meaningfully different security principals isn't sustainable.

However, the suborigins proposal Joel Weinberger is working on, and which we are considering as part of rechartering, could help here:

http://www.chromium.org/developers/design-documents/per-page-suborigins

In this way, the resource in each frame could opt-in to a stable sub-origin that was uniquely addressable by origin-aware APIs like postMessage, and they would behave as fully independent security principals.

-Brad

From: Sean Snider <ssnider@yahoo-inc.com<mailto:ssnider@yahoo-inc.com>>
Reply-To: Sean Snider <ssnider@yahoo-inc.com<mailto:ssnider@yahoo-inc.com>>
Date: Wednesday, October 29, 2014 at 9:59 AM
To: Sean Snider <ssnider@yahoo-inc.com<mailto:ssnider@yahoo-inc.com>>, Frederik Braun <fbraun@mozilla.com<mailto:fbraun@mozilla.com>>, "public-webappsec@w3.org<mailto:public-webappsec@w3.org>" <public-webappsec@w3.org<mailto:public-webappsec@w3.org>>
Subject: Frame access
Resent-From: <public-webappsec@w3.org<mailto:public-webappsec@w3.org>>
Resent-Date: Wednesday, October 29, 2014 at 10:04 AM

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:

  1.  Frame Ancestors and Referrer
  2.  Consider directives to manage postMessage and external navigation of iframes [CSP Next] (webappsec issue 69)

Given the following example:


  1.  foo.com at the top level browsing context
  2.  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 directly
However, 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 messageREALLY 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 changed
what the "source" property was on the message event, bar.org-B could just inject code into bar.org-A
as 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 way
to 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 when
the 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 something
else 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 messaging
comes 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<mailto:ssnider@yahoo-inc.com>>
To: Frederik Braun <fbraun@mozilla.com<mailto:fbraun@mozilla.com>>; "public-webappsec@w3.org<mailto:public-webappsec@w3.org>" <public-webappsec@w3.org<mailto: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 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<mailto:fbraun@mozilla.com>>
To: public-webappsec@w3.org<mailto: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.