570938 - 'Back' navigation via backspace key can be hijacked to return the user to a different page than the one in their history.

Status: RESOLVED INCOMPLETE

(Firefox :: Security, defect)

Description

[phonicuk+mozbugzilla]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.0 (KHTML, like Gecko) Chrome/6.0.408.1 Safari/534.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.3) Gecko/20100401 Hypnoreindeer/3.6.3 (WHAARGARBL) ( .NET CLR 3.5.30729)

The keypress event for the backspace key can be trapped and intercepted. This means that if the user presses the backspace key intending to go to the previous page in their session history, a malicious script can direct the user to a different page than the one intended.

Reproducible: Always

Steps to Reproduce:
1. Create a new HTML file containing the contents of the "Additional Information" field.
2. Open the HTML file in a Firefox window which already has a session history.
3. Press the backspace key
Actual Results:  
The user is redirected to www.youtube.com regardless of what page was actually in their history.

Expected Results:  
The user should be taken to the page in their history.

Both IE8 and Chrome 6 behave in this manner.

<script type="text/ECMAscript">
  document.onkeypress = function(e)
  {
    if (!e) { var e = window.event; }
    
    code = e.keyCode ? e.keyCode : e.charCode;
    
    if (code == 8)
    {
      window.location = "http://www.youtube.com";
      return(false);
    }
  }
</script>

<p>Press the backspace key</p>

Comment 1

[Benjamin Smedberg]

Yes, web pages are able to intercept and treat keystrokes specially. I think this is WONTFIX, because in order for all kinds of rich-text-editing features to work apps need to be able to handle backspace. I suggest you click the back button instead, if you're worried about phishing possibilities.

In any case, we don't need to keep this bug hidden.

Comment 2

[phonicuk+mozbugzilla]

I would reitterate that Firefox is the only browser of the big 3 that behaves in this manner. I think it unlikely that a web app would want to handle backspace in this way for it not to work on any of the other major browsers.

Comment 3

[Jo Hermans]

Gmail uses the back button. Is that big enough as an example ?

Comment 4

[phonicuk+mozbugzilla]

(In reply to comment #3)
> Gmail uses the back button. Is that big enough as an example ?

Gmail doesn't trap the keypress event for the back button being pressed. It instead polls changes to the page anchor. As such there are actual entries in the browser history when the anchor changes.

Thats why when you click on inbox, the URL changes to have #inbox on the end.

Comment 5

[phonicuk+mozbugzilla]

See provided URL for a demo on how this can be made into a real attack.

Comment 6

[Jesse Ruderman]

We could call this attack "Backnapping" to highlight its similarity to "Tabnapping".  Rather than preying on the perceived immutability of tabs, it preys on the perceived immutability of session history.

There are many interacting parts to consider:

1) Detecting (and canceling) user actions that mean 'Back'
  1a) Key: Backspace
  1b) Key: Cmd+Left
  1c) Key: Cmd+[
  1d) Right-click for context menu, select "Back"
  1e) Ctrl+click for context menu, select "Back"
  1f) Toolbar: Click the back button
  1g) Menu: History -> Back

The first two keyboard shortcuts, Backspace and Cmd+Left, have the distinction of having a different meaning if a textbox has focus.  An attack page could focus a hidden textbox and watch for the contents to change.

I suppose we could say "if the first user interaction with the page is to press Backspace or Cmd+Left, ignore the fact that focus is in a textbox".  Or we could remove these shortcuts entirely, and tell users they should always use Cmd+[ if they want to go back using the keyboard.  I don't really like either of these solutions.

The second two keyboard shortcuts involve multiple keys.  Web pages might do something sneaky when they detect the Ctrl press.

For 1d and 1e, I don't think we want to prevent web pages from providing their own context menus.  It's too useful a feature.

2) Canceling navigation

A page can usually cancel a navigation that has started but not yet zombified the old page.  So if the previous page gets evicted from bfcache, and the http cache gets emptied or invalidated, the attacker's page can just keep trying to stop all navigations, regardless of whether it detects a user attempt to go back.  It might be possible to fix this.

3) Changing session history

There are many ways pages can add entries to session history: various kinds of redirects, form submissions, hash-changes, DOM pushState.  Some of these can be hidden by taking place in a frame, or happening in response to what the user thinks is a request to scroll the page.  Then clicking Back once doesn't go back as far as the user might expect.

Maybe we can limit it so that pages you haven't interacted with don't leave an entry in session history.  That should stop the attack without breaking Gmail.  Would this require changes to the HTML5 spec, such as the part related to pushState?

It doesn't seem that this concern came up in https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review :(

Comment 7

[Jesse Ruderman]

The reporter's demo <http://www.phonicuk.com/test/phdemo.aspx> doesn't work if you click it from Bugzilla because referrers are hidden from https.  Instead, you can try it from

http://www.squarefree.com/bug570938/

An attacker needn't rely on the referrer header; spamming each victim page with a different link would work just fine.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

For what it's worth, I do think we talked about this in the pushState security review. However it was deemed that you can already do the same thing by immediately navigating the user to a fragment and then waiting for the back button to get pushed (can be detected by polling window.location, or by listening for the hashchange event)

Comment 9

[Alin Ilea, Desktop Test Engineering]

Marking this as Resolved > Incomplete since the reporter's demo is no longer available, the last activity on this issue was 11 years ago and it might not be relevant anymore. Feel free to re-open if the issue is still reproducible on your end in the latest FF versions.