Session Management: Set new value of session ID after privilege change and other sensitive operations

Question

This OWASP Article on session management recommends to set a new value of session ID when:

Common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed.

Please elaborate on the need of this.

Answer 1

It is important to quote the previous sentences too:

The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios ...

In other words, OWASP is summarizing the case where a user changes what he is authorized to do or what he is authorized with. I'll give an example of each case:

1. User changes what he is authorized to do: A user logging in to a different account (e.g. google "log-in as a different user") must have his current session invalidated before he can login in to the other account. This important because you are keeping a session open for a limited time (to make it harder to hijack a session).

   Now, if one of the accounts the user has credentials to is compromised and the other isn't, the attacker could use the overlapping sessions to execute something as the account that he did not manage to compromise. Therefore it is important that the previous session is killed (no matter if the previous or new session it the one that is for a compromised account).

   As an extra, if an attacker can force a user logged in two accounts switch between them repeatedly, you may fail to count the session time and be vulnerable to fixation. It is easier (and less error prone) to simply invalidate the session on spot, than trying clever algorithms to keep both sessions alive. This is less probable, but still a way of increasing attack surface for an attacker.

2. User changes how he is authorized (actually authenticated, but then authorized): A user changing the password must have his old session destroyed on the spot because that is what the user expects to happen. If your session lives for 10 minutes, and a user changes his password he expects than an attacker who he believes has his password cannot access his account anymore. He does not believe that the attacker can use his account for 10 minutes more.

   Note that this is not the same requirement as asking an user to input the old password and the new password on a password change screen. You should definitely do that, since it prevents an attacker in possession of a session ID from changing the user's password. But what that quote from OWASP argues is about the destruction of the previous session the moment that the POST request with the password change is received. So that an attacker in possession of a session ID cannot use the account of that user at the moment when the password is reset.

Answer 2

Consider a common example of privilege change: Amazon.

If you have ever used Amazon, your browser has a persistent cookie that tells Amazon who you are, even if you haven't signed on. When you open up the browser and navigate to Amazon, it'll show your name on the top right and you'll have the ability to add items to your cart. You might call this level 1 authentication.

The level 1 authentication cookie has a very long lifespan (it may be infinite) and is persistent, meaning that anyone with access to your cookie store could steal it.

Now, let's say you've added some items to your cart and you wish to complete a purchase. At this point, Amazon will require you to enter your password. Once you have done so, you have additional privileges. You might call this level 2 authentication.

The level 2 authentication cookie is a lot harder to steal. It is an http-only session cookie and goes away when you close your browser. And it only works for about 30 minutes, I believe.

Note: It is impossible for the server to tell if a cookie is http-only or if it is a session cookie, because a browser only presents the cookie value itself, not its attributes. So from the web server's perspective, everything depends on the cookie value itself.

Now imagine if Amazon didn't bother to switch the session ID when you sign on. Instead, it keeps the same session ID, but stores a session variable indicating the elevated privilege. Here is a plausible attack:

1. Hacker steals your persistent cookie, which will only give him level 1 privileges. No biggie, right?
2. Your browser has an exact copy of this cookie.
3. At some point, you browse to Amazon, decide to complete a purchase, and sign on.
4. The cookie now has level 2 privileges.
5. Hacker has been hitting the Amazon server with this cookie occasionally to see if you have signed on. Once he sees that you have elevated to level 2, he can do anything you can, including send himself an item or changing your password.

If the session identifier changed in step 3, this attack would be thwarted.