People's Newsroom

SESSION FIXATION

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.

Meta-tags. The HTTP-Equiv attribute supported by HTML meta tags enables several header-like instructions, such as setting cookies. Placing the following code in an HTML page results in the creation of a cookie with name foo and value bar: <meta HTTP-equiv=”Set-Cookie” content=”foo=bar; Path=/;”/>. By injecting such a tag in the target site, an attacker can easily fixate a SID in a cookie. Meta tags are typically included in the header of a page, but an investigation of major browsers shows that meta tags found in the page’s body are also honored. Additionally, some browsers also process dynamically included meta tags (e.g. from JavaScript using the appendChild operation). Similar to script execution, this attack vector can be exploited through legitimate means (e.g. an included advertisement) or through an injection vulnerability. Note that for meta tag injection, it suffices that the injection vulnerability allows the injection of an HTML tag. A full-scale cross-site scripting vulnerability is not required.

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.

Subdomains. As discussed before, cookies set from a subdomain can apply to other subdomains as well, using the Domain option. This feature becomes problematic when not all subdomains belong to the same entity, and the attacker controls one of them. An obvious way for the attacker to attack a target site sharing the same parent domain is to set a cookie for the parent domain through an HTTP header. If the attacker fully controls this application, setting cookies through HTTP headers is trivial. In cases where the attacker has no control over the headers (e.g. limited hosting with only static pages), he can achieve the same goal by including a meta tag in one of his pages or by setting a cookie from JavaScript through the document.cookie property.

CURRENT COUNTERMEASURES

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.

Instead of focusing on the value of the SID, several approaches aim to generally protect cookies. One example is the HttpOnly option that can be added to a cookie, preventing JavaScript from reading that cookie, foiling traditional session hijacking attacks. Recently, browsers started preventing an HttpOnly cookie to be overwritten from JavaScript, thus severely limiting the window of opportunity for a session fixation attack using attack vectors A3, A4, and A5 (i.e. fixation can only happen before the user received a SID from the server). As indicated by other studies, the use of HttpOnly is still fairly limited. Web proposes to limit cookies to their origin, thus preventing the sharing of cookies across subdomains. Origin cookies can effectively prevent session fixation attacks from subdomains if both browsers and applications implement and deploy this feature.

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.

Back to top button