Re: Breaking the `opener` relationship.

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.

regards
Dev



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