- From: Nicholas C. Zakas <standards@nczconsulting.com>
- Date: Tue, 06 Jan 2015 12:10:48 -0800
- 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 http://www.nczonline.net
Received on Tuesday, 6 January 2015 20:11:17 UTC