Pushing Left, Like a Boss — Part 5.4 Session Management

It is my firm opinion that only the session management features in your framework, or a third party tool/product used for this sole purpose, should be used to manage identity or a user session. The HTTP 1.1 protocol was never designed to manage these concepts and thus there is no default way built in for it. When you choose a framework, such as .Net, Ruby or Spring, they have built in features to handle this, and you should always use those features. Don’t be tempted to think you can do better on your own, let the experts handle this for you.

Much of the information in this section was learned from the OWASP Cheat Sheet — Session Management, as written by Raul Siles. For a much more in-depth look on this topic, check it out.

Below is general guidance on session management. Again, always use the features in your framework, purchase a third party tool to do this, and as a last resort write your own by following the advice below.

· Session IDs should be at least 128 characters long.

· The session ID should be unpredictable (randomized) to prevent guessing attacks. Use a well-recognized random number generator; do not write custom code for this. Users should receive a new session ID each time they log in.

· The session ID content or value should only be used to identify the session, it cannot also be used for other functionality, such as the user’s ID within the system, a social number or any other direct object reference.

· The session ID should never be passed in the URL, it will be passed in a secure cookie.

· Use the current built-in session management implementation in your framework. I know I said this twice, it’s important.

· The session ID should have an expiration date and/or time, it cannot last forever, even if the user is still logged in.

· The session ID should only be passed over encrypted channels.

· The session should be destroyed after a user logs out.

· Web applications must never accept a session ID they have never generated. In the case of receiving one, this scenario must be detected as a suspicious activity; an alert should be generated and the IP blocked.

· Session IDs should be regenerated during authentication, re-authentication, or any other event that changes the level of privilege with the associated user.

• Keep your frameworks up to date; there’s no sense in using the session management features if your framework is broken. If your framework hasn’t been updated in 15 years the previous advice to use your framework does not apply, and you likely have larger issues on your hands!