Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: OWASP Session Management "Cheat Sheet" - SANS Internet Storm Center SANS ISC InfoSec Forums

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
OWASP Session Management "Cheat Sheet"


Application session management (or rather the lack thereof) is still one of the most frequently exploited vulnerabilities in web apps. OWASP contributor and fellow SANS ISC Handler Raul Siles has now put together a nice OWASP cheat sheet on things to consider when designing or reviewing web application session handling.  One of my favorite sentences in there is

The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side,

because not doing so is one of my "favorite" application mistakes when I conduct a penetration test. Times and again do I find session IDs that are actually more than just "random" identifiers. All it takes in such cases is two distinct, valid users .. and looking at their session token readily reveals the non-random portions like account numbers, which can then be manipulated and attacked.

In his write-up, Raul also links to a couple other OWASP cheat sheets that are equally worth reading, like one on cross site scripting (XSS) prevention.  Enjoy!



367 Posts
ISC Handler
About the "omnipresent" logout-button the article mentions, I've always added the simple idle logout measure of having all pages automatically refresh to a logout page after a certain time. This way the user will see that they've been logged out due to inactivity. It can be combined with a simple javascript counter that counts down until the refresh so that the auto-logout won't be a surprise if the user is actually working with the page.

The alternative of invalidating the sessions server side won't be visible to the user until they interact with the server, which can cause unnecessary loss of work when the user uses a page from an already expired session to fill in some data which are refused by the server due to the expired session and most likely lost.

11 Posts
This is all rather academic. Why not just use SSL / TLS and limit the audience that can sniff session information. Fair enough if you are subject to a MITM attack what you say will help by keeping sensitive info on the server. So in truth it does make sense what you say , but you should really encapsulatethis type of information within secure tunnels.
13 Posts
SSL/TLS doesn't help you if you find

1) Session fixation - the session ID doesn't change when you login and logout

together with

2) Cross-site-scripting or other method of stealing or pre-setting the session ID
Per, thanks for the suggestion. From a usability perspective the client-side functionality you mention, very common in several web apps, is highly recommended. I will consider it for a future cheatsheet update.

DDJ, sorry but as you can read on the original blog post ( the cheatsheet is everything except academic; it is based on real-world pentests and common mistakes.

Unfortunately, the usage of SSL/TLS (HTTPS), although extremely important, does not protects against lots of the threats the cheatsheet tries to cover, such as session id guessing, brute forcing, manipulation of your own id, session fixation, session id gathering (XSS), etc. In reality, HTTPS most of the times helps attackers to hide their session-based activities in lots of environments where the encrypted traffic is not thoroughly inspected.

Besides that, one thing is to say "use SSL/TLS", as the industry is aware it must be used (but only recently :( ) and a different thing is to implement it properly (most of the time it is not, and the usage of the "Secure" cookie flag is just one example). The cheatsheet tries to provide lots of best practices to do it properly and effectively.
Raul Siles

152 Posts

Sign Up for Free or Log In to start participating in the conversation!