A session fixation attack enables an attacker to force the victim’s browser to use an existing session, which is also known by the attacker. The goal of the attacker is to wait for the user to perform state-changing actions, such as authenticating himself to the application, after which the attacker takes control of the session. The effects of a session fixation attack are similar to those of a session hijacking attack. Session fixation is categorized as a session management problem, ranked second in the OWASP Top 10. Session fixation is technically more difficult than session hijacking and requires the capability to transfer a session identifier towards the victim’s browser. Unfortunately, no exact numbers of the prevalence of session fixation attacks are available. However, the prevalence of the attack vectors that can lead to a session fixation attack is a good indicator, which is covered during the discussion of related attacks.
The goal of a session fixation attack is to register the results of the victim’s state-changing actions in a session controlled by the attacker. The most prominent example of such a state-changing action is the authentication process, which results in the authentication state being stored in the session. The attacker forces the victim’s browser to use a specific, attacker-known session, allowing him to retake control of this session at any time. If the attacker takes over the session after user authentication, he can effectively impersonate the user.
Fixating a session identifier in parameter-based session management systems is straightforward. All it takes is tricking the user into visiting a URI which contains the fixated session identifier as a parameter in the query string. In essence, session fixation attacks are possible because the session identifier acts as a bearer token for a session between a user and an application, combined with the fact that sessions are easily transferable between browsers. Session fixation and session hijacking attacks both exist for the same reasons, but use a different attack vector to obtain an authenticated session.
Due to the multiple attack vectors that can lead to a session fixation attack, plugging them all is difficult. Nonetheless, protecting session cookies with the Secure and HttpOnly attributes makes the attack more difficult, since it prevents an attacker from easily overwriting an already existing session cookie. However, these protections can be bypassed, for example by overflowing the cookie jar with meaningless cookies, causing the browser to purge the oldest ones (i.e., the session cookie), allowing the attacker to fixate a new session identifier. An effective mitigation technique for fixation attacks consists of sending the user a renewed session identifier after the user changes privilege levels in the application, such as a login or logout operation, accessing an administrative part of the application, etc. For example, by issuing a new session identifier after user authentication, an application ensures that the authentication information is not associated with the fixated session identifier, preventing the attacker from taking over the authenticated session. Renewing the session identifier is the server’s responsibility, and is often supported by the Web programming language or Web framework. No explicit client support is required since the server can just override the already-existing session cookie using a Set-Cookie header.
However, integrating the renewal of the session identifier in legacy applications is challenging. Researchers have proposed several solutions to this problem, both from the server-side and the client-side. A first solution is to integrate the renewal of the session identifier directly in the server-side framework, as part of the session management mechanism. Alternatively, the same approach can be offered as a server-side reverse proxy, which scans requests and responses, and appends an additional, protected session identifier when required. On the other hand, our client-side protection mechanism against session fixation attacks, called Serene, offers protection to a user, without requiring a change or modification at the server-side. Serene is a browser add-on that detects cookie and parameter-based session identifiers in requests and responses and offers additional protection for these identifiers. Serene can prevent cookie-based session fixation attacks through an injection attack vector, as well as parameter-based session fixation attacks.
A variant of a session fixation attack can be carried out by a related domain attacker, who controls an application hosted under the same registered domain as the target application (e.g., example.com). By setting a cookie that applies to all sibling domains, an attacker can easily fixate a session identifier. Origin Cookies protect applications against this kind of attack by allowing cookies to be limited to one domain, preventing manipulation from sibling sites. Origin-Bound Certificates is follow-up research that offers even stronger guarantees but requires a TLS-secured channel to be present.
Modern frameworks all support the renewal of the session identifier, albeit only after explicit actions from the developer to enable this behavior. Additionally, correctly enabling the HttpOnly attribute on session cookies can successfully mitigate certain attack vectors.