Friday, December 22nd, 2006

Backbutton Overloading

Category: JavaScript, Tip

Mario Heiderich wonders if being able to do this is a bad thing:


  1. window.onunload = function(){ location.replace(document.location); };

With this one line of code (test page here) you can keep a user around against their will, other than killing that tab/window.

Posted by Dion Almaer at 6:05 am

3.5 rating from 35 votes


Comments feed TrackBack URI

It is not entirely foolproof. If you keep bashing the back button, it will eventually go back to the previous visited page. Not only that, it will add a history for that page. In other words: if you push forwards, you stay on the same page.

(I found this out because I am an extrmely angry and impatient person 8P )

Comment by Wouter — December 22, 2006

Does not work in Safari. If you use the back button, if just works as usual. Even if this worked, you would still have the problem that the page would be reloaded and all JavaScript variables and objects were gone.

Comment by AndiSkater — December 22, 2006

I clicked the Google link, then viewed the source. It showed me the source for Google and not the inescapable page. Could be handy for a tool to view the source of other pages, while not leaving one.

Comment by Dave — December 22, 2006

hmm… what’s the point of destroying your user’s will? Oh, i know, to piss them off
The up side i see is that if you have an application that has some Ajax pieces built in, and you don’t want them going back and force and loose the look and feel, then it might be useful, but this is really taking it to the extreme.

Comment by Simon Jia — December 22, 2006

To be honest, I don’t like that “keep a user around against their will”-part.

Comment by Kalle — December 22, 2006

The “No-script” plugin for Firefox is usefull in that case… :]

Comment by DJP — December 22, 2006

Thanks for posting! In my opinion, this is a horribly bad thing which does annoys me! Why keep someone around if they are trying to leave your site? It only irritates them and makes them think twice about coming back. Unuforunately this is a cheap and rude way at gaining extra page hits : ) Thanks for the post…

Comment by Rob Cluett — December 22, 2006

Ok, so the example shows how to keep people at your site, but that isn’t really the worst use of this method. It could actually be used to compromise a user’s security by redirecting them to an evil site when they think they’re clicking on a good site.

An input form with bad validation, for example, could allow a user to add javascript that hijacks the onunload with a redirect to an evil url. The redirect would pass the correct url as a parameter to this evil url. evil site then uses this url to fetch the good site, changes the html to do bad things, and shows it to the user.

naïve user doesn’t realise that he’s not at, but at (maybe because the link actually pointed to and gives away some critical data.

Comment by Philip Tellis — December 22, 2006

The onunload event can be useful for cleaning up upon leaving a page, such as saving recent changes. Unfortunately, providing this power leaves the user open to malicious scripts (which mostly, I think, would be off the annoying rather than data collecting kind since, as in Philip’s example above, some other kind of exploit would be required to do anything seriously malicious).

Comment by Spolster — December 22, 2006

Rather than simply keeping the user on the current page, might one overload the “back” button to do what s/he expects, coming from the paradigm of pre-Ajax Web apps? That is, might it “undo” the last create/update/delete action executed via XHR? Maybe this feature belongs in a framework. I can imagine an “event stack,” where appropriate “undos” are registered for each C/U/D action, and the Back button executes and discards the top of the stack …

Comment by ARWolff — December 22, 2006

Doing that is about as good as a window opening itself onLoad (then ofcourse that starts a loop)… and then you make the window not open noe, but 2 or 4 versions of itself. i remember when i was about 14 and learning javascript doing that to annoy somebody…

Comment by Dougal — December 22, 2006

If you want to keep a visitor from leaving your page by clicking a link, there’s a much better way to do it:

Don’t have any links on your page! D’oh!

Comment by Michael Geary — December 22, 2006

This is definitely a bad thing. At some point or another, the ability to disable or divert the back button is something every web app developer has wished they had for genuinely useful purposes, but I’m pretty sure that this would be used for far more nefarious purposes. I bet an update to prevent this will make its way into Firefox soon and the other browsers will have to follow suit, so I’m not going to bother with using this for anything because it’s going to stop working soon.

What scares me is that it raises a lot more potential for dangerous XSS attacks. What bothers me is that onunload is supposed to be for cleanup and such, but not for preventing the action that led to the event being fired, which this does, so it really strikes me as a bug.

Comment by Mark Kawakami — December 22, 2006

If the previous page was an RSS feed in IE7, the back button works. :D

Comment by NICCAI — December 22, 2006

I think this is a great idea! I mean, force users to stay on a certain page! Great! The user will understand that he should not visit any other pages apart from the one having this script.

Comment by José Jeria — December 25, 2006


Just came back from my holidays and recognized my link was posted. I read the comments and I came to the conclusion that the severity of this problem doesn’t seem to be understood completely.

I am currently employed as developer and security guy and i did a lot of research around xss, csrf and other web application vulnerabilities. I learned how to use tools like backframe in combination with a xss hole to remote control a whole site. If you manage to get a user on a vulnerable site with the backframe code applied you can use my snippet above to keep him from leaving the site AND you might be able to assure that he event won’t notice. I think this is pretty severe and should be solved by browser vendors.

If you have any questions regarding this issue, don’t hesitate to contact me here or via my site.


Comment by .mario — December 27, 2006

Totally agree with Mario

Comment by L-Argentine Erectile Dysfunction — August 8, 2007

Leave a comment

You must be logged in to post a comment.