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

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

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Tue, 06 Jan 2015 12:22:29 -0500
Message-ID: <54AC19D5.8040209@mit.edu>
To: whatwg@lists.whatwg.org
On 1/5/15 8:14 PM, Mat Carey wrote:
>> even when the two windows have different domains
>> Basically window.opener.location.href = "whatever" works all the time
> Looks like Chrome, Firefox and Opera already differentiate between window origins when the example is changed to window.opener.location.href="javascript:alert(‘Gotcha');” - if they’re on the same origin the alert is displayed, if they’re on different origins it’s not.

This is a totally different issue.  This case basically does an eval in 
window.opener, and has to be blocked if the setter is not same-origin to 
prevent cross-site scripting exploits.

You can see this in the spec in 
step 15 the javascript: case, substep 1, which says:

   If the origin of the source browsing context is not the same origin
   as the origin of the active document of the browsing context being
   navigated, then act as if the result of evaluating the script was
   the void value, and jump to the step labeled process results below.

Importantly, this is absolutely required to prevent XSS, as I said, and 
all browsers already do this and have since time immemorial, so no sites 
depend on this working.

> I guess it’s a logical that the existing restriction should be applied more widely.

The wider application doesn't resolve immediate XSS issues, and is very 
likely to cause web compat problems.

It's worth thinking about, but data on how serious the web compat issues 
are is key.  And as noted sites have a way to opt in to more protection 
here already; the only thing we're discussing is the default behavior.

Received on Tuesday, 6 January 2015 17:22:59 UTC

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