Skip to content
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

Security checks in navigate are racy and hence broken #2591

Closed
bzbarsky opened this issue Apr 26, 2017 · 4 comments · Fixed by #6801
Closed

Security checks in navigate are racy and hence broken #2591

bzbarsky opened this issue Apr 26, 2017 · 4 comments · Fixed by #6801

Comments

@bzbarsky
Copy link
Contributor

https://html.spec.whatwg.org/#navigate step 12 in the javascript: case, substep 1 does a check that involves the "source browsing context's active document's origin".

Unfortunately, this need not match the origin that browsing context had when the navigation started, because this step is running off a task. So in a browser that implements the spec as written you get a security hole: if you target a javascript: load at a cross-origin site just as you're being unloaded due to navigation to that same cross-origin site you get XSS.

I know there are existing bugs on the "source browsing context" thing being a bit wonky, but given that I know there are implementations attempting to align with the HTML spec on the navigation algorithm, or even implementing directly from the spec, it would be good to at least have a note here or something explicitly calling out the fact that the spec should not be implemented as-is.

// cc @asajeffrey @cbrewster

@annevk
Copy link
Member

annevk commented Apr 27, 2017

Created #2601 to add issue markers.

@gterzian
Copy link
Member

gterzian commented Jun 7, 2019

The origin concept on the other hand seems to take this into account for "Documents (that are) created as part of the processing for javascript: URLs" in stating that their origins are determined by taking "The origin of the active document of the browsing context being navigated when the navigate algorithm was invoked."

@domenic
Copy link
Member

domenic commented Jun 16, 2021

I'm still investigating but it appears like Chrome (probably WebKit too?) may have a very different way of handling JS URL origin checks. I can't find any origin check like the spec has at all, in the code. Instead they ensure that the response created from the JS URL navigation has the initiator origin. (Which initiator? See #6514.)

This is unlike the spec's version which does an origin check to make sure that the initiator origin is same-origin with the target browsing context's current origin, and then creates a response using the target browsing context's current origin.

@domenic
Copy link
Member

domenic commented Jun 17, 2021

I was wrong, there is an origin check: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/local_frame.cc;l=1857

(Notably the check is done synchronously for location.href assignment O_o...)

domenic added a commit that referenced this issue Jun 23, 2021
This makes it non-racy by taking the origin snapshotted at the top of the navigation algorithm. Fixes #2591. Helps with #1130. See #6514 for related investigation.
domenic added a commit that referenced this issue Jun 25, 2021
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.
mfreed7 pushed a commit to mfreed7/html that referenced this issue Jun 3, 2022
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

4 participants