Cross Origin Opener Policy: clarify what should happen with insecure context interactions

[empijei]

The current proposal states that

This should only work over a secure context.

But this could be potentially misunderstood by people that are implementing the spec and allow for trivial bypasses:

Scenario:

window A (COOP null) on http://evil.com opens window B (COOP same-origin) on https://victim.com

I would hope that https://victim.com could still be protected by COOP, even if in this case it is not inside a secure context.
I would expect COOP to cause a new context to be created and the connection with evil.com to be broken.

[annevk]

See example 4 of https://w3c.github.io/webappsec-secure-contexts/#examples-top-level. There's nothing in that specification that looks at opener or talks about auxiliary browsing contexts. It only deals with top-level browsing contexts and then goes downward.

[arturjanc]

I think part of the problem is that MDN says:

Similarly, if a TLS-delivered document is opened in a new window by an insecure context without noopener being specified, then the opened window is not considered to be a secure context (since the opener and the opened window could communicate via postMessage).

and

Note: Safari and Chrome don't support the full secure contexts specification so APIs may work when using HTTPS iframes inside an HTTP page or pages that have an 'opener context' with an insecure page (this happens when an HTTP page uses Window.open() or the target attribute with a value of _blank).

(But @mikewest pointed out the editor's draft of Secure Contexts is the only source of truth here.)

Nevertheless, I'm a little worried that the restriction to a secure context could become problematic for COOP. If you could force a cross-origin document to be considered a non-secure context (I'm not sure how, given that the opener-based approach doesn't do it) then it would be a bypass of the protections offered by COOP.

If we don't think this will ever be possible, then maybe there's nothing to do here, but it seems a little brittle.

[annevk]

I think the consensus is that such a thing shouldn't be possible. You could probably add an assert somewhere to that effect, though I wouldn't know where offhand.

And yeah, it's best to not use MDN as a source of truth when discussing standards.

[annevk]

cc @whatwg/documentation

[empijei]

What is the security benefit of restricting COOP to secure contexts?

[annevk]

w3c/trusted-types#259 (comment)

[sideshowbarker]

I think part of the problem is that MDN says:

Similarly, if a TLS-delivered document is opened in a new window by an insecure context without noopener being specified, then the opened window is not considered to be a secure context (since the opener and the opened window could communicate via postMessage).

I updated https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts to change that sentence to basically say the opposite of the above, as well as to make other refinements to the article to align with the actual requirements in the current Secure Contexts spec.

If I missed anything, please let me know.

and

Note: Safari and Chrome don't support the full secure contexts specification so APIs may work when using HTTPS iframes inside an HTTP page or pages that have an 'opener context' with an insecure page (this happens when an HTTP page uses Window.open() or the target attribute with a value of _blank).

I have now completely removed the above note from https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts.

[annevk]

Thanks Mike!