The goal of a session fixation attack is to gain control over a session of an authenticated user, thus giving the attacker full access to the target application with the user’s privileges. To reach this goal, the attacker will force the user to use a session accessible to the attacker, by fixating a known SID in the user’s browser before authentication. When the user has successfully authenticated, the attacker can contact the target application with the same SID, thus impersonating the authenticated user. The figure shows a session fixation attack on a parameter-based session management system.
To launch a session fixation attack against a vulnerable application, the attacker needs to be able to fixate the SID in the user’s browser. The attacker can gain this capability by launching the attack from a Web site, the so-called Web attacker, or through an out-of-band channel, such as email or instant messaging. In the remainder of this section, we discuss ways for an attacker to perform session fixation attacks on parameter-based and cookie-based session management systems.
PARAMETER-BASED SESSION FIXATION
Links. The simplest attack vector is to get the user to go to the target site through a crafted link, that contains a SID embedded as a URL parameter (e.g. <a href=”http://target.example.com?SESSID=A1B2C3D4E5″>Follow me</a>). There are numerous ways of tricking the user into following a crafted link. One example is external channels, such as email messages or instant messaging, where a user is simply asked to open a link. An attacker can also place a link on an unrelated site, such as an attacker-controlled site or a site permitting user content to be posted, such as a social networking site, a forum, etc. Finally, an attacker can also inject a link containing a SID directly in the target site, making it blend in with the rest of the page contents.
Script Execution. If the attacker can execute a malicious script within the origin of the target site, he can easily launch a session fixation attack by replacing the valid embedded SIDs with fixated SIDs. Script execution privileges can be gained legitimately (e.g. an included advertisement), or unintentionally (e.g. through cross-site scripting (XSS)). Unfortunately, vulnerabilities giving attackers script execution privileges are very common, as indicated by the high-ranked spot in both the OWASP top 10 Web application security risks. Additionally, attackers can legitimately gain script execution privileges in numerous ways.
COOKIE-BASED SESSION FIXATION
Script Execution. Similar to parameter-based session fixation (attack vector A2), cookie-based session management is susceptible to session fixation if the attacker gains script execution privileges. The attacker can simply set a fixated SID as a cookie through the document.cookie property. Note that a site with an XSS vulnerability that allows cookie-based session fixation is not necessarily susceptible to other attacks, such as session hijacking.
Headers. The possibility for an attacker to inject headers into the HTTP response allows him to use the Set-Cookie header to fixate a cookie-based SID. The header injection is typically caused by a target site including unsanitized input in header values, or by a parsing vulnerability in a browser or proxy system. Due to the large-scale impact of such a vulnerability in a Web framework, language or browser, these vulnerabilities are typically immediately fixed, making header injection an unlikely attack vector.
Session fixation attacks have been known for some time, and adequate server-side protection techniques are available. Unfortunately, these protection techniques are not always deployed, leaving the user vulnerable to session fixation attacks. We discuss the most important and effective countermeasures below. Session fixation can easily be addressed during the development phase of a Web application, by generating a new session identifier whenever the privilege level of a user changes, for example from an unauthenticated state to an authenticated state. This approach foils any session fixation attacks aimed at obtaining an authenticated session. Even if an attacker forces a session identifier on a user, the session identifier will be overwritten by a newly generated one after authentication. Since the new SID differs from the fixated one, the authenticated user is never linked to the fixated session. This approach works both for cookie-based and parameter-based session management. Most Web frameworks explicitly support the regeneration of SIDs but require the developer to enable it or explicitly trigger it by calling a function.
Furthermore, Web has proposed two more server-side solutions for combating session fixation attacks against cookie-based session management. One consists of instrumenting the underlying Web framework, to automatically regenerate the SID when an authentication process is detected. In a second approach, they propose a server-side proxy that maintains its own SID and couples it to the target site’s SID. Renewing the proxy SID after a detected authentication process prevents session fixation attacks. Both approaches do not require modifications to either the Web framework or the protected site but depend on initial training or configuration to identify the authentication process.