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

[Hallvord R M Steen]

> > Adam Barth and Collin Jackson pointed out to me that while
> > investigating frame navigation policies they found that a recipient of
> > a postMessage in Opera can set event.source.location, thus navigate
> > the sender window/document. I think this is a bug in the API itself.
>
> When one frame posts a message to another frame, the recipient frame
> obtains a pointer to the sender frame as the "source" attribute of the
> message event.  In Opera, this leaks the capability to navigate the
> sender's frame to the recipient because 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. 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.

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. 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.

(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.)

> The source attribute of the message event does not leak any privileges
> to the recipient in Internet Explorer, Firefox, and Safari because
> these browsers do not make this assumption and instead check whether
> the script is permitted to navigate the frame when the script assigns
> window.location.

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.

> In Opera, it is difficult to obtain a JavaScript pointer to a frame
> because Opera prevents scripts from reading window.frames[i] across
> domains.  Internet Explorer, Firefox, and Safari all allow scripts to
> read window.frames[i] across domains.

We should probably fix that if there is consensus on the more liberal
approach - 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

alert(window.frames[i])

you're actually calling the toString() method of the window object,
which Opera disallows across domains so you get a security exception
there. (Perhaps a pointless one..)

> 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 :-)

> > 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! Alternatively we
could pass in a "fake" window object that does not allow setting
location, but that would directly contradict the spec and not be much
cleaner. A postback function on the event object is by far the
cleanest approach I can think of. (Apologies to the Opera and Firefox
developers who would have to change their implementations..)

> On Feb 7, 2008 1:45 AM, Thomas Broyer <t.broyer at gmail.com> wrote:
> > Shouldn't event.source.location be read-only? Isn't that a direct
> > application of the same-origin policy?
>
> Internet Explorer, Firefox, Safari, and Opera all permit a script to
> write window.location across domains.  This action is interpreted as a
> request to navigate the frame.  The browser's frame navigation policy
> determines whether this navigation is permitted.

Exactly.

-- 
Hallvord R. M. Steen