W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2015

Re: [whatwg] Clarification for window.opener.location.href

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Mon, 05 Jan 2015 20:07:40 -0500
Message-ID: <54AB355C.9040701@mit.edu>
To: whatwg@lists.whatwg.org
On 1/5/15 5:17 PM, Nicholas C. Zakas wrote:
> Basically window.opener.location.href = "whatever" works all
> the time, regardless of origin restrictions, and pretty much works that
> way across all browsers.
>
> This seems to indicate that this behavior isn't allowed:
> https://html.spec.whatwg.org/#allowed-to-navigate

Why not?

Stepping through the "allowed to navigate algorithm" for this case, 
assuming window.opener is a toplevel browsing context:

1)  B is a toplevel browsing context, so this item does not apply.
2)  A is not sandboxed so this item does not apply.
3)  A is not sandboxed so this item does not apply.
4)  We allow the navigation.

Am I just missing something?

If B _isn't_ a toplevel browsing context, then we'd still skip step 1 
because A is not sandboxed...

> This issue is pretty big for sites that host user-generated content, as
> it's easy to create an attack, such as:
>
> 1. Go to a UGC site that allows uploading files with embedded links.
> 2. Upload a file containing a link to an attacker's page.
> 3. When someone clicks the link

So where in this process is the popup window opened?  Is that done under 
the control of the "file containing a link to an attacker's page" or of 
the UGC site?

Because the current spec mitigation for the problem you describe is that 
when a site opens a popup it can set its .opener to null to prevent it 
reaching back into the site that opened it, precisely because of the 
issue you described.

> So my question is: is the spec incorrect in that it should reflect
> reality? Or are browsers incorrect and we should be hounding them to fix
> this behavior?

As far as I can tell, either you're just misreading the spec or I am.

-Boris
Received on Tuesday, 6 January 2015 11:51:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:32 UTC