Implementing Session and State Tracking

Session hijacking is possible mainly when a Web application depends entirely on the client side to keep track of session and state information. In some cases, even when session tracking is performed on the server side, successful spoofing of the session identifier leads to session hijacking. In the case of the Alice Bob Charles attack, Bob easily spoofed the session identifier by reverse engineering. Session identifiers that yield themselves to sequence prediction attacks can end up being the cause of session hijacking attacks. Hence adequate methods of session and state tracking are essential.

Based on our experience in Web application security testing, we have derived the following rules of thumb for implementing proper means of session and state tracking. By no means are they complete or binding for all Web applications. Instead these rules of thumb should serve as guidelines for designing a session and state tracking mechanism.

Session Identifiers Should Be Unique

Again, in every Web application, a logical session has to be established between the browser and Web server. For that purpose a string or a number of pieces of data called a session identifier need to be passed back and forth between the browser and Web server. Preferably, every user session with the application should be identified by a unique session identifier that doesn't get reused from session to session. Even if the same user logs on again, a new session identifier should be generated.

Session Identifiers Should Not Be "Guessable"

An easy way to identify weak session identifiers is to create many user sessions rapidly or keep creating and destroying user sessions in a short period of time. Session identifiers that are serially incrementing, or following a time stamp or other pattern, are cause for concern. Such session identifiers are susceptible to a sequence prediction attack, and an attacker can perform session hijacking by successfully generating session identifiers that coincide with the session identifiers of users who are currently logged onto the application.

An easy way to generate out-of-sequence session identifiers is to use a combination of a random number, the current time stamp, and a secret number to generate a hash from the combination. Hashes also have a low-collision property, which helps in defeating sequence prediction attacks.

Session Identifiers Should Be Independent

Session identifiers shouldn't be derived from usernames, passwords, and application states. Instead, a look-up table should be provided on the server side that maps the session identifier with the user credentials and application state.

Session Identifiers Should Be Mapped with Client-Side Connections

To prevent sniffing and reusing of a session identifier by an attacker belonging to the same network as the application user, the application should keep a track of the client's IP address and time of session creation on the server side. The session identifier should be mapped with the client's connection information. Every time a request is received from the client, the current client connection information should be compared to the stored information. If a discrepancy is noticed, the session should be automatically terminated.

Preferably, the session identifier should be transmitted to the browser over SSL once it has been created on the server side. This action also prevents sniff and reuse attacks aimed at hijacking sessions.