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

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

From: Nicholas C. Zakas <standards@nczconsulting.com>
Date: Tue, 06 Jan 2015 12:10:48 -0800
Message-ID: <54AC4148.7030105@nczconsulting.com>
To: whatwg@lists.whatwg.org

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
Received on Tuesday, 6 January 2015 20:11:17 UTC

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