Hacking the Session for fun and profit

Intro

This post is about describing from the security perspective how the life cycle of a Web Application should be. By saying life cycle I mean all the stages a session goes through and what are the steps to be taken on order to properly test the session. Very recently I had a discussion about session management with a colleague of mine and he seemed confused about what session management is and how it should be handled. Now if you lookup the OWASP session management cheat sheet you are going to find lots of interesting information overlapping the information presented here but, there is no information in the internet that has a complete and easy to understand guide about how to test a session.

What is a Session and how should it behave

A web application session is a user credential "representative" for as long as the user is logged in (well not always). In more simple words the user credentials after a successful log-in should be translated into one or more cryptographically secure variable that:

1. Should not leak (e.g. no session passed in web application URL) while being valid.
2. Should not be predictable (that is what cryptographically secure means).
3. Should expire under certain conditions (e.g. user log out).
4. Should not be recyclable (e.g. do not save in database). 
5. Should be mascaraed (e.g. do not use the default framework .NET name).
6. Should be tamper-prof (e.g. run regular integrity checks).
7. Should not be cloned (e.g. concurrent log-ins should not be supported).
8. Should be audited (e.g. track user id and session pair and log events)
9. Should have a 1-1 relationship with the username or user id (e.g. one session variable should translate in one username)   

Note: If one or more of the conditions described above is not met then your session is open to be attacked.

Session life cycle conceptual representation

The following diagram shows the session life cycle and how it should be according to me view. The purple color shows what it should be checked, the green shows how to perform hardening, all other is parts of the diagram is about about attacks that can be performed at that specific session stage. The attacks in red are the most critical and should be characterized as high impact attacks, the attacks in yellow should be characterized as medium impact and the attacks in green have information leakage impact in the web application.

  

  

Note: See how the the session attacks performed after the session authorization are all red. Take note also to the fact that almost all attacks concerning session are red.

The following diagram explains the signs used above:

Note: The image above is self explanatory.

The Session Checklist

The following part of the article attempts to specify the exact characyetristics a session should have and what you should check in more detail:

• Session Properties:

1. Session ID Name Fingerprinting
1. Change Session Default Name
2. Use additional proper costume secure tokens
2. Session ID Length
1. Chose Big Length (e.g. the session ID length must be at least 128 bits 16)
3. Session ID Entropy
1. Use true random numer generator for the session
2. Refresh after login
4. Session ID Content (or Value)
1. Don't save critical Web Application Data in session
2. Use meaningless data to the session 

• Session Attributes:

1. Secure Attribute
1. Set secure flag (or simply enforce SSLv3/TLSv1)
2. HttpOnly Attribute
1. Set HttpOnly flag
2. Disable TRACE http method
3. Domain and Path Attributes
1. Restrict Path
2. Do not include cross domain scripts from none trusted third parties 
4. Expire and Max-Age Attributes 
1. Make sure cookies expire after log-off 

• Session Input Validation Defense Mechanisms:

1. Manage Session ID as Any Other User Input
2. Renew the Session ID After Any Privilege Level Change
3. Renew Session after authorizing the session

• Session Leakage

1. Do not pass session into Http referrer header field. 
2. Do not pass session into web application urls.

• Session Termination:

1. Idle Timeout (e.g. after 15 minutes of user inactivity)
2. Absolute Timeout (e.g. force expiration after 3 hours)
3. Manual Session Expiration (e.g. increase user security awareness by giving them de-validation options)
4. Logout Button 
5. Force Session Logout On Web Browser Window Close Events
6. Automatic Client Logout 3 Session Attacks Detections
1. Session ID Guessing and Brute Force Detection
2. Detecting Session ID Anomalies
3. Binding the Session ID to Other User Properties 

• Session Event Auditing:

1. Monitor Session Creation
2. Monitor Destruction of Session IDs 
3. Monitor simultaneous Session Log-ons
4. Export session auditing into syslog format and feed it to an event correlation engine
5. Implement costume e-mail alerts (e.g. for multiple access denied events). 

Cookie/Session token reverse engineering

Questions to answer about cookie reverse engineering:

1. Unpredictability: a cookie must contain some amount of hard-to-guess data. The harder it is to forge a valid cookie, the harder is to break into legitimate user's session. If an attacker can guess the cookie used in an active session of a legitimate user, he/she will be able to fully impersonate that user (session hijacking). In order to make a cookie unpredictable, random values and/or cryptography can be used.
2. Tamper resistance: a cookie must resist malicious attempts of modification. If we receive a cookie like IsAdmin=No, it is trivial to modify it to get administrative rights, unless the application performs a double check (for instance, appending to the cookie an encrypted hash of its value)
3. Expiration: a critical cookie must be valid only for an appropriate period of time and must be deleted from disk/memory afterwards, in order to avoid the risk of being replayed. This does not apply to cookies that store non-critical data that needs to be remembered across sessions (e.g., site look-and-feel).
4. "Secure” flag: a cookie whose value is critical for the integrity of the session should have this flag enabled in order to allow its transmission only in an encrypted channel to deter eavesdropping.

Epilogue 

The diagram shown above should be enough to give you a good information and a new perspective about how session should be handled. Hope this helped.....

Reference:

https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
https://www.owasp.org/index.php/Testing_for_Session_Management_Schema_(OWASP-SM-001)