0

According to wikipedia, a transient cookie (aka session-cookie, in-memory cookie) is forgotten when the user closes the browser. These are also recommended for session cookies by OWASP.

I've seen a lot of sites that recommends that you close your browser window to log out (thus deleting this cookie), but that wouldn't unset the logged-in state on the server side. If the users doesn't explicitly click the log out button (they just closes the browser window instead), a man in the middle could catch and re-use that session even after the original user closed the browser window (and thought they logged out).

Wouldn't that also mean that using transient cookies for session management potentially could teach your users that they don't need to explicitly log out - and thus increase the potential effectiveness of a MITM? If the user re-opened the browser and found that they're still logged in, it would teach them that only an explicit logout action will log them out.

So, should i avoid using transient cookies for session management for this reason?

Improve this question

1 Answer 1

Reset to default
0

Transient cookies are only secure if treated the same way as log in credentials. Used properly, they should only be exchanged over an HTTPS connection and the cookie should be marked to only be available to an HTTPS connection. This protects the cookie from a MITM attack.

The cookie is effectively a short term copy of the username and password, so you have to give it the same kind of protection or it becomes insecure.

If the connection is not protected with HTTPS, then it doesn't matter if the MITM grabs the cookie or simply intercepts the request to log out. If the attacker controls what you can and can't say to the server, you are out of luck. It might me a slight bit for a passive attacker that can't alter traffic, but the session should also be locked to the IP, so only an active MITM attacker should be able to make use of the cookie and they could also prevent logout.

Improve this answer
5
  • I agree completely when it comes to using the secure flag for cookies, thus keeping them on HTTPS. Still, this doesn't answer my question - let's say that the MITM (or, let's broaden this to MITB and similar) is still capable of reading the cookie - in that case, using transient cookies may trick the user into believing that they logged out when closing the browser window (when, in fact, the session can still be re-used by someone else after this point).
    – user41333
    Commented Mar 4, 2014 at 21:57
  • @OleMartinHandeland - MITM how? If it is only exchanged over SSL, then MITM isn't possible. If user's machine itself is compromised, the attacker could prevent any attempt to log out too and make it look like clicking the logout happened when really they do their own thing.
    – AJ Henderson
    Commented Mar 4, 2014 at 21:59
  • sslstrip (could render the log-out useless), guessed session id, session id re-use (although that's another problem) and/or an unlocked machine where an attacker could open developer tools and snap a picture of the session id. I know these may be extreme edge cases, but I'm still not quite convinced that not notifying the server about a logout action (and waiting until the session is GC'd) will be more secure than building an application where the user over time learns that the logout button is the only way to end a session.
    – user41333
    Commented Mar 4, 2014 at 22:34
  • @ole session ids should be impossible to guess and if a transient cookie is used then unless the local machine is compromised then the key isn't going to leak. Killing the cookie on browser close is the best possible option since you need some way to keep a session. Yes it is best if they actively log out but there is no way to force that and no substantial attack against the cookie that couldn't be taken against the logout anyway.
    – AJ Henderson
    Commented Mar 4, 2014 at 22:47
  • All right, I'm with you on that one. Thanks a lot! :-)
    – user41333
    Commented Mar 5, 2014 at 9:26

You must log in to answer this question.