Re: [powerful-features] Use of the active document in defining a secure context is fishy

On Wed, Jul 1, 2015 at 5:05 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> https://w3c.github.io/webappsec/specs/powerfulfeatures/#settings-secure
> step 2.1 sets "ancestors" to be "a list of Documents containing document
> and the active document in each of document’s ancestor browsing contexts".
>
> Ignoring for the moment that a document has no concept of an ancestor
> browsing context, and assuming this meant to say "the active document in
> each of the ancestor browsing contexts of document's browsing context",


https://github.com/w3c/webappsec/commit/1a8c1cc28c7f43f496efe7d9a32586d4bafd5abd

Thanks! :)


> I would like to think about the following situation:
>

To step back a moment, the intent is to address the kinds of things that we
saw happen with WebCrypto. Putting aside for the moment the question of
_whether_ WebCrypto should be restricted to secure contexts, it turns out
that the restriction is fairly meaningless if an insecure context can embed
a cooperative secure context. Netflix, for example, wrote more or less a
1:1 shim which wrapped the API inside of a securely-delivered iframe, and
exposed a `postMessage()`-based interface to the insecure top-level
document.

This is why we do ancestor checking in the first place, and expose APIs iff
the whole chain is secure. We thereby mitigate the potential for this kind
of bypass (though, as you note below, that mitigation is certainly
imperfect).

With that in mind:

Consider a website (call it W) loaded from http://a which has a subframe
> (call it X) loaded from https://b.  This subframe opens another window
> (call it Y) loaded from http://c.  This window has a subframe (call it Z)
> which is loaded from https://b (so X and Z are same-origin).
>
> Now X grabs a reference to the window object of Z and then navigates Y to
> https://d.  Then it tries to do something with that window object that
> performs the check at
> https://w3c.github.io/webappsec/specs/powerfulfeatures/#settings-secure


As you note at the end, X can gain access to exciting capabilities by
popping up new window, navigating it to a secure document, and
`postMessage()`ing its way to success. I hadn't considered just grabbing
the `window` object itself, but that seems possible as well.

One option is simply to allow this kind of workaround; popping up a window
requires a user gesture, and might be annoying enough (especially in
conjunction with a permission request in the popup?) to make this an
unappealing option for most folks.

Another would be to propagate "secureness" from an opener to the openee.
That is, perhaps insecure contexts shouldn't be allowed to open secure
contexts, regardless of the context's location or TLS state.

It's not clear to me how far we ought to go to prevent developers from
doing this kind of thing. My intuition is that walking the ancestor chain
is enough, and that popups are annoying enough for everyone involved to
avoid. What do you think?

+Yan, who is smart and has opinions.

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)