42

A design pattern I've noticed on internet banking sites is that you get automatically logged out and sent to a warning page if/when you hit the back button on your browser, ending your session and obliging you to log in again.

I'm presuming this is due to some sort of security consideration, but I'm at a loss to figure out what. What is the rationale for this behaviour?

Nick F
  • 545
  • 4
  • 7
  • 5
    Possibly related to ["Are there security advantages gained from forcing a website to be available from just one tab at a time?"](http://security.stackexchange.com/questions/109142/are-there-security-advantages-gained-from-forcing-a-website-to-be-available-from) – Philipp Jan 13 '16 at 15:08
  • Yes, that was definitely the closest question I could find. It seemed to me that the underlying rationale *might* be the same but might not, so I felt it was worth asking about the back button specifically. – Nick F Jan 13 '16 at 15:14
  • 33
    Most of the time this is caused by bad web design rather than security. – André Borie Jan 13 '16 at 15:15
  • 10
    @AndréBorie Imagine a scenario where the back button sends you to a confirmation page which POSTed confirmation that you want to send money to an honorable Nigerian prince and you get that pesky message about re-sending the POST data and you click "Yes, resend". Well now you've sent the prince twice as much money and will never see the $400,000,000 he promised because now he doesn't trust you to use a computer. – MonkeyZeus Jan 13 '16 at 17:39
  • 1
    It's hard to identify their reasoning when we don't know the exact circumstances under which this behavior happens. It could be due to per-request CSRF tokens breaking. The token validation may be failing when the page is reloaded with the back button and they're logging you out due to this 'security violation' as a result. – PwdRsch Jan 13 '16 at 18:34
  • @MonkeyZeus this can be mitigated by using a nonce in the POST request, but IMO that's exactly why the "resend" warnings are in place and I don't think it's the bank's job to fix user's stupidity. If they click through despite being warned, it's their problem, not the bank's. – André Borie Jan 13 '16 at 23:12
  • This reminds me of an annoying bug on a major bank's website: when I intend to transfer money, they provide a last chance to view all the information before clinking the final commitment button. I reviewed it, found that I made a typo in the description field, clicked on the back button inside the website (so not the browser's back button), made my correction, then did this once again.... and was greeted by a message saying that I entered my SMS code wrong 3 times in a row so my account was blocked. – vsz Jan 14 '16 at 07:19
  • @AndréBorie Most businesses are interested in making a profit, and helping your customers make their experience as smooth as possible helps with that. That applies to the stupid customers as well! – Jon Bentley Jan 14 '16 at 17:54

3 Answers3

57

A scenario such banks might want to protect you from could be this:

  1. you visit your banking website and do your banking stuff.
  2. after you are finished you log out and then navigate to some other website to look at cat pictures or whatever.
  3. you leave your computer with the cat picture website open. Because there is nothing incriminating on your screen, you feel safe doing that.
  4. your evil roommate comes along and presses the back button a few times.
  5. they arrive at the cached version of your banking site, see your bank account and see that you still haven't paid your share of the rent even though you clearly have enough money to do that.

That's one reason why banking websites do not work when you navigate to them using the browsers back button.

But an even more likely reason could be laziness on the side of the web developers.

Allowing the user to use back and forward navigation creates an additional variable in a web application which needs to be kept in mind at all times. Simply making this impossible removes that variable and makes it far easier for the developers to create a secure and bug-free application. Because bugs in banking applications can cause quite a lot of financial damage, developers in that sector are rather conservative and tend to limit usability when it results in a more predictable application use-pattern.

Philipp
  • 48,867
  • 8
  • 127
  • 157
  • 8
    What is this *additional variable*? I've done a bit of web development and have never heard of the 'back' button being a problem. Moreover, where is it stored (i.e. client or server)? – Chris Cirefice Jan 13 '16 at 17:26
  • 24
    @ChrisCirefice I don't think 'variable' in this context was meant to refer to a literal variable you'd think of in a programming language that could be stored client or server side. I think he was referring to just a variable in your train of thought, that you constantly have to think about "ok the user hit this part of the application, now what if they hit back". – DasBeasto Jan 13 '16 at 17:33
  • @DasBeasto That makes way more sense, I didn't think about that :) I'm constantly in programming mode, sorry! – Chris Cirefice Jan 13 '16 at 17:35
  • The back button can be a problem is there is user submitted data via a form or AJAX, and they do not want to risk the data being submitted twice accidentally, simply because the back button reloaded the page. – Scott M. Stolz Jan 13 '16 at 17:45
  • 2
    I think the first 70% of this answer misses the boat in terms of OP's flow. However, the concluding paragraph is useful. OP describes being logged in, navigating to the accounts summary, navigating to a monthly report, navigating back to accounts summary, pressing the back button to get back to the monthly report but instead a log out is forced. – MonkeyZeus Jan 13 '16 at 17:54
  • 2
    @MonkeyZeus It is very difficult for the server to definitively tell the difference between your scenario and the one that Philipp describes. It is much easier and more secure to force the user to use the interface as given and disallow the back button altogether. – Dean MacGregor Jan 13 '16 at 17:56
  • 6
    @DeanMacGregor the scenario described in the first 70% of this answer can be prevented without causing the situation which OP is asking about. – MonkeyZeus Jan 13 '16 at 17:58
  • @MonkeyZeus Yes, and perhaps a better way for Phillip to explain this would be pointing out that the first half of his answer *is* solvable, but the second half explains why web developers don't always do this - call it laziness, time crunch, or inexperience, sometimes they just choose to take the easier path. Without the first half of the answer though, the reason behind doing this *at all* isn't explained. Perhaps connecting the two better would improve this answer. – Zibbobz Jan 13 '16 at 21:42
  • 1
    "to look at cat pictures or whatever." - No whatever please. – Top Questions Jan 14 '16 at 07:50
  • 1
    This bank have problems starting from the words "cached version". – Oleg V. Volkov Jan 14 '16 at 19:52
  • Why would this nice answer not mention the possibility of issuing Double Payments by mistakenly going back to a page where you transferred money to someone? – Hanky Panky Jan 15 '16 at 08:04
27

There's a couple of things going on here:

Bankings sites will use cache-control headers to forbid cacheing of the pages. So when you click back the browser has to reload the page from the server.

Some parts of the site may have a strict flow of pages, e.g. you enter transaction details, enter your SMS code, view transaction confirmation. These require strict tracking of what page you're supposed to be on. So if you click back, it breaks this, and you get an error.

It can also occur because of dubious attempts to improve site security. For example, some banks have session tokens in the URL that change with each request, and if you go back your token is now invalid.

There is usually no strict need for the site to have this behaviour. Going back ten years or so it used to be very common, although less so now.

paj28
  • 32,736
  • 8
  • 92
  • 130
8

This isn't as common now, but quite some time ago a lot of websites were just HTML wrappers around classic terminal (IBM 3270 and the like) applications which were being scraped statefully, and this was especially prevalent in legacy industries where the whole idea of a separation between view and model is very, very new. It's possible that a lot of banking websites still are implemented in that way, or that they used to be and still have the back-button-preventing behavior "just in case."

fluffy
  • 1,342
  • 1
  • 8
  • 10