I work with sensitive sites that handle financial information, my code protects more than four billion pounds of assets.

All of our sites have a logout button and in addition use HttpOnly, Secure, Session cookies to maintain a user's session. Although we expect users to click the "Logout" button, we also anticipate that some users will not do this; as a result, we rely on the session cookies to be dropped when the user closes the browser.

Recently it has come to my attention that browsers don't always drop session cookies when you close them. Chrome, specifically, has a "Resume where I left off" feature that persists session cookies after the browser is closed, and what's more this option is selected by default. FireFox has a similar feature.

What additional mitigations have you implemented due to this feature? We considered a few:

  1. OnBeforeUnload/Unload/PageHide handler to drop cookies when the window is closed. Unfortunately you can't drop HttpOnly cookies in this manner.

  2. Very short session cookies that are continually refreshed (every 30 seconds or so) via script. This has issues because some browsers (especially on phones and tablets) halt Javascript execution when a tab is inactive, so this would have the effect of dropping users when they alt tab or switch windows.

  3. AJAX handlers to maintain a heartbeat with the server. Again, this will not work when the tab is inactive.

Is any additional mitigation necessary? Or is it buyer beware if you don't explicitly logout? Curious what other IT professionals have done about it.

Note: We also use a persistent cookie with a ten-minute sliding window, and expire the session on the server side in ten minutes. The point of this exercise is to mitigate malicious activity that occurs within the 10 minute window, e.g. if someone is watching you carefully in an internet cafe and takes over your workstation if you don't log out properly.

  • Can't you just make your session cookies very shortterm lived? Commented Jan 28, 2014 at 18:19
  • We currently use a combination of a persistent cookie (with a 10-minute sliding window) and a session cookie that is supposed to be dropped when the browser is closed. The attack vector I am addressing is a determined malicious user in an internet cafe who seats himself at the user's computer within the 10 minute window.
    – John Wu
    Commented Jan 28, 2014 at 18:37
  • @JohnWu - what would such an attacker be able to do? Just view the balance? I presume to initiate a transaction to a new payee some addition authentication is required, like re-entering their password, or doing SMS verification?
    – paj28
    Commented Jan 28, 2014 at 20:06
  • It's true that actual money movement is protected by out of band, step-up authentication based on risk assessment, and there are other mitigations as well-- really this is just about customer perception. It's shocking when you open up a browser and can see someone else's information.
    – John Wu
    Commented Jan 29, 2014 at 19:35

3 Answers 3


If your site is that sensitive, set a max cookie lifetime of 15 or 30 minutes, rather than lifetime of the browser session. And it's always buyer beware if they are accessing your site from a public location and they don't log out.

This is what I see on any financial site I use, from banks to credit cards to anything else.

Edit: I suppose that's not entirely true. On some sites, they do allow you to "register your computer"... essentially, allow you to bypass some part of the identity check once (or rather, perform additional identity checks before) you've passed it once from that terminal. You might be able to use this method to allow longer lived cookies on a registered terminal, if the user chooses to do so. But when it comes to financial applications, you best bet is always to give the user as little rope as possible with which to hang themselves. Other types of applications are more forgiving.

  • I've added a comment to clarify, 15 minutes is too big a window.
    – John Wu
    Commented Jan 28, 2014 at 18:39
  • With your clarification, if you leave your terminal open with an authentication session, then it's your own fault if an attacker takes advantage of that. With the possible addition of firing off an ajax request to close the session onbeforeunload per your and Adnan's comments, there's not really much else you can be expected to do without making your application completely unusable to legitimate users. Quite frankly, I find a 15 minute session to be almost unusable when I'm at home and may frequently be distracted in the middle of doing something.
    – Jason
    Commented Jan 28, 2014 at 20:16

A combination of properly-used OnBeforeUnload and short-lived cookies can help you achieve what you want.

The basic idea is to send an HTTP request when OnBeforeUnload fires, and the server should reply by invalidating the cookie. In that way, you'll not be limited by the HttpOnly cookie restrictions. Combine that with short-lived cookies that are refreshed with each action taken by the user (each time a user takes an action, send an HTTP request that will set the cookie time to, say, 5 minutes. When the user doesn't take any action in 5 minutes, invalidate the session on the server.

That way, when the user closes his browser, the cookie will be invalidated and removed. If something wrong happens and the user manages to reopens his browser and "Continue[s] where [he] left off", the session will be long expired on the server anyway.

  • Not sure what you mean by "properly-used." The only way I know to make this semi-reliable is to fire a synchronous AJAX request before returning the string in the OnBeforeUnload handler, which would log the user out even if he clicks Cancel in the dialogue-- not a very good user experience. Can you elaborate?
    – John Wu
    Commented Jan 28, 2014 at 19:54
  • @JohnWu - I presume he means fire off the ajax event, and then return nothing, so the browser doesn't popup. Still, I wouldn't normally recommend this. Just live with the 15 minute timeout, and if you need more than that you're getting to the realms of smart cards that must be present throughout the transaction. I presume 4 billion pounds is total assets, not single account.
    – paj28
    Commented Jan 28, 2014 at 20:05
  • @JohnWu The Ajax request is just an extra precaution. The main thing here is the short-lived cookie.
    – Adi
    Commented Jan 28, 2014 at 20:07

I've worked in FS before and I'd say that this is buyer beware. If you're talking business banking or similar (which I'm guessing you are if a 15 minute session expiry is too long) get wording into the contracts about using the system from trusted client systems only. If it's retail banking it should be in user education never to log in from an untrusted system and always to explicitly use the applications log out function.

The risk scenario you're looking at, user logging in from an untrusted system in an untrusted location (e.g. Internet Cafe) has a host of risks as bad or worse than a browser feature storing session cookies. For example probably one risk in that environment is malware on the PC, in which case the attacker can likely grab the cookie, block the users log out request from hitting the server and then keep the session alive themselves...

Another risk in that environment is malware for keystroke logging which unless you're using 2-factor pretty much negates the security of the system anyway (attacker has credentials).

  • I think you've conflated two different risks, (a) the risk that the computer running the browser is compromised, and (b) the risk that the computer running the browser is shared. Maybe I don't want my teenage daughter to view my personal banking information, but that doesn't mean my computer is infected with malware. A workstation in a well-run internet cafe may be locked down, but it is still accessible to customers for normal use.
    – John Wu
    Commented Jan 31, 2014 at 1:33
  • I wouldn't say so, a well run Internet Cafe machine may well be locked down, but in a risk assessment you would never assume that it is, unless you have control over all the Internet cafes which may be used to access the application, which in this case you do not. Commented Jan 31, 2014 at 7:23
  • Agreed, however that does not change my feedback that you are conflating two different risks. There is no mitigation on Earth that will protect a user from a compromised machine, while there are mitigations that can protect against snooping users. The risk of one does not preclude mitigations against the other. Appreciate your comments.
    – John Wu
    Commented Jan 31, 2014 at 20:17
  • well hey I guess that's a difference of opinion then. there is a mitigation as a bank against compromised machines. Transfer the risk to the customers by putting it in the contract that they shouldn't use them :) and the mitigation I put in the answer (advise users to explicitly use the application's log out functionality) applies to the snooping user scenario (not the compromised machine scenario). If the users use the application in that way then AFAIK the remember session functionality doesn't come into play. Commented Jan 31, 2014 at 21:13
  • I think we agree. I would point out that there is a narrow but common use case where the user has entered personal information but has not authenticated (e.g. is engaged in an enrollment workflow to obtain a user name). E.g. enter your SSN so the system can find you. In this case if we store the SSN in the form/post it's stored by Chrome, and if we store it in session it's obtainable via the cookie that is not automatically dropped. We may be left in a situation where we have to add a "Log out" button where the user hasn't even logged in yet.
    – John Wu
    Commented Jan 31, 2014 at 23:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .