5

While reading through the newes OWASP ASVS standard (still beta) I have found a requirement V2.6 saying

Verify that the session id is changed or cleared on logout.

I do not see a clear point why it is necessary to have the session id changed or cleared after logout. It is necessary to have the session invalidated so after logging out no protected resources can be accessed. But why should I want to change the session id? Defense in depth?

EDIT: Another answer to the question.

Improve this question
3
  • If the old session id leaks, the attacker would only have to wait for victim to log in again. Or did I misunderstand? – domen Jul 29 '14 at 13:17
  • Not if I change the session id after logging in. But that's exactly my point. Why do I need to change the session id after logging out? I will still need to change it again after logging in to be secure. Why does this requirement verify only the logout part? – Marek Puchalski Jul 29 '14 at 20:29
  • "This unnecessary requirement has been removed from the current" — Thanks for the link Marek. I was also thinking that it was a waste to have to change the ID on a logout. – Alexis Wilke Aug 6 '18 at 23:49
1

. It is necessary to have the session invalidated so after logging out no protected resources can be accessed. But why should I want to change the session id? Defense in depth?

The Session ID itself can be viewed as a piece of private information that was associated with the authenticated user session. Clearing this ID from the client side ensures that this private value is no longer available.

Yes it is a sort of defense in depth, as you will be able to verify from the client side that the session has changed which would imply that the server does not know anything more about the current session (i.e. not tied to any user account or is holding any private data, etc). If you were reviewing an application against the ASVS standard and you noticed that the Session ID had changed on logout you can be pretty sure that all session data has been cleared and is no longer available from the client. Yes, technically it is possible to code a system to migrate any session data to the new session, but as there is no real reason to do this it is a good measure of the quality of the application's session handling.

In addition, sending the old ID can be done as part of the testing to ensure that it is no longer recognised as an authorised session.

Improve this answer
1
  • "does not know anything about the user" — I think that's exactly why 99% of the systems out there keep a session ID: to be able to continue to track that very user. Actually even some banks do that with their "Remember my User ID" (although at least here they are smart enough to use a random value to represent that user ID and not their actual user ID.) – Alexis Wilke Aug 6 '18 at 23:36
5

Because of possible session fixation: http://en.wikipedia.org/wiki/Session_fixation

In computer network security, session fixation attacks attempt to exploit the vulnerability of a system which allows one person to fixate (set) another person's session identifier (SID). Most session fixation attacks are web based, and most rely on session identifiers being accepted from URLs (query string) or POST data.

Another problem: if user has same session id after logout (even if session contents are cleared), attacker gains possibility to prolong usage of stolen session id. Alice logs in to some site; Attacker steals cookie with session id; Alice logs out of site; Attacker can't use stolen cookie to access the site; Alice logs in to the site; Attacker can use stolen cookie, because Alice's session id is the same;

Rule of thumb is to change session id as often as you can.

Improve this answer
6
  • 1
    Thanks for the comment. I think I understand the concept of session fixation. But the problem you stated can be solved by changing the session id after login. I still do not quite understand, why it is necessary to change the session id after logout. – Marek Puchalski Jul 29 '14 at 20:25
  • @MarekPuchalski You can "change" the session ID to a blank value, which is what I usually see happen upon logout. Some apps do assign new session ID values but I haven't ever heard of a good reason to do this rather than nullify the old one. – PwdRsch Jul 30 '14 at 15:19
  • +1: although I disagree with "as often as you can" - certainly it should have an upper limit on its TTL, and should change whenever your authentication state / authorization changes. – symcbean Mar 14 '18 at 16:16
  • I agree with Marek here, what you describe is a change of session ID after login and not after logout. What is important after a logout is that the session ID is not going to allow you to access private data (pages that require you to be logged in.) – Alexis Wilke Aug 6 '18 at 23:31
  • @AlexisWilke Yes, you are right, but in most frameworks and technologies it is difficult to invalidate sessionId, that's why everybody is saying that you should change it (new session) or destroy it (delete session). – Dissimilis Aug 7 '18 at 11:14
2

It's another way of saying the same thing. The goal is that a malicious user who captures the session id of an authenticated user should not be able to continue to use that session id to interact with the application as the authenticated user after the user has logged out. After log out, the application should no longer recognize that session id. From an implementation perspective this can mean that you invalidate the session, or change the session id on the server so that it can no longer be referenced by the old session id.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.