W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2015

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

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Thu, 02 Jul 2015 12:15:23 -0400
Message-ID: <5595639B.60804@mit.edu>
To: Mike West <mkwst@google.com>, Yan Zhu <yzhu@yahoo-inc.com>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
On 7/2/15 3:32 AM, Mike West wrote:
> To step back a moment, the intent is to address the kinds of things that
> we saw happen with WebCrypto.

Yes, I understand that.

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

My point is that it's not only imperfect, it's just broken because it's 
looking at objects that have nothing to do with the actual global you're 
operating in.

I mean, consider the opposite situation:

Window W is loaded from https://a.  It loads a subframe X from https://a 
which loads a subframe Y from https://a.  W grabs an object from Y, then 
X is navigated to http://b and W tries to use the object it grabbed.

In this situation, the object will be treated as not in a secure 
context, because the document in its browsing context's ancestor 
browsing context is "http://b".  This seems a bit weird to me.

All of which is to say that instead of walking the ancestor browsing 
context chain and adding their active documents to the list we should 
perhaps walk the browsing context creator document chain, adding those 
to the list.  This _does_ cross window.open calls, though; if we want to 
exclude that we can with a bit of checking for whether the browsing 
context of the creator document is in fact the ancestor browsing context.

Also, if you _want_ my example above with https://a that's been 
navigated away from to be treated as insecure, then presumably you want 
to walk up the creator document chain (possibly with the check to not 
cross window.open, whatever) and return "insecure" as soon as you hit a 
document that's not the active document.  But at least then this will be 
an operation which makes sense: you're examining the things that 
actually led to the thing we're looking at and seeing whether we want to 
treat them as secure or not.  Right now the spec is examining some 
totally unrelated set of documents to decide whether we're a secure context.

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

It's certainly possible.

> One option is simply to allow this kind of workaround

I guess it really depends on which problems you're trying to solve and 
how much web breakage you're ok causing in the process.  ;)

> Another would be to propagate "secureness" from an opener to the openee.

Right, this is the thing that could cause web breakage.  Consider a site 
that just has a <a href="http://something" target="_blank">.  Should 
everything in that new window be considered insecure from then on, even 
if the user types in the url bar?  I would argue not.

So we'd need to not set or reset this flag in some situations. (e.g. 
when the load is not same-origin with the origin that was marked 
insecure?  But then you could just launder things through a subdomain or 
something.)

> It's not clear to me how far we ought to go to prevent developers from
> doing this kind of thing.

Me neither, since I'm not really clear on what fundamental problem we're 
trying to solve.

> My intuition is that walking the ancestor
> chain is enough

I would be fine with that if we walked the actual chain of ancestors of 
the document, not some other kinda sorta but not really related chain, 
see above.

-Boris
Received on Thursday, 2 July 2015 16:15:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:13 UTC