-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Having both incumbentNavigationOrigin and the source browsing context's active document's origin seems bad #6514
Comments
Note that you might not need |
In what follows:
In web-platform-tests/wpt#28347 I tested three scenarios:
I did not yet test COOP enforcement as I figured that's a new feature and might be flexible. Also, I'm waiting on Safari results for the first two. I'm not sure what to conclude from all this.
|
No, CORP is for "no-cors" only; it doesn't apply to "navigate" it appears |
I added another test to the test PR:
In the meantime, I managed to engage @anforowicz on this question. His intuition is that in general the INO is more correct; in particular he's pretty sure we have a bug in both the spec and implementation on It would be nice if we could move everything to INO per @anforowicz's intuition. The way to do this would be to change the request's client to be determined from the incumbent settings object, instead of the source browsing context's active document's relevant settings object. (And we'd probably then also align |
This makes it non-racy by taking the origin snapshotted at the top of the navigation algorithm. It also switches to same origin-domain, which is more reasonable since if you have synchronous access to the document then you can just run JavaScript directly in it anyway. Fixes #2591. Helps with #1130. See #6514 for related investigation.
This makes it non-racy by taking the origin snapshotted at the top of the navigation algorithm. It also switches to same origin-domain, which is more reasonable since if you have synchronous access to the document then you can just run JavaScript directly in it anyway. Fixes whatwg#2591. Helps with whatwg#1130. See whatwg#6514 for related investigation.
Spinning off from #1130 and #2591, my concern is that even if we applied tricks similar to #6497 and #6512, we might end up in a bad place, because we have two notions of "initiator origin" for a navigation.
The spec uses:
Sec-Fetch-Site
When will these two concepts differ? Well, assuming we fix source browsing context's active document's origin to be computed synchronously instead of lazily, then the differences arise mainly when cross-global scripting is involved. For example, consider:
https://a.example.com/
which embedshttps://b.example.com/
which embedshttps://c.example.com/
.document.domain
so that they can synchronously script each other. (You knew it was coming!!)frames[0].contentDocument.querySelector("iframe").src = "https://whatever.example/"
Then, the incumbentNavigationOrigin is the outermost
https://a.example.com/
where the script is running, whereas the source browsing context's active document's origin ishttps://b.example.com/
. (The same thing happens for the initial navigation if we changed this example to insert the innermost iframe, instead of modify it, BTW.)You can construct similar terrible situations with
window.open()
, where the source browsing context is derived from the entry global, which differs from incumbent in fun ways. (On the other hand,location.href
and other setters always sets the source browsing context to the incumbent, so it cannot diverge there.) Other scenarios I haven't dug into are inserting<meta http-equiv="refresh">
or performing a non-bfcachehistory.back()
navigation.Anyway, this difference seems bad. Security checks for
javascript:
URLs and COOP should probably use the same security checks asSec-Fetch-Site
.So, which origin do we care about? I guess this is testable in browsers, so probably I should write some tests and report back...
The text was updated successfully, but these errors were encountered: