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!
Comments
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.
Per
Jul 27th 2011
1 decade ago
DDJ
Jul 27th 2011
1 decade ago
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
Chris W
Jul 27th 2011
1 decade ago
DDJ, sorry but as you can read on the original blog post (http://blog.taddong.com/2011/07/owasp-session-management-cheat-sheet.html) 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
Jul 29th 2011
1 decade ago