Session Management & Access Control - Notes

Session Management Functionality

• Used to uniquely identify a Given User Across multiple requests
• Used to handle the "State Data" associated with a given user's session 
• Helps persist the assurance of a given user's identity beyond the authentication step.

Consequence of Attacks on Session Management

• Attacker can assume the identity of another user without knowledge of their credentials
• Assume identity of admin & own the application.

Why do we need State?

• HTTP is a stateless protocol.
• HTTP has No mechanism to link a series of requests to a particular user.
• Business Applications need a mechanism to keep track of requests coming from the same user. 
• State information can Include - client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details.

How do we maintain State?
Three mechanisms exist

• Sessions are used to maintain state.
• HTTP Authentication can be used to maintain State

1. The credentials are submitted along with each request in HTTP Headers
2. Basic, Digest, NTLM mechanism 

• Sessionless State mechanisms 

1. State data is stored on client
2. State data is stored in a hidden form field or cookie.
3. State data stored on the client must be protected, so it is encrypted or signed.
4. State data should include sufficient context in order to prevent an attacker from replaying it later.

Vulnerabilities in Session Management Mechanism fall in two groups  

1. Weakness in the generation of tokens
2. Weakness in handling sessions tokens

Token Generation Weaknesses

Concerns related to weak tokens apply to

• Password recovery tokens sent to Email
• CSRF tokens
• One time access tokens
• Tokens used for "Remember Me" functionality
• Tokens allowing "Unauthenticated Customer" to see the "Order Status"

1. Meaningful Tokens are weak

Tokens generated using transformation of user-related data 

• Are weak
• Exhibit Structure & are often separated by delimiter.
• Can be broken down into SubParts & Analyzed 
• Subparts can be analyzed for meaning & their function

Attack: 

Such tokens are commonly encoded using XOR, Base64, Hex, ASCII. 

Try decoding various decodings to Unpack the token 

Not all components of a structured token may be processed by the application

--Narrow down on useful components of a token to reduce entropy & complexity.

User "Char frobber" payload type in Burp Intruder to modify a token one character at a time.

2. Predictable Tokens can be guessed

Predictable tokens 

• do not contain meaningful data
• but can be guessed  ( might involve trial & error)
• a sample of tokens can be used to generate other valid tokens

Predictable token are generated using

• hidden pattern (hidden using encoding)
• time dependency - time is used as input to token generation algorithm 
• Weak Random number generator. - sample of tokens can be used to find the sequence of tokens that the algorithm will generate next

Securing Session Management

Generate STRONG Tokens

1. To Generate strong tokens

• Use an extremely large set of possible values
• Use a strong source of pseudo-randomness, to ensure unpredictability.

2. Token should have no Meaning or Structure ( not even hidden or obfuscated structure)

3. Source of randomness should be chosen carefully

• Java.util.Random - can be extrapolated both forward & backward given a single output.
• Java.util.Random - should not be used

4. Use only those algorithms which are "Explicitly" described as "Cryptographically Secure"

5. Along with chosen source of Randomness, Include the following as a source of entropy

• Source IP
• User-Agent
• Time of request in Milliseconds

6. Above sources of entropy will mitigate any weakness in the PRNG

7.  Highly Effective Formula to generate a token

•      HASH (PseudoRandom Number + User-Specific Data + Secret String ( generated fresh on reboot))

Protect Tokens Throughout Their Life Cycle

1. Tokens should only be transmitted over HTTPS
2. Prevent Brute force - Length of token should be at least 128 BITS ( 16 BYTES)
3. Entropy - Avoid Birthday attack - Session ID must provide 64 bits of entropy. Entropy is estimated to be Half of the length of the session ID. So 128 BITS is a good length.
4. We can generate Cryptographically strong session ID using HASH Functions.
5. Cookies should use the "Secure" cookie attribute
6. Application must not accept any cookies submitted through "URL".
7. Use HTTPS throughout the application, including static pages (help & Images)
8. Do not offer public unencrypted contents and private encrypted contents from the same host, instead use two different hosts, such as www.example.com over HTTP and secure.example.com over HTTPS for sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the latter only has port TCP/443 open. 
9. Avoid HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as it can be used by an attacker to gather (or fix) a valid session ID.
10. The session ID must be renewed after any privilege level change within the associated user session. Ex- from anonymous user state to the authenticated state, password changes, permission change, regular user role to an administrator 
11. If multiple cookies are set for a given session, we must verify all cookies (and enforce relationships between them) before allowing access to the user session.
12. Use client side JavaScript code to capture web browser tab or window close event and close the current session before closing the web browser, emulating a logout.
13. Bind the session ID to client IP address, User-Agent, or client-based digital certificate. If a change or anomaly is detected change or anomaly in the middle of an established session, this indicates session manipulation and hijacking attempts.
14. Limit Cookies using cookie scope, and avoid submitting tokens for accessing static resources
15. Never transmit token in URL as it gets logged
16. Cookies disabled ? - Use post request for navigation & store token in hidden form field
17. Logout should be implemented
18. Logout should invalidate the session token & dispose all session related data
19. Session Expiration should be implemented ( keep it small 10-30 mins)
20. Session Expiration should invalidate the token & dispose all session related data
21. Concurrent logins should be prevented
22. A new token should be issued at login, everytime.
23. HelpDesk should not get to see the User-Session-Tokens
24. Domain & Path of "Session Cookies" should be set as Restrictively as possible
25. Arbitrary & Unrecognized tokens submitted by users should not be accepted.
26. Fresh session should be created after "successful authentication" to mitigate session fixation

Session Fixation AttackVulnerability exists when - application does not assign a new session ID after Successful Login
Attack : 1. Attack obtains a valid session by connecting to the application2. Making a user authenticate with that session ID

•     Set the sessionID in the URL
•     Set the sessionID in hidden form field
•     Set the sessionID in cookie, using XSS vulnerability (:P)

3. Then hijacking the validated session

     18. In case where an application handles sensitive credit card data, without authentication
      Ex: Shopping without logging in

• Keep the checkout page sequence really small & generate a new session at first page of this small checkout process.
• Use per page tokens, to be safe from an attacker who knows the token used on first page of the checkout process, from accessing user data.
• Personal data should be masked & not completely shown back to the user.

Cookie Domain Restrictions

Some sub-domains of a given domain may have a lower level or trust, so sensitive cookies should be restricted from being submitted to these sub-domains.

Cookie "domain" ignores both the "Protocol" & "Port", so an application with same domain, but a different Protocol or Port will have access to the cookies.

Cookie is set by "foo.bar.com" & "domain" attribute is NOT set. 

• Cookie is submitted to "foo.bar.com"
• Cookie is submitted to all sub-domains like "admin.foo.bar.com"
• Cookie is NOT submitted to the parent domain - "bar.com"
• Make sure any subdomain is not unsafe

Cookie is set by "foo.bar.com" & "domain = foo.bar.com"

• Cookie is submitted to "foo.bar.com"
• Cookie is submitted to all sub-domains like "admin.foo.bar.com"
• Cookie is NOT submitted to the parent domain - "bar.com"
• Make sure the sub-domains are not unsafe.

Cookie is set by "nuclear.facility.com" & "domain=facility.com"

• Cookie is submitted to "nuclear.facility.com"
• Cookie is submitted to all sub-domains like "admin.nuclear.facility.com"
• Cookie is submitted to the parent domain - "facility.com"
• Cookie is ALSO submitted to all sub-domains of parent domain "unsafeapp.facility.com"

Cookie Path Restrictions

Application at path      /app/secure/a/b/index.jsp   sets a cookie

• Browser will by default submit the cookie to     /app/secure/a/b/         &  its sub-directories
• Browser will NOT submit the cookie to the parent directory

When path is set to "/app/" by the application at    /app/secure/a/b/index.jsp

• Then cookie is submitted to all sub-directories of     /app/

However,

• Path based security mechanism are ineffective, because it is stricter than same-origin-policy
• Its easy to obtain a cookie scoped to a different path
• A malicious path may open a window targeting a different path of same domain & can read & write to that window without restrictions, because same-origin-policy allows this

Per Page Tokens

• A new token is created along with each user request (is stored in cookie or Hidden form)
• Fine-grain control over sessions is achieved
• Both main session token & per-page token are validated with each request
• Online banks uses-per page tokens for increased security

Benefits of per page tokens

• Prevents session fixation attacks
• will block a hijacked session after a single request is made by both attacker & user
• Can be used to track the user's movement through the application.
• Can block attempts to access a functionality out of a defined sequence.

Reactive Session Termination

• Used by online banks
• terminate session every time user submits anomalous request
• can slow down the probing of application by many orders of magnitude.