Using active document of a browsing context introduces a security vulnerability

[andypaicu]

Instances of using the active document of a browsing context introduce a vulnerability where the browsing context could have navigated in the middle of the current request and we are inheriting a new document's CSP.

Better explained by @bzbarsky here: #358 (comment)

We should use the request's client.

Places that do this (incorrectly):
https://w3c.github.io/webappsec-csp/#initialize-document-csp
https://w3c.github.io/webappsec-csp/#should-block-navigation-request
https://w3c.github.io/webappsec-csp/#should-block-navigation-response

Places where the usage is correct and should be kept:
https://w3c.github.io/webappsec-csp/#frame-ancestors-navigation-response

[bzbarsky]

It's not clear to me that the use in https://w3c.github.io/webappsec-csp/#frame-ancestors-navigation-response is correct either, fwiw. "parent’s active document" might not be the same as the document that contained the iframe tag that created the "current" (well, the old value, before we set it to "parent") browsing context.

[andypaicu]

Yes, but an iframe can be navigated by someone different than its parent and frame-ancestors specifically deals with the embedded chain of an iframe, so using the request is definitely wrong.

Let's say we have parent document A that embeds iframes B and C. B navigates its sibling C to D and D has a frame-ancestors directive. That directive should check whether A is an allowed embedder and it's not relevant whether A initiated the navigation or someone else.

If the parent of an iframe navigates away doesn't the iframe loading stop anyway? I guess I'm not seeing how a "parent's active document" can change without simply stopping the iframe request since it's part of the parent document. Is there a way to change the parent document but keep a child iframe?

[bzbarsky]

so using the request is definitely wrong

Sure.

If the parent of an iframe navigates away doesn't the iframe loading stop anyway?

Probably yes, but I would be happier if we did not rely on that. For example, if preloading ever gets resurrected, this would become a problem again.

Is there a way to change the parent document but keep a child iframe?

In general, sure, though not necessarily while there is a child request running in the iframe. Both Firefox and Safari implement, and the spec supports, mechanisms that store the whole DOM/JS state in the session history.

Anyway, I think what would make the most sense for frame-ancestors is an algorithm like this:

1. Let current be target.
2. While current is a nested browsing context:
   1. Let document be the Document that current is nested through.
   2. Let origin be the result of executing the URL parser on the ASCII serialization of document's origin. (No need to indirect via the settings object, afaict... but if there is, it would be good to have a note explaining why that's needed.)
   3. Do the check on origin.
   4. Set current to document's browsing context.

This is provably correct (in that it walks the ancestor chain of documents involved) without having to think about details of the navigation algorithm and its complicated interactions with all this stuff.