41

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?

Steve Dodier-Lazaro
  • 6,798
  • 29
  • 45
blunders
  • 5,052
  • 4
  • 28
  • 45
  • 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 '15 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](https://security.stackexchange.com/q/43809/33). – AviD Aug 06 '17 at 07:34

5 Answers5

40

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.

Community
  • 1
Steve Dodier-Lazaro
  • 6,798
  • 29
  • 45
  • 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 '15 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 '15 at 19:38
  • @Zeta Even in that case though wouldn't the prefered solution be to automatically clear all sensitive data from the browser tab after the user signs out? (E.g. Using JavaScript.) – Ajedi32 May 20 '15 at 19:42
  • @Ajedi32: The browser might have disabled both refresh and JavaScript (the banking service I use forces a refresh every 15 minutes); if JavaScript is enabled, one can simply use websockets or polling, so that isn't a problem. On a slightly unrelated note, this is the reason I usually use a private window for banking. If I close that window, I know that the rest of my browsing session isn't affected, and I don't have to worry about forgotten tabs (unless I'm using very old versions of FF). – Zeta May 20 '15 at 19:44
  • @Zeta Well, for that case you could always just write `` in the tab the user just signed out in. That way there's no need to bother the users who _do_ have JavaScript enabled. That is a good point though. – Ajedi32 May 20 '15 at 19:49
  • 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 '15 at 20:23
  • @SteveDL I never said that the browser was compromised. Its more of that it can cause un reliable behavior. Maybe the user does not have control over cache as in a corporate computer. Even in stock setups can have un expected behavior, in IE11 you cant disable the autocomplete on password fields. The op asked for reasons why(which you gave two good points). I gave a reason to not limit your answer. While your point about responsibility is very valid, it is also very close minded. Yes we should not push off that responsibility, but at the same time, is saying that pushing responsibility? – Jdahern May 21 '15 at 00:04
  • 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 http://www.is.uni-muenster.de/security/publications/BG2011_Security_Cost_of_Cheap_User_Interaction_NSPW.pdf – Steve Dodier-Lazaro May 21 '15 at 00:40
  • By the way, it's also the role of the web app to tell the client to cancel relevant cookies (https://www.owasp.org/index.php/Logout). I'll make that more explicit! – Steve Dodier-Lazaro May 21 '15 at 00:41
  • 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 http://security.stackexchange.com/q/8404/396 – makerofthings7 May 21 '15 at 01:10
  • @LamonteCristo proxies should not be a problem, since we're talking about an encrypted connection here, unless users accept going through a proxy that MITMs and effectively does cache users' sensitive information... Do you have any example of software / extensions that would perform such duties and would be expected to be installed in a kiosk environment? – Steve Dodier-Lazaro May 21 '15 at 01:23
  • It's sound advice, not "security theater". Closing the browser clears out all the memory in use. Memory that may contain sensitive information like session cookies, usernames and passwords, balances, account numbers, etc. Restarting the browser process gets a new set of memory, so any potential exploit on the browser won't be able to compromise any of this information. – Steve Sether May 25 '15 at 22:57
  • @SteveSether if the exploit was run *before* you closed the browser tab, you'd be compromised. If it is run *after* and your browser gets compromised, it means that only the sandbox model is broken but also that the browser doesn't clean memory properly. Browsers should actively overwrite memory that contains passwords or other sensitive information before releasing it. Of course using a separate browser instance is useful when stronger guarantees are wanted by the user, but it shouldn't become a mundane way of interacting with the browser to compensate for faulty implementations. – Steve Dodier-Lazaro May 26 '15 at 10:41
  • @SteveDL I'd trust the OS to clean an entire memory space before I'd trust a browser to figure out which parts of the data are sensitive, and which aren't. (Which is impossible to do since the browser can't possibly know that). – Steve Sether May 26 '15 at 14:08
  • @SteveSether browsers should know how to release the data used by a renderer process when closing a tab or switching to a new site. I perfectly agree with you that the OS gives a better guarantee, but not that this better guarantee is worth the cost of expecting users to shut down their whole browser every time they're done browsing a somewhat-valuable site. – Steve Dodier-Lazaro May 26 '15 at 15:25
  • @SteveDL Closing the browser is incredibly easy, and far less troublesome than running noscript or some other form of disruptive security technology. It's easily worth the minimal cost of the 3 seconds it takes to re-launch the browser. I don't think there's any expectation involved. People will do what they please. The bank (and myself) are just offering simple things you can do to increase your security. I've been closing my browser now whenever I go to a bank or other financial institution for several years now. – Steve Sether May 26 '15 at 17:38
  • More than 5 years later, I still see corporations telling customers to close their web browsers after logging out of web sites. – RockPaperLz- Mask it or Casket Oct 07 '20 at 13:45
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.

Neil McGuigan
  • 3,379
  • 1
  • 16
  • 20
  • 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 '15 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 '15 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 '15 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 '15 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 '15 at 03:20
5

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.

dan
  • 3,033
  • 14
  • 34
Jasper
  • 151
  • 1
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.

user2320464
  • 1,802
  • 1
  • 15
  • 18
  • 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 http://stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication – CBHacking Sep 12 '16 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 '18 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.

Steve Sether
  • 21,480
  • 8
  • 50
  • 76
  • 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 '15 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 '15 at 04:23
  • would now be a good time to talk about cold boot attacks? :) – schroeder May 26 '15 at 17:45
  • We can talk about cold boot attacks right after we talk about rubber hoses and bribery ;) – Steve Sether May 26 '15 at 17:49
  • @SteveSether than why do you list 2 OS's that do not do that and 1 were most distro's do not do that. The only clear memory if someone explicitly programs that in. I'm not sure about SELinux maybe that one does. But simply relying on the OS to clear it is incorrect. The browser does clear memory before it uses it (as most programs do). That's not what you are saying though. – LvB May 26 '15 at 21:30
  • 1
    @LvB Linux certainly DOES zero out the memory when it's given to a new process. See this answer: https://security.stackexchange.com/questions/42179/is-there-any-linux-distro-or-kernel-patch-that-wipes-a-process-memory-space-aft 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 '15 at 21:43
  • That question says the same as I do. Linux does not zero out memory when releasing memory. It can do this when you request it (it further list a patch that does make the Linux kernel zero out the memory) . Whether the memory is zeroed out or not when claiming the memory slot is depended on what actual call is used. Most libraries and languages do it for you. But there are no guarantees from the OS. – LvB May 26 '15 at 21:53
  • You're really splitting hairs here. The point is the memory isn't available to another process. – Steve Sether May 26 '15 at 21:58
  • 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 '15 at 22:09
  • I think you really have the wrong idea about security. Security is never about can, it's always about risk and likelyhood. It's very, very unlikely that a browser exploit is going to result in the ability to read arbitrary, unitialized memory spaces. That would take a kernel level break. I'm aware that encryption keys should be zeroed out, but I think you're really not seeing the point here. I'm afraid I can't make you see it either. – Steve Sether May 27 '15 at 02:52
  • Linux doesn't actually zero out memory of processes, it simply gives all _new_ processes pages that point to the zero page and use an actual physical page only when a write is attempted and a page fault results (in which case it doesn't zero it anyway because it is, naturally being written to. Reads just read the zero page). Unless you are using PaX or enabling expensive memory poisoning, memory is not actually _wiped_. – forest Sep 22 '18 at 06:15
  • I also find it kind of amusing that the claim is that it's very unlikely for a browser exploit to allow arbitrary memory reads in 2015, since a year later, Meltdown and Spectre came out! Never say never. – forest Sep 22 '18 at 06:18