Closed Bug 804083 Opened 12 years ago Closed 12 years ago

After navigating away during sync XHR, script runs with incorrect "window" object

Categories

(Core :: DOM: Navigation, defect)

x86_64
macOS
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: jruderman, Unassigned)

Details

(Keywords: sec-other, testcase, Whiteboard: Embargo until ESR-31 EOL (like bug 810808))

Attachments

(1 file)

Attached file testcase
This part of the output doesn't make sense: > x is 3 > window.x is undefined
Probably related to the wackiness of spinning the event loop for sync XHR. Bug 780770 is another security bug related to this.
(In reply to Bobby Holley (:bholley) from comment #1) > Probably related to the wackiness of spinning the event loop for sync XHR. Sync XHR is not the only case when we spin event loop, and per spec we must spin event loop in case of showModalDialog.
Are we still running a script against an inner after that inner has stopped being the current inner? What does the spec say for what should happen in this case (e.g. if a navigation happens under showModalDialog, when control returns to the showModalDialog caller)?
Wouldn't this issue happen with document.open/write too?
Hmm. It might, conceivably, yes. Worth testing.
(In reply to Olli Pettay [:smaug] from comment #4) > Wouldn't this issue happen with document.open/write too? We've had issues with it in the past, where cross-compartment calls end up returning to a different compartment than the one they were invoked by. Right now we just wrap for whatever the proper cx compartment is and hope that's enough.
No, we're talking about a different thing. The return would be to the same compartment, and the same inner window, but it would no longer be the current inner. Again, this bug is about the fact that: > x is 3 > window.x is undefined which is perfectly sane if the global is no longer the current inner of "window"...
(In reply to Boris Zbarsky (:bz) from comment #3) > Are we still running a script against an inner after that inner has stopped > being the current inner? That's almost certainly what's happening. window refers to the navigated-to page, but the scope chain doesn't change and continues to point to the old inner window. > What does the spec say for what should happen in this case (e.g. if a > navigation happens under showModalDialog, when control returns to the > showModalDialog caller)? I don't see any special handling there. I can't find it now, but I seem to remember Hixie proposing that navigation stops all scripts in the old window, but was shot down on account of the performance hit of checking if the page had navigated for each function call. I don't see anything that necessarily suggests a security bug here, only odd behavior resulting from the inner/outer window split.
If the old script is pointing at the new window that sounds bad. Do compartments protect that script from accessing any of the data in the new window? We should change the test so that the new window also has an 'x' property and make sure.
Flags: needinfo?(jruderman)
Flags: needinfo?(jruderman)
> If the old script is pointing at the new window that sounds bad. Why? It's no different from any other script pointing to a window that's been navigated... > Do compartments protect that script from accessing any of the data in the new window? I would think so, if the new inner is not same-origin.
Critsmash triage: Can someone suggest a security rating for this issue?
So far I haven't seen any security bug here. But someone should test cross-domain case.
(In reply to Olli Pettay [:smaug] from comment #12) > So far I haven't seen any security bug here. > But someone should test cross-domain case. Matt, can you look at this?
Keywords: qawanted
Al asked me to look at this, so I did. Please let me know if I can be of further help. In reply to Dan's comment #9: > We should change the test so that the new window also has an 'x' property > and make sure. Not 100% sure what is intended, but I altered Jesse's example by declaring x in the new window's inline JavaScript, and this new value was never reflected in the dump output. I read that as either it was consistently overwritten by the original page's declaration of x, or that I'm missing something. In reply to Olli's comment #12: > But someone should test cross-domain case. There are two places here where we call URLs, so not knowing which one we wanted to test cross-domain - I did both. - For XMLHttpRequest.open I substituted a cross-domain URL, and the debug output was exactly the same as before. - For the URL assigned to location, I took the same logic and migrated it to a separate page, hosted x-domain. The debug output was slightly different ("1 fail" instead of "1 succeed") but the window property (in the dump output) remained undefined.
Correction to above - last sentence: The window is not undefined; references to "window.x", however, appear to be. In short, I don't see anything here myself.
Olli, does it sound like we could open this bug up?
Flags: needinfo?(bugs)
The vector here is kind of similar to the one used in bug 810808. Can we maybe wait a little bit?
Flags: needinfo?(bugs) → needinfo?(bobbyholley+bmo)
Flags: needinfo?(bobbyholley+bmo)
Keywords: qawantedsec-other
Whiteboard: [leave closed until bug 810808 is opened]
mrbkap says this isn't actually a valid bug, so I'm closing it. It should be left closed until 810808 is opened because the test case here is very similar to that one.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Whiteboard: [leave closed until bug 810808 is opened] → Embargo until ESR-31 EOL (like bug 810808)
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: