Securing Session Management

Methods:

The token should only be transmitted over HTTPS

• The tokens used to reidentify a user between successive requests should be generated in a manner 
• that does not provide any scope for an attacker
• Session tokens should never be transmitted in the URL
• Logout functionality should be implemented. This should dispose of all session resources held on the server and invalidate the session token
• Session expiration should be implemented after a suitable period of inactivity (such as 10 minutes). This should result in the same behavior as if the user had explicitly logged out
• Concurrent logins should be prevented. Each time a user logs in, a different session token should be issued, and any existing session belonging to the user should be disposed of as if she had logged out from it
• A fresh session should always be created after successful authentication, to mitigate the effects of session fi xation attacks.
•  If the application contains any administrative or diagnostic functionality that enables session tokens to be viewed, this functionality should be robustly defended against unauthorized access.
• The domain and path scope of an application’s session cookies should be set as restrictively as possible.
• The application’s codebase should be rigorously audited to identify and remove any cross-site scripting vulnerabilities (see Chapter 12). Most such vulnerabilities can be exploited to attack session management mechanisms. 
• Arbitrary tokens submitted by users the server does not recognize should not be accepted. The token should be immediately canceled within the browser, and the user should be returned to the application’s start page

• Finer-grained control over sessions can be achieved, and many kinds of session attacks can be made more diffi cult or impossible, by using per-page tokens in addition to session tokens. Here, a new page token is created every time a user requests an application page (as opposed to an image, for example) and is passed to the client in a cookie or a hidden fi eld of an HTML form. Each time the user makes a request, the page token is validated against the last value issued, in addition to the normal validation of the main session token. In the case of a non-match, the entire session is terminated 
• The application’s session management functionality should be closely integrated with its mechanisms for logging, monitoring, and alerting to provide suitable records of anomalous activity and to enable administrators to take defensive actions where necessary:
• The application should monitor requests that contain invalid tokens.
• Brute-force attacks against session tokens are diffi cult to block altogether, because no particular user account or session can be disabled to stop the attack. One possible action is to block source IP addresses for an amount of time when a number of requests containing invalid tokens have been received.
• Wherever possible, users should be alerted to anomalous events relating to their session, such as concurrent logins or apparent hijacking (detected using per-page tokens).
•