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

Re: Breaking the `opener` relationship.

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Thu, 27 Apr 2017 19:15:09 -0700
Message-ID: <CAPfop_1mLaDsc9HxKQ=JBm+Lbs-x9uCs2oRWT=Um0HOiriu1jQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Mike West <mkwst@google.com>, 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>
I am sorry to ask a dumb question but I don't have a lot of context on
this: what was the motivation for limiting post message?

 I feel like there is chasm between navigating and post messaging.
Even though I agree with Artur about risk priority, I am ok with
lumping iframe and window.open together for this directive.

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.

If we are worried about vulnerabilities in the MessageEvent handlers,
I think this is a broader problem and I am all for CSP directives to
control who can send/receive post messages from a page.


On 27 April 2017 at 07:19, Anne van Kesteren <annevk@annevk.nl> wrote:
> 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?
> --
> https://annevankesteren.nl/
Received on Friday, 28 April 2017 02:16:02 UTC

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