On 1/5/2015 5:07 PM, Boris Zbarsky wrote:
On 1/5/15 5:17 PM, Nicholas C. Zakas wrote:
Am I just missing something?
Sorry, you're totally right. I was going off the comment in the Chrome bug.
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.
Yes, if we do it with window.open(), then it's possible to set opener to
null. However, if you click on a link with target=_blank, window.opener
is set as well. This is really the issue.
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.
Yup, that's all on me. Thanks for pointing it out.
-Boris
--
___________________________
Nicholas C. Zakas
http://www.nczonline.net
