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:
- Obtain a valid session ID for the targeted application
- Trick the victim into authenticating using that predefined ID
- 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:
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
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
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:
Secureto set and store session identifiers
- Never use
POSTvariables 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 multiple 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.