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

[Adam Barth]

On Feb 7, 2008 4:32 AM, Hallvord R M Steen <hallvors at gmail.com> wrote:
> One case I'm still
> somewhat concerned about is that one is allowed to set the location of
> any top-level window according to the ancestor policy,

Yes.  I think there is a lot of room for improvement in this part of
the navigation policy.  The idea behind permitting the navigation of
top-level windows is that browsers display the location of these
windows in the location bar, but a user might not notice that the
location bar has changed if the top-level window is navigated at an
unexpected time.

Firefox's implementation of the ancestor policy restricts the
navigation of top-level windows based on openers (but only when
navigating by name).  As you know, Opera restricts the navigation of
top-level windows based on a number of factors, including whether the
window is displaying an HTTPS page and the destination of the
navigation.

> For example, consider
>
> w=window.open();
> w.opener = null;
> w.location = 'http://untrusted.example.org'
> w.postMessage( '...' );
>
> Untrusted content now gets a window reference it would not otherwise
> have, and will be allowed to set location if this scripts runs in the
> top context of the opener.

This is an interesting case because some web sites, for example Gmail,
attempt to restrict which sites can navigate their frames by nulling
the window.opener property of windows they creates.  This technique is
only partially effective because

1) Safari restores the opener property after navigation,
<http://bugs.webkit.org/show_bug.cgi?id=17111>.

2) Gmail, in particular, doesn't clear the window.name property of its
window.  That means a malicious web site can navigate the Gmail window
if it happens to have a name.

It seems like a better solution is to improve the navigation policy
for top-level windows.  That way, web sites don't have to fight the
losing battle of controlling references to their windows.

One possibility is to prevent one frame from navigating another if the
frames are in different units of related browsing contexts.  This is
consistent with HTML5's philosophy that different units of related
browsing contexts could be run in different threads and do not
interact directly.  That way, if a user visits a web site by first
creating a new tab, the existing frames cannot navigate the new site's
frame.

In addition, we could define a new target, for example "_unrelated",
such that calling

window.open(url, "_unrelated")

would open the URL in a new unit of related browsing contexts.  Under
the proposed policy, the newly opened window would be unable to
navigate its opener.  (Of course, window.open would need to return
null and the newly opened window's window.opener property would need
to be null.)  This would be a useful mechanism for applications like
webmail that wish to open windows but do not wish to be associated
with the content they open.

Adam