Session Fixation ¶

Session fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existing session ID. The attack consists of inducing a user to authenticate himself with a known session ID, and then hijacking the user-validated session using the exposed secret session ID. The attacker has to provide a legitimate session ID and try to make the victim's browser use it.

The session fixation attack is a class of session hijacking, which steals the established session between the client and the web server after the user logs in. This attack fixes an established session on the victim's browser, so the attack starts before the user logs in.

Exploitation¶

There are several techniques to execute the attack; it depends on how the web application deals with session tokens. Below are some of the most common techniques:

• Session token in the URL argument: The session ID is sent to the victim in a hyperlink and the victim accesses the site through the malicious URL.
• Session token in a hidden form field: In this method, the victim must be tricked to authenticate in the target Web Server, using a login form developed for the attacker. The form could be hosted in the evil web server or directly in HTML formatted e-mail.
• Client-side script
  • Most browsers support the execution of client-side scripting. By embedding malicious code in a hyperlink sent to the victim, an attacker could leverage a Cross-site scripting (XSS) vulnerability to inject Javascript code into a user's browser. Using the document.cookie variable, the malicious script could fix the value of the session cookie.
• <META> tag
  • <META> tag also is considered a code injection attack, however, it is different from the XSS attack. While undesirable scripts can be disabled, it's nearly impossible to disable the processing of <META> tags in browsers.
• HTTP header response
  • This method explores the server response to fix the session ID in the victim's browser. Including the Set-Cookie parameter in the HTTP header response, the attacker is able to insert the value of session ID in the cookie and send it to the victim's browser.

Prevention¶

Most of the attack vectors described above require the web application to accept the session ID given in the request. Don't just accept a session ID from the client. Before the application accepts the session ID, it should validate it to make sure there actually is a session open with that key.

Some of the attacks above involve an attacker setting the victim's session ID before they log in. When the victim logs in, the application keeps that session ID but authenticates the user. The attacker now has access to an authenticated session. To prevent this, it's important to change the session ID when a user logs in. And be sure to invalidate sessions when the user logs out.

---

• Version: latest
• Edited by Craig Younkins on 4/9/12 11:41 PM
• History
• Edit

Wiki content is available under a Creative Commons 3.0 License.