Session fixation

Session fixation is an attack in which a victim authenticates using a session identifier already known to the attacker, and the application keeps that identifier usable for authenticated access.

The identifier survives the sign-in

A web application may create a session before the visitor signs in. Fixation becomes possible when an attacker-known identifier remains usable for authenticated access after the visitor signs in.

Fixation starts before authentication: the attacker gets the victim to use an identifier the attacker knows. This differs from stealing an authenticated session credential after sign-in. Either mechanism can lead to unauthorized use of the victim’s session if the application accepts the credential.

What makes it exploitable?

Two things must line up: the attacker can get the victim to use an identifier the attacker knows, and that identifier later authorizes access to the victim’s account. An unchanged cookie value alone does not establish either condition.

In an authorized test, follow the identifier across sign-in and check whether the old value still works for a protected request. Keep the result separate from whether an attacker could plant that identifier in the first place.

What the application owner should check

OWASP recommends renewing session identifiers when privileges change, including authentication, and invalidating the previous identifier. Check the framework’s session behavior and the server’s rejection of the old credential after sign-in.

Encrypted transport and cookie protections do not fix an application that continues accepting an attacker-known identifier after sign-in.

Sources

See it in practice