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

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