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

In reply to Boris, it looks like the spec has changed its wording since the
Chromium bug was filed, and it now sounds like the navigations should be
allowed (consistent with existing browser behavior).

At the time (Jan 10, 2013), I posted a quote of the spec to
https://crbug.com/168988, comment 3:

---------
"A browsing context A is allowed to navigate a second browsing context B if
one of the following conditions is true:
 - Either the origin of the active document of A is the same as the origin
of the active document of B, or
 - The browsing context A is a nested browsing context with a top-level
browsing context, and its top-level browsing context is B, or
 - The browsing context B is an auxiliary browsing context and A is allowed
to navigate B's opener browsing context, or
 - The browsing context B is not a top-level browsing context, but there
exists an ancestor browsing context of B whose active document has the same
origin as the active document of A (possibly in fact being A itself)."
---------

This would suggest that navigating a cross-origin opener is not allowed,
since none of the conditions apply.  However, the spec now reads:

---------
"A browsing context A is allowed to navigate a second browsing context B if
the following algorithm terminates positively:

If A is not the same browsing context as B, and A is not one of the
ancestor browsing contexts of B, and B is not a top-level browsing context,
and A's active document's active sandboxing flag set has its sandboxed
navigation browsing context flag set, then abort these steps negatively.

Otherwise, if B is a top-level browsing context, and is one of the ancestor
browsing contexts of A, and A's node document's active sandboxing flag set
has its sandboxed top-level navigation browsing context flag set, then
abort these steps negatively.

Otherwise, if B is a top-level browsing context, and is neither A nor one
of the ancestor browsing contexts of A, and A's Document's active
sandboxing flag set has its sandboxed navigation browsing context flag set,
and A is not the one permitted sandboxed navigator of B, then abort these
steps negatively.

Otherwise, terminate positively!"
---------

As you mention, this indicates that navigating a cross-origin opener is
allowed, since it now defaults to true.

Anne, you're right that we did not get around to measuring the
compatibility impact of changing the behavior at the time.  Personally, I
wouldn't mind seeing cross-origin opener navigations disallowed, though I
don't have time to study the compatibility impact at the moment.

Hope that helps clarify things,
Charlie


On Tue, Jan 6, 2015 at 9:22 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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 https://html.spec.whatwg.org/
> multipage/browsers.html#navigating-across-documents 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.
>
> -Boris
>

Received on Tuesday, 6 January 2015 17:40:09 UTC