Re: Breaking the `opener` relationship.

On Fri, Apr 28, 2017 at 10:10 AM, Mike West <mkwst@google.com> wrote:

> 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.
>

A couple of other things: `window.stop()`, getting load timings from
cross-origin frames, and the ability to perform arbitrary CSS/SVG transforms
<https://arturjanc.com/xo-frame.html> of cross-origin content, all of which
enabled interesting attacks in the past. I'm not sure if the latter two
would be addressed by this proposal, though.

FWIW I also don't think postMessage is a huge concern here given that
developers already have a mechanism that lets them decide which messages
they trust.


> > 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.
>

To clarify, I don't think we should treat window.open and iframes
differently, but that we should distinguish restrictions based on whether
(1) the document is being embedded/opened by external content, and (2) the
document itself decides to embed/open external content. I can see a lot of
benefit to (1) and would use it in many applications; I don't see much
benefit to (2) over existing mechanisms, and suspect it might make it less
deployable if we bundle these two types of restrictions.


>
>> 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?
>

I'm perfectly happy with a flat lockdown if we can apply it to case (1) but
not (2) ;-)