40

I might be wrong, but I believe the request to close the browser window after logging out is common, though it's completely unclear what the risks might be of failing to close a browser window (assuming the browser is completely up-to-date) and why more importantly browsers are not able to mitigate the threat without closing the browser window. Lastly, is closing the browser better than just closing a window/tab within the browser?

Improve this question
2
  • This all depends on which browser, what they cache, and in what context they cache it. I believe the main concern is cached secure session tickets. But I could be wrong.
    – RoraΖ
    May 20, 2015 at 15:26
  • 1
    It should be noted that, not only is this uncalled for, but in most cases it would not have the presumed effect anyway.
    – AviD ♦
    Aug 6, 2017 at 7:34

5 Answers 5

Reset to default
41

After a bit of searching, it seems some banks are giving this advice following an attack on a bank that allowed users or malicious websites to reuse persistent cookies after a user had logged out, allegedly because other browser tabs were left open on the site in question and so the browser had not cleared the cookies yet.

The reason such a vulnerability would be possible indicates either of the two following security mechanisms has failed:

  • The browser had not imposed a strict same-origin policy between sites, allowing a third-party site to access your bank site's cookies (OR for shared computers, you left a tab open and that tab was used by an untrusted third-party user)
  • The bank website has not, or incorrectly, invalidated your cookies as it has logged you out

As far as I'm concerned, I can already conclude that this "advice" is security theater used by some websites to reject their own responsibilities onto users. Which is, obviously, very wrong as it incentivises users to waste effort and time applying silly measures instead of actually fixing the problem where it occurs.

Websites have two duties when logging a user out, according to OWASP:

  1. Invalidate the user state on the server's side, which will prevent any client query being replayed or crafted
  2. Invalidate the session cookie (as well as cookies that contain information normally accessible only to users authenticated on the website, for web apps) on the browser, to ensure no information remains available for the next user of the client browser
  3. Websites can even go a bit further and ensure that all open tabs on a device are refreshed on user logout. This can even remove the need for users to ensure they closed all their tabs behind them.

Thus, in a world where website developers respect their duties, there should be no basis for following such silly advice. And if websites don't, they're likely to be liable for not taking the necessary means to protect users' personal data.

Improve this answer
17
  • 2
    I concur, although I think this suggestion also stems from multi-tab sessions. In this case, a forgotten tab might contain sensitive data.
    – Zeta
    May 20, 2015 at 17:31
  • I concur with the two security mechanisms have failed portion. I don't think that is a full list however. I would add that you can not trust a browser / OS to always act as they say they will. Outside influences (plugins, other programs, hardware) also can provide security risks. Something as simple as connecting to another network may introduce some unwanted behavior. Also the conclusion that you came to seams kinda strange. From what I read, you have never been placed in a situation where that message may be important (I have not either), I feel that you are limiting the answer.
    – Jdahern
    May 20, 2015 at 19:38
  • 1
    @Jdahern there isn't a point in discussing what to do when the browser is compromised, since in that case all of the previous interactions between the user and server should already be assumed compromised. My point is that even though sometimes it might be good to remind users to close their tabs, training them into shutting down their browser / window / closing all their tabs for every website they log out from is a massive waste of user time/effort/willingness to comply, and that problem can be more elegantly and reliably solved server-side when necessary.
    – Steve Dodier-Lazaro
    May 20, 2015 at 20:23
  • 4
    @Jdahern I'm extremely conservative when people tell users to do things, because some naive or uneducated users (i.e. the majority of people without a CS degree) will try to obey any practice given to them and develop rituals where they keep doing something but don't really know why, sometimes misapplying advice, sometimes overapplying it. We should only bother users when it is strictly necessary, not when we can't trust professionals to do their jobs properly. See is.uni-muenster.de/security/publications/…
    – Steve Dodier-Lazaro
    May 21, 2015 at 0:40
  • 1
    Since not every browser acts the same, and plugins and local security software (or proxies) may alter this behavior, I think the advice is a good way to ensure a consistent security posture. Here is an example of why this is needed, because some apps/proxies may cause prior session/SAML auth to be cached. Some SAML providers (facebook, and older ADFS in non cluster mode) are affected security.stackexchange.com/q/8404/396
    – makerofthings7
    May 21, 2015 at 1:10
8

You should close your web browser (to avoid private information disclosure) if...

  1. Someone might access the computer after you do

  2. The HTTP response (of the sensitive info) does not set the Cache-Control header properly

For example, go to yourbank.com, and look at your account. Click logout. Click the back button. Do you see your account info? On some sites you will, on others you won't, depending on that cache header.

Go to yourbank.com, and look at your account. Note the URL. Click logout. Close your browser (all windows/processes). Open your browser again with the noted URL. Do you see your account info? You should not.

The correct HTTP header is:

Cache-Control: no-store, must-revalidate

For the case where a user might have the same site open on multiple tabs (but only logs out of one), you can make the browser reload the page (thereby showing the login screen) by using the following header

Refresh: N

Where N is the number of seconds until the user's session expires + a small buffer. It would still be vulnerable for a period, but not forever.

Improve this answer
5
  • 1
    If you use a computer in a library, the one who is a risk is the user who used the computer before you and what he had the freedom to install. If you close your browser or not won't alleviate this risk. Hence the recommandation to close your browser is false security.
    – dan
    May 25, 2015 at 22:51
  • @danielAzuelos a library was just an example. Your family members or co-workers probably aren't installing malware on your computer, but might be tempted to look at your email
    – Neil McGuigan
    May 25, 2015 at 23:06
  • I'm not sure I understand this answer...perhaps it could be improved just a bit? What does the first sentence refer to ("You do...")? You do what? Also, doesn't this presume that closing the browser window will empty the cache? Is that really a safe assumption?
    – camdez
    May 25, 2015 at 23:23
  • @camdez I made the first sentence more explicit. If you doubt my claim please provide an example. Every web app framework that I've seen sets Cache-control: private, no-cache (for serverpage type pages), which prevents cache to disk if close browser, but still suffers from the back button problem.
    – Neil McGuigan
    May 25, 2015 at 23:36
  • @NeilMcGuigan Thanks for the clarification. I'm actually not trying to dispute anything, just trying to make sure the implications have been considered. Even better if they're spelled out, like this.
    – camdez
    May 26, 2015 at 3:20
6

This advice is often given for Single Sign On (SSO) solutions. This is for a collection of systems, where a user only logs in once. The authentication of the user is handled by a central system called the Identity Provider. After login, two sessions are established with the requested system and with the Identity Provider itself. When visiting a new system the existing session with the Identity Provider is used to create a session with this new system without asking for credentials again.

Realising single log out (SLO) is a complex problem as you must invalidate sessions of each visited systems. SLO is often implemented by just giving this advice to close the browser thereby invalidating all sessions credentials.

Improve this answer
2

This technique is often used when a website uses basic or windows authentication since there isn't a way to "log out". Instead of using cookies, the authentication mechanism is added as an Authorization header to every request sent to the website. For basic authentication it would be the username/password in a base64 encoded string and for windows authentication it contains values pertaining to NTLM or Kerberos auth. Thus closing the browser is the quickest and safest remediation.

This is in contrast to using forms authentication where a session can be closed by simply expiring the cookie and removing the session from the application.

Improve this answer
2
  • IE (and presumably Edge) have the document.execCommand("ClearAuthenticationCache") JS function, while will log you out. For other methods, including cross-browser ones, see the various answers on stackoverflow.com/questions/233507/…
    – CBHacking
    Sep 12, 2016 at 21:43
  • @CBHacking That link basically contains a user-unfriendly hack for the general case that depends on users being willing to deal with inputting credentials twice.
    – oligofren
    Oct 31, 2018 at 13:08
0

It's hard to know what the banks are thinking, but there's a real benefit to closing your browser after you've logged out of a bank or another sensitive site.

Browsers aren't perfect, and are never going to be perfect. The browser memory space may contain sensitive information like usernames, passwords, tokens, account balances, etc. This SHOULD be unavailable to an attacker, but as we all know no program is completely secure. As we saw in Heartbleed, an exploit has the potential to leak that sensitive information to 3rd parties. Closing the browser and starting an entirely new process clears out the memory and removes this potential avenue for leaks.

Improve this answer
12
  • 1
    that is only true if we could trust all OS'es to correctly clear memory (including the stuff in the page file / swap). Unfortunately we can't due large to the same point your making. 'no software is perfect' ;)
    – LvB
    May 25, 2015 at 23:36
  • I don't know about ALL, but Windows, Linux and MacOS clear the memory of new processes. Software's flaws are related to the complexity. Clearing memory is incredibly trivial. Especially compared to keeping an application secure.
    – Steve Sether
    May 26, 2015 at 4:23
  • would now be a good time to talk about cold boot attacks? :)
    – schroeder ♦
    May 26, 2015 at 17:45
  • 1
    @LvB Linux certainly DOES zero out the memory when it's given to a new process. See this answer: security.stackexchange.com/questions/42179/… It'd be a huge security problem if this wasn't the case as Linux started as a multi-user shared memory environment. MacOS has similar roots, and I'd be very, very surprised if Windows didn't do the same.
    – Steve Sether
    May 26, 2015 at 21:43
  • 1
    Your missing the point. The memory is still there. And an attacker could read it if he uses the low level memory read. It is the main reason why you zero out encryption keys yourself and not let the software do it for you. it's a specific and crucial difference of working I expect a security professional to be aware of. (Since many programmers are not)
    – LvB
    May 26, 2015 at 22:09

You must log in to answer this question.

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