Session Fixation is a type of attack on web application users where an attacker is able to trick a victim into using a Session ID which is previously known to them.

When the victim makes use of the known Session ID in their requests to a vulnerable application, the attacker is able to exploit this vulnerability to make their own requests using the same Session ID – carrying out actions as if they were the legitimate owner of the Session. This attack differs from Session Hijacking, in the fact that the Session ID is previously known to the attacker and is forced onto the victim, as opposed to the attacker discovering the token through another vulnerability.

Why do we need sessions ?

The HTTP protocol that is used by web-based applications is designed to be ‘stateless’, meaning that each request handled by the server is processed individually and is not treated as being related to previous requests. The problem is that most web applications need to keep track of user’s actions across multiple requests, and remember certain information about the user while they are active. This is called the user’s ‘Session’.

Each Session consists of data held on the server which is associated with a Session ID of some kind, which is passed by the user’s browser with each HTTP request. Data that’s held in sessions often includes sensitive items, such as: shopping cart contents, identity information and authorisation levels.

Session Fixation

In a Session Fixation attack, a victim is tricked into using a particular Session ID which is known to the attacker. The attacker is able to fool the vulnerable application into treating their malicious requests as if they were being made by the legitimate owner of the session. A typical scenario involves the attacker prompting their victim into clicking on a link which directs them to sign in, while also supplying a Session ID. The server accepts the Session ID, and populates the session with information about the authenticated user. The attacker is then able to carry out actions in the application as if they were the victim by passing the compromised Session ID along with their requests.

Many developers think that simply using server-generated Session IDs is enough to prevent Session Fixation attacks; however, the example in the following diagram shows that this is not the case. The attacker only needs to extract the Session ID from their own cookie before sending it to the user:

In a variation of the attack, the attacker could make use of subdomains under the target domain which they control, to allow them to set a wildcard cookie after tricking the user into accessing a malicious link. This takes advantage of the fact that web browsers will send wildcard cookies to any subdomain of the site which set them. It’s worth noting that there may even be no need for the user to actually log into the vulnerable application, as simply browsing through public areas on some websites may be enough to leak sensitive information to the attacker, such as shopping cart contents or credit card details filled in during the compromised session.

The impact to the victim of the attack and the owners of the website will vary, depending on the type of application and the nature of the data stored within the compromised user session. At a minimum, a successfully exploited Session Fixation could lead to a loss of privacy allowing the attacker to obtain sensitive information entered into the application by the victim. In a more serious case, it could lead to the takeover of the victim’s account if the attacker is able to authenticate with the application using the stolen Session ID.

If administrator accounts are compromised using this vulnerability the attack could be used to make other attacks possible, such as altering the configuration of the application or extracting data from backend databases. The organisation is likely to suffer damage to their reputation and lose the trust of users who have had their accounts compromised by the attack.

Testing for Session Fixation vulnerabilities

The most common type of Session Fixation vulnerability comes from a failure in the application to issue a new session token after login. Testing an application for this is fairly straightforward and can be performed using a web browser and a proxy application (such as Burp Suite or ZAP Proxy) using the following process:

1. Browse to the application login page and check the HTTP Response in the proxy for a cookie containing the Session ID
2. Note the value of the Session ID
3. Sign into the application, and check the HTTP Response from the application
4. If the response does not issue a new session cookie, then the application may be vulnerable to Session Fixation

In addition to testing how the application behaves during login, it’s also worth checking whether the application accepts a Session ID passed as a URL parameter, since this makes it especially easy for an attacker to force the Session ID onto a user through the use of a malicious link.

Ensuring cookies are handled correctly plays an important role in preventing certain types of Session Fixation vulnerabilities, as cookies which are scoped to their root path or which are valid for wildcard domains may allow a Session Fixation vulnerability to be exploited.

How to prevent Session Fixation vulnerabilities

The countermeasure for a Session Fixation vulnerability is to code the application in such a way that prevents the application from accepting a token that has been forced onto a victim’s session.

The following steps provide a robust way in which to secure a web application against these attacks:

Don’t accept Session IDs in GET or POST parameters

This makes it much harder for an attacker to exploit, since it’s simpler to trick a victim into making the request without the need for browser vulnerabilities. Additionally, all Session IDs should be server-generated; there should be no need for the client to propose a new session ID for the application.

Change the Session ID after login

The server should generate a new Session ID and set it as a cookie after the user has signed in. Any existing session for the user should be destroyed on the server.

Provide a logout feature and expire old sessions

The user should be able to choose when to end their session with the application, which should immediately terminate any current sessions on the server and not simply delete the cookie from the browser. Session data should also time-out automatically after a certain period, to reduce the time window an attacker can make use of a compromised session.

References

https://www.owasp.org/index.php/Session_fixation