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
