Re: Breaking the `opener` relationship.

Thanks for your comments, folks!

On Thu, Apr 27, 2017 at 4:19 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Apr 27, 2017 at 12:57 PM, Mike West <mkwst@google.com> wrote:
> > The goal instead is to prevent cross-origin pages that gain
> > a reference to the protected page (e.g. via `window.open` or `<iframe>`
> in
> > either direction) to use that reference to poke the protected page in
> ways
> > it might not expect.
>
> You mean like postMessage()? It would help if we're more explicit
> about the goals.
>

Dev asked a similar question about the threat model, I'll try to answer
both here:

#2 in https://wicg.github.io/isolation/#threat of Emily's doc spells out
the model in broad strokes. Basically, if someone has a handle to your
window, it's not really your window anymore, not fully. Locking down access
to `w.postMessage()`, access to frames (`w.length`, `w.frames['name']`,
`w.frames[1]`, etc), `focus()`/`blur()`, and `w.location` stand out as the
things I'm concerned about. Mostly in the context of Emily's Isolation
proposal, but hopefully in a generally applicable way.


> > Assuming that `https://a.com/sekrit` served a response with
> > `content-security-policy:
> > block-cross-origin-access-via-windowproxy-and-etc`, I'd expect the
> following
> > behavior:
> >
> > 1.  `var x = window.open('https://a.com/sekrit')` executed from
> > `https://evil.com/` would return a `WindowProxy` object, just as it does
> > today. But, accessing `x.location` or `x.postMessage`, or any of the
> other
> > cross-origin attributes would throw a `SecurityError`.
>
> That would only work post-navigation, but seems reasonable.


In the initial implementation, yes. In a magical world where Origin Policy
was a thing, we might be able to make it work on the intial `about:blank`
as well, since we'd know a priori that the navigation would result in a
protected window.


> What about using window.name to get a reference? Presumably that would
> fail too?
>

If `window.name` was used to gain a reference to the window, I'd imagine
that that reference would be similarly neutered. The flag would need to be
available no matter how the proxy object was obtained.


> This would only be for cross-origin? What about similar-origin?


`WindowProxy`'s `[[GetOwnProperty]]` uses
https://html.spec.whatwg.org/#isplatformobjectsameorigin-(-o-): I'd just
stick with that as a determinant of the properties listed in
https://html.spec.whatwg.org/#crossoriginproperties-(-o-).

On Fri, Apr 28, 2017 at 4:15 AM, Devdatta Akhawe <dev.akhawe@gmail.com>
 wrote:
>
> Even though I agree with Artur about risk priority, I am ok with
> lumping iframe and window.open together for this directive.
>

I think it would be strange to treat these distinctly: both offer
third-parties access to your `WindowProxy` object. It's not clear that
trusting one is any different than trusting the other, as they offer the
same capabilities.


> But, both for window.open and iframes, I think there is value to
> allowing post-messages. Post messages have a security model: the
> target page can check event.origin and ignore the messages; unlike
> window.opener navigation scenarios. Seconding Artur, I feel like
> restricting post message will significantly affect ability to
> effectively adopt this directive.
>

Artur raised similiar concerns. *shrug* If you do the right thing with
source and origin checks, then I agree with you that `postMessage()` isn't
terribly dangerous. That said, we consistently see folks do the wrong thing
with these checks.
https://labs.detectify.com/2017/02/28/hacking-slack-using-postmessage-and-websocket-reconnect-to-steal-your-precious-token/
is the most recent example I can remember of this kind of attack vector.

That said, I recognize the suggestion in both your response and Artur's
that blocking all cross-origin access might be overly draconian. I was
trying to avoid it, but one of the suggestions that Jonathan Watt made in
https://github.com/w3c/webappsec-csp/issues/194 was to turn this into a
source list such that the cross-origin check would turn into a list of
acceptable origins. I'm a little bit worried about the expense of injecting
such an access check into our bindings, but it's an option if a flat
lockdown isn't something we can work with. I'm also a little bit worried
that you'll next ask for a separation between different types of
cross-origin access (e.g. `postMessage` vs `location`) which I'm not
excited about creating (both because of implementation complexity and
developer confusion (where does named-access to frames go, for instance? Or
`blur()`?). "Cross-origin stuff" seems like a narrow enough bucket on its
own.

WDYT?

-mike