Understanding session fixation attacks

How session fixation works

As with other session hijacking attacks, the purpose of session fixation is to obtain a user’s session identifier. However, while other methods attempt to extract the identifier from the user’s browser or web traffic, session fixation relies on tricking the victim into using an identifier that is known to the attacker. While there are many ways to do this, a session fixation attack usually needs to successfully execute three operations:

1. Obtain a valid session ID for the targeted application
2. Trick the victim into authenticating using that predefined ID
3. Access the application to impersonate the victim

Session fixation methods

In the simplest scenario, let’s say a vulnerable application accepts any session identifier via the sid query string parameter. An attacker can use social engineering to get the victim to visit a malicious URL that already contains a fixed ID, such as:

http://banking.example.com/?sid=1234567890

If the victim clicks the link, maybe in a phishing email or social media post, and authenticates with with application, the attacker will be able to use the same link to access the user’s account.

Using a hidden form field

To avoid sending the session ID directly in the link URL, an attacker might craft a fake login form with a hidden field containing the identifier value. The name of this field would match the expected session ID parameter, so a user tricked into submitting this form would log in with the fixated identifier. As before, this is only possible if the application gets its session ID from GET or POST requests.

Bypassing the problem of server-generated identifiers

You might think that only accepting server-generated session IDs would be enough to prevent fixation. However, without additional precautions, malicious users can easily get around this limitation. After all, the attacker can simply visit the vulnerable server as a legitimate user, get a server-generated ID, and then use that value to fixate the user session as shown before.

Setting the session cookie using a header

A similar effect can be achieved if the application is vulnerable to HTTP header injection. By tampering with the web server response, an attacker may be able to inject the Set-Cookie header to specify a known session cookie value. Upon receiving this response, the victim’s browser will set the session cookie as instructed, fixating the identifier.

Setting the session cookie using a meta tag

The Set-Cookie parameter can also be set using an HTML meta tag with the http-equiv="Set-Cookie" attribute. The effect is exactly the same as when using a header but with the added bonus that it even works when JavaScript is disabled in the browser.

Using cross-subdomain cookies

If the server allows wildcard cookies that can be set by a subdomain and apply to the main domain, an attacker who controls attack.example.com can set session cookies that apply to example.com. By tricking the victim into visiting first attack.example.com to pick up a fixated session cookie and then example.com, the attacker can take over the victim’s session.

Reverse session fixation

Session fixation attacks usually involve the attacker impersonating the victim, but all fixation techniques can also work the other way. If the victim can be tricked into using the attacker’s account via a fixated ID, the attacker may be able to access that person’s transaction history to extract sensitive information (depending on the application).

Preventing session fixation attacks

While session fixation attacks are not easy to perform except in the most trivial cases, they are also not easy to completely eliminate. Prevention depends on treating the session ID as highly sensitive data and combining multiple safeguards as a defense-in-depth session management strategy to ensure that attackers can’t access or guess the identifier. The application must also be careful about the values it generates and accepts.

Here is a non-exhaustive list of common techniques for session fixation protection:

• Use cookies marked as HttpOnly and Secure to set and store session identifiers
• Never use GET or POST variables to transmit session IDs
• Accept only server-generated IDs
• Set a time limit for old session IDs
• Generate a new session ID for each request

As with other session hijacking attacks, web application vulnerabilities such as cross-site scripting (XSS) can provide malicious actors with a way to exploit session fixation vulnerabilities. Having a quality web vulnerability scanner in your toolbox is a must, as is using it regularly at all stages of development and operations to ensure web application security. Modern solutions are no longer limited to late-stage testing, so you can fix security issues as quickly and efficiently as possible before they even leave development.