Thanks for the report!

I'm having some trouble reproducing this locally. Could you give some more detail about what the expected behavior is and how the attack works? Also, do you think this would work (or could be made to work) when the target page in the attack is on a different origin?

Here's what I tried using Chrome 69 on Linux:

1. Start local server using `python -m SimpleHTTPServer`
2. Navigate to http://localhost:8000/index.html
3. See a lot of "Hey<random characters>" output
4. See a javascript alert that says "Leaving"; click "OK"
5. Automatically navigated to http://localhost:8000/another.html where it just says "Wait a minute... You are not supposed to be here."

I also tried in Chrome 66.0.3359.117 ASAN build (to try to match the version you tested on) but had the same result.

I replied via email but I am not sure if that was the right channel for that so this is a follow up.

In line 33 of index.html there is a call to window.open to redirect to site2.html if a certain value is set to true which it will be set to after 4000ms

The expected behavior is for the browser to open site two but asynchronous calls made during that time override this behavior and redirects you to another.html with the text "Wait a minute... You are not supposed to be here". The redirection to another.html only occurs after the window.open is called and so redirecting to my specified page is definitely not wanted in this case

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for the additional details. I've been able to reproduce the behavior you described on Chrome 69 on Linux (where the navigations occur in that order).

This falls under one of the exceptions to the same-origin policy when you have a handle to the Window object (https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Window) -- read/write access to window.location is allowed.

Typically this behavior would be for popups, but there may be a brief time when the prior javascript execution context can finish executing deferred tasks after another navigation is committing. I don't think there are any security consequences here, since you could explicitly do the same thing without the timing race by opening site2.html in a popup, and that would fully fall under the exception allowed under the same-origin policy. (Additionally, with site-isolation, cross-site navigations like this are forced into separate processes, so even if the old javascript execution context is still running it can't use this trick to load a different site into its process.)

This is, however, a potentially confusing behavior that could occur with kinda-buggy asynchronous javascript navigations on sites in the wild, so I'll leave this as a functional bug that the V8 team can consider.

If you come up with other tricks you can pull off, please file a new security bug and one of us would be happy to take a look :-)

The review process made it a nice first bug reporting experience for me. Thank you for making it pleasant for a tech enthusiast still months shy of 18. I am hopeful that I have been able to at least add value to the project as I look forward to helping out whenever possible, to make technology better in the service of humanity.

Sorry about going philosophical, Sometimes i just get in the mood :)

Good morning, sorry to disturb but i changed the url in the open call to "http://www.google.com" and i still got the same results, hoping you could confirm this at your end

Deleted: index.html 4.5 KB

index.html 4.5 KB View Download

Yep, I would expect that this can still work even when the window opened is to a different origin. Read/write access to window.location is allowed as an exception to the same-origin policy if you have access to the window object.

Happy bug hunting :-)