Restrict to secure contexts

[annevk]

Any reason this isn't restricted to secure contexts?

[koto]

What's the advantage of restricting that? TT restrict the capabilities of the authors - what would be the attack we'd be preventing by restricting the API to secure contexts?

…

On Mon, Feb 17, 2020, 18:23 Anne van Kesteren ***@***.***> wrote: Any reason this isn't restricted to secure contexts? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#259>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA7JK4NESXKRJK22TRM66TRDLBZPANCNFSM4KWVXZIA> .

[jonathanKingston]

Some thoughts before I forget:

What's the advantage of restricting that?

• Browsers agreed on restricting all new APIs unless it became an unreasonable implementation effort to do so.
  • This move was to help advance the web platform to HTTPS by default.
• The rationale isn't too dissimilar to the arguments of removing Web Crypto. It's a new feature that is to improve the security of web applications. It's hard to expect security when the transport layer can't be trusted.

What's the advantage of restricting that?

• An active network attack can manipulate the code such that the assurances of Trusted Types no longer hold.

[koto]

Thanks for clarifying, Jonathan!

/cc @mikewest. I don't have a strong opinion here, but it would be surprising for authors if some directives of CSP applied, and some did not, depending on the page origin. An active network attacker can remove the assurances of most of the Web APIs, but here the effect of the attack would be that the web application can still have unconstrained DOM XSS, which doesn't give the attacker capabilities they did not already have.

If I understand correctly, secure contexts are intended to guard "sensitive APIs", not all new APIs (source), but I lack the bigger context here.

[otherdaniel]

On Chromium side, we'll restrict TT to secure contexts.

(Obviously, it's much easier to extend an API's scope than to restrict it, so in case of doubt we should probably opt for restricting.)

[koto]

Reopening, as this led to a nasty bypass due to secure context inheritance rules. In short, framing a document from a non-secure context disables DOM XSS protections despite that document being delivered over a secure transport. Letting the embedder disable security restrictions of APIs is quite undesirable.

Perhaps this can be gated on a weaker condition? Something like [SecureTransport] or [SecureContext=NoInheritance]? Protecting against XSS but only websites that prohibit framing themselves (or limit the schemes to secure ones) seems too limiting.

[koto]

// cc @mikewest

[annevk]

I think we should offer a way, perhaps through CORP, to indicate you only want to be embedded in secure contexts.

[koto]

The issue is slightly different; Authors don't do anything wrong by letting themselves be embedded from http:, this should not make them more exposed to XSS.

[annevk]

I think that's debatable.

[arturjanc]

@annevk Does frame-ancestors https: not suffice to achieve the goal of making sure you're only embedded in a secure context?

[annevk]

@arturjanc it would break down when playing around on localhost. It wouldn't work for data: URLs. Not sure about blob: URLs. Depends on how that match is done.

[shhnjk]

I think #259 (comment) showed that restricting Trusted Types to Secure contexts provides a bypass. We should make deployment of Trusted Types as easy as possible, and adding more requirements for deployment isn't ideal.

So I think restricting Trusted Types to Secure contexts provides more risks than its advantages.

[koto]

I removed the secure context restriction in #279 due to the bypass vector mentioned in #259 (comment). +1 that the platform should have a way for the embedees to opt-out from being framed by insecure contexts, but I think there's value in addressing XSS without gating that on SecureContext with the propagation rules. Or, more specifically, I think that, while restricting access to powerful APIs makes total sense, allowing a bypass of a security restriction via framing is very undesireable.

[annevk]

Again, the bug here is it being possible to be framed in that way. I'd much rather we address the root cause than a symptom.

[koto]

I think there should be a way to more accurately prohibit framing by insecure contexts, perhaps even making it the default at some point, or non-overridable setting later. But I don't think TT should be gated on that, unless all of CSP also is.