[whatwg] postMessage: event.source allows navigation of sender

[Adam Barth]

On Feb 7, 2008 2:27 AM, Hallvord R M Steen <hallvors at gmail.com> wrote:
> > Opera assumes that if a script
> > has a JavaScript pointer to a frame then that script is permitted to
> > navigate that frame.
>
> This is actually per the spec and required for web compatibility: any
> script that has a pointer to a window object can usually set its
> location property.

This does not seem to be required for web compatibility because
Internet Explorer, Firefox, and Safari all restrict what happens when
you assign a frame's location property according to their navigation
policy.  If the navigation is denied, Internet Explorer opens the page
in a popup instead (unless blocked by the popup blocker) and Firefox
throws an exception.  The latest nightly build of Safari also opens a
popup window when a navigation is denied, but the currently deployed
version only logs the error to the debug console.

> I expect most UAs only disallow it for http->https
> communication and I know Opera is a tad stricter than the others and
> disallow it if domains do not match for https->https communication.

The frame navigation policy in Internet Explorer, Firefox, and Safari
is based on origins.  If two frames are in a different origin, the
frame navigation policy does not distinguish origin differences due to
hosts from origin differences due to schemes.

> If you have test cases that show other browsers disallowing scripts
> that have a pointer to a window object from setting location across
> domains I'd very much like to see them.

Here is a test case:

http://crypto.stanford.edu/~abarth/research/html5/sibling/

The first child frame is in a different origin from the top-level
frame and from the second child frame.  In Internet Explorer, Firefox,
and Safari, the first frame can obtain a JavaScript pointer to the
second frame, but cannot navigate the frame by assigning its location
property.  This demo works in Internet Explorer 7, Safari 3, and
Firefox 3.

> Being more restrictive in
> certain cases would be nice but is in my experience not possible
> without too much breakage, so I'm very interested if you can
> demonstrate stricter policies that actually work.

This demonstration shows that Internet Explorer, Firefox, and Safari
restrict these cases.  These browsers are widely deployed, and the
best thing for compatibility would be for all browsers to consistently
apply the same policy.

> (Note that I am talking only about setting window.location here, not
> about e.g. targetting a named window with a window.open call - that's
> a different scenario entirely.)

Yes.  Named window navigation is another scenario.

> Adam, I don't quite follow you here because I don't know any IE or
> Safari implementation of window.postMessage. I'm quite sure IE doesn't
> implement it, I  tried googling for Safari and
> postMessage/cross-document messaging but didn't find anything. As far
> as I know only Firefox 3 betas and Opera supports this, so no other
> implementations can be tested.

postMessage is implemented in the trunk version of Safari.

http://nightly.webkit.org/

I do not know if postMessage will be implemented in Internet Explorer
8, but if it were to be implemented in IE8, the source attribute would
not leak any privileges to the recipient because IE checks whether the
navigation is permissible before performing the navigation.

> We should probably fix that if there is consensus on the more liberal
> approach

Yes, interoperability would be improved if all browsers implemented
the same security policy.

> though note that Opera nevertheless allows you to set
> window.frames[i].location across domain. I don't know how you tested
> "allow scripts to read window.frames[i]" to reach the above statement.
> If you try a simple

The same demo at
<http://crypto.stanford.edu/~abarth/research/html5/sibling/> shows
that Opera does not permit a script to assign top.frames[1].location
when top and the second frame are in a different domain.

> > Other browsers do not equate having a JavaScript pointer to a frame
> > with the ability to navigate that frame.
>
> Again if you can back that up with test cases I'd love to see them :-)

This is the same test case.

> > > I think this should be adressed by removing event.source entirely.
> >
> > Another way to resolve the issue is for Opera to match the other
> > browsers and check whether a script is permitted to navigate a frame
> > when that scripts assigns the frame's location.
>
> But this would have to be applied only when window.location was set in
> a message event handler - that would get very messy!

I'm suggesting Opera should match the behavior of other browsers and
check whether a navigation is permissible under its frame navigation
policy before performing the navigation, regardless of how the browser
was requested to perform the navigation.  It is difficult to control
navigation by containing references to frames because it is easy for
JavaScript pointers to frames to escape in unexpected ways, for
example via the source attribute of the message event.

Adam