Session token is an important mechanism in the overall authentication scheme of web applications. Once a user successfully authenticates to the web application, a token is assigned to the user. It is usually a long random number. This token is then shared by the user on subsequent interactions with the web application and is used for re-authentication purpose. Now, the token represents the identity of a user. Session tokens are also used to track user behavior. This mechanism has an inherent problem; if a malicious attacker is able to determine the victim's session token, the attacker can impersonate as the victim.
The session token becomes as important piece of information and needs to be carefully protected with the same vigour as done for the login credentials, because it serves the same purpose as the user credentials.
The various ways to steal tokens are as follows:
- Brute forcing a predictable session token
- Sniffing a token over the wire
- Compromising a session token using client-side attacks (XSS or malicious JavaScript)
- Man-in-the-middle attack
Some web applications still use predictable session tokens that are very easy to guess or brute force. These tokens are generated from a finite series of numbers or in an incremental order. You may find gaps even if the application is issuing token in an incremental order, as other users accessing the application would also be assigned tokens. Other ways of generating token include using the client data, such as username and IP address, and then encoding it to hide it from novice attackers. After collecting a number of tokens, they can be analyzed and the pattern identified to break it.
These two ways to stealing tokens are very similar to each other. Here, the attacker sniffs the communication between the server and the client. The token is then extracted from the sniffed data. The sniffing can be done via a man-in-the-middle attack (MITM) or by sniffing it over the wire. The attacker with the knowledge of token starts accessing the application impersonating the innocent user.
Once a user authenticates, a session token is passed to the web browser. The same session token is then used for future interactions with the web application during the session and saved in the browser. If that application is vulnerable to a cross-site scripting flaw, a malicious attacker could trick the user into running a token stealing script, which would send the token over to a remote server controlled by the attacker.
Zed Attack Proxy, Burp proxy, and WebScarab, which are included in Kali Linux, have inbuilt functionality to gather and analyze token. WebScarab has a feature to analyze and plot the values over a graph. This makes it very easy to visualize the randomness and distribution of session token used by the application over a defined time.
Burp suite also contains a session token analyzer called sequencer. The sequencer functionality is flexible and allows the tester to identify the token manually. In addition to this, it also allows loading a token file saved offline for analysis. It tests the randomness of the tokens against the standards set by FIPS. Detailed explanations are also provided for every passed or failed test.
Session fixation is a flaw wherein a malicious attacker fixes a predetermined session ID on to a user even before the user logs in to the application. The attacker acquires a legitimate session token from the website and tricks the user to use that specific session ID when logging in to the application. Since the attacker already knows the session ID, they can hijack the session of the user too.
Here's a simple example:
- The attacker visits the website and is issued a session ID.
- The attacker then crafts a URL, which includes the session ID assigned to it, and entices the user to use the URL through a phishing e-mail of a forum platform.
- The victim is now connected to the application and tries to log in with the preset session token.
- The victim successfully logs in but is not assigned a new session token, as it already has a valid ID that was fixed by the attacker. Hence, the attack is known as session fixation.
- After the user logs into the application, the attacker can take over the session by using the same session token and impersonate the user.
The following diagram explains the session fixation attack:
The attack becomes very easy if the session token is part of the URL, since creating a custom URL to entice the victim is trivial. The attack becomes more difficult if the session token is passed through a cookie. Setting a cookie on the browser of another user is difficult unless the application itself is vulnerable to a flaw such as cross-site scripting, through which the attacker can set a cookie in the user's browser. Another mitigation step is to design the application to reject any user supplied session IDs. It is the responsibility of the server to create random session IDs and any user supplied IDs should be discarded. To properly manage session tokens, use tried and tested frameworks such as PHP and .NET, which have built-in mechanism for sending and handling session tokens. Another mitigation step is to implement concurrency control.