W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2017

Re: Breaking the `opener` relationship.

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 27 Apr 2017 16:19:43 +0200
Message-ID: <CADnb78jJ21WweCwKm8CsG-zMZbktEvPNPg8XYKELvRp4KBCYGQ@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Artur Janc <aaj@google.com>, Alex Russell <slightlyoff@google.com>, Emily Stark <estark@google.com>, Jonathan Watt <jwatt@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Thu, Apr 27, 2017 at 12:57 PM, Mike West <mkwst@google.com> wrote:
> As noted, I think that `disown-opener` is the wrong thing for a page to ask
> for. Instead, I think something like
> `block-cross-origin-access-via-windowproxy-and-etc` is more accurate. That
> is, the goal isn't to prevent `window.opener` from being set on the
> protected page. 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.

> 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. What about
using window.name to get a reference? Presumably that would fail too?

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

Received on Thursday, 27 April 2017 14:20:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:00 UTC