Web Application Hacker's Handbook - Securing Session Management
Generate strong tokens
It should be extremely unlikely that an attacker with large amounts of bandwidth and processing resources should be able to guess a single valid token within the lifetime of its validity.
- Tokens should use a large set of possible values
- Should contain a strong source of pseudo-randomness
- Should only be an identifier used by the server to locate the relevant user object.
- Should contain no meaning or structure.
- Must use a cryptographically-secure source of randomness.
- For additional entropy, use:
- Source IP and port number
- User-agent from the request
- Time of the request
Good formula for token generation:
- Concatenate (place the most variable towards the start):
- Pseudorandom number
- Request-specific data (e.g. IP)
- Secret string from server that is generated each time the server is booted.
- SHA256 concatenated string.
Protect tokens throughout their lifecycle
- Only transmit over HTTPS (use the secure flag on any cookies).
- Never transmit in the URL. Always use POST requests.
- Implement logout and ensure it invalidates all tokens.
- Minimise session expiration time.
- Ensure that concurrent logons for the same user cannot occur. If an old session identifier is used, the user should be informed.
- If an admin function requires sessions to be viewed, the session token should not be displayed.
- The cookie path and domain should be as restrictive as possible.
To defend the session management mechanims against attack:
- Audit the application's codebase to remove any XSS vulnerabilities.
- If an arbitrary token is submitted, the in-session token should be cancelled and the user returned to the application's start page.
- To protect against CSRF, require a two-step confirmation or reauthentication before a high-risk transaction is carried out.
- CSRF can also be protected against by transmitting the token in a HTML hidden field rather than via a cookie.
- To mitigate against session fixation attacks, always create a fresh session after each authentication.
- A new token is created whenever a user requests an application page.
- Issues - stops backwards and forwards buttons from working.
- Can be used to monitor pages used by the customer and can be used to detect attempts to access functions out of order.
Log, monitor and alert
- Application should monitor requests that contain invalid tokens.
- Where an attacker attempts to generate lots of tokens as part of a guesssing attack, this will leave an obvious mark on the application log.
- To help mitigate against brute-force attacks, you can temporarily block IPs when a certain number of incorrect attempts have been made.
- Users should be alerted to anomalous events (e.g. concurrent logons).
Reactive session termination
- Where an anomoly is detected, the session can be easily terminated by revoking the token:
- Modified hidden HTML field or URL parameter.
- Anything that looks like an SQL injection or XSS attack.
- Any input that would have been stopped by client-side validation.