search

w3c / webappsec-secure-contexts

WebAppSec Secure Contexts
https://w3c.github.io/webappsec-secure-contexts/
Other
33 stars 38 forks source link

Consider whether sandboxed content should automatically be a secure context #28

Closed jwatt closed 4 years ago

jwatt commented 8 years ago

It may be that content authors want to prevent sandboxed content from being a Secure Context even if the target of a sandboxed frame is an https URI, or even if the content of the document is otherwise known to have been securely transported (a srcdoc attribute inline in the sandboxing document, say).

Maybe the sandbox attribute should have a new allow-secure-context flag that is required for the sub-document to create a secure context? (That would have the added benefit of making authors explicitly state that the content of a srcdoc (say) was securely delivered which makes things a bit more robust than what we have now where we just assume that to be the case if the embedding document is a secure context.)

CC: @mikewest @annevk @bzbarsky

mikewest commented 7 years ago

I'm a little worried about doing this, given that both Chrome and Firefox already lock a number of features to secure contexts in Chrome, and I'm loath to make another change to the places in which those features are available in the very near future.

I'm marking this as "v2", as I think it fits in well with some of the other kinds of modifications to tighten Secure Contexts (into "Really Secure Contexts"? :) ) that @johnwilander was proposing at our last face-to-face meeting.

bzbarsky commented 7 years ago

Note that this came up while implementing in Gecko as a practical matter: we had places in our browser UI that were sandboxing stuff and would NOT have wanted it to end up secure context even though the browser UI itself clearly is. Websites would run into the same issue.

Firefox doesn't lock anything to secure context yet; it's not clear to me whether you think it does or not....

mikewest commented 7 years ago

Hrm. shrug If y'all feel strongly about it, I can add some metrics to Chrome to see how much flexibility I have with our implementation. Based on https://www.chromestatus.com/metrics/feature/timeline/popularity/672, sandboxed frames appear on ~0.6% of pages that Chrome's users see, which is fairly high. It's possible that not many of those frames are using APIs we'd consider powerful, but in the absence of any other context, it worries me.

Note that this came up while implementing in Gecko as a practical matter: we had places in our browser UI that were sandboxing stuff and would NOT have wanted it to end up secure context even though the browser UI itself clearly is. Websites would run into the same issue.

  1. What kinds of decisions are you making based on the "secureness" of the context? Especially given the next sentence, it's not clear where this would have impact on the abilities sandboxed frames would retain?
  2. Browser chrome is something of a special snowflake, both because it often has access to APIs we'd be very wary of giving to the web, and also because you have complete control over it, so there's no backwards compatibility to worry about. I think it's probably possible to be much more strict with those contexts than otherwise... (Chrome prevents web->chrome:// navigations, for instance). Changing the rules for a custom scheme seems like a totally reasonable thing to do, regardless of what the spec says about the web.

Firefox doesn't lock anything to secure context yet

What about things like Service Workers? If y'all aren't locking things like that to secure contexts, do you have plans to start doing so? I guess I assumed this was already done...

bzbarsky commented 7 years ago

What kinds of decisions are you making based on the "secureness" of the context?

None yet; this was looking forward to some of the things we do plan to condition on secureness.

and also because you have complete control over it

Not at all, because of extensions.

This specifically came up in the context of sandboxed srcdoc, btw.

What about things like Service Workers?

The API is exposed. The implementation I think rejects in non-secure contexts, for definitions of "non-secure" which doesn't match this spec, because we're still in the middle of implementing this spec.

johnwilander commented 7 years ago

Mike, I really should get going with our Secure Context v2 proposals. Can you pull me in formally somehow? I need more pressure.

mikewest commented 7 years ago

I'm coming around to the idea. I'll add it to the spec as "at risk" pending the metrics I'm adding to Chrome in https://codereview.chromium.org/2160533002.

mikewest commented 7 years ago

Closed via w3c/webappsec-secure-contexts#528190c. We can decide whether to keep this once metrics roll in.

bzbarsky commented 6 years ago

@mikewest Note that there are now apparently web platform tests (e.g. https://github.com/w3c/web-platform-tests/blob/master/storage/opaque-origin.https.html) that depend on sandbox not affecting secure context state. :(

bzbarsky commented 5 years ago

@mikewest So what is the spec outcome here? What do implementations do?

annevk commented 4 years ago

I didn't know this was a thing, but my recommendation would be to remove this sandboxing feature. I think it's a big selling point that the entire document tree is a secure context and having exceptions to that model is confusing (and also why I argued to for data URLs to be a secure context when embedded).

mikewest commented 4 years ago

No browser shipped it, and I agree that it's better that way; I'll drop it from the spec.