The Web is the most widespread and de facto distributed platform, with a plethora of valuable applications and services. Building stateful services on the Web requires a session mechanism that keeps track of server-side session states, such as authentication data. These sessions are an attractive attacker target, since taking over an authenticated session fully compromises the user’s account. This chapter focuses on session fixation, where an attacker forces the user to use the attacker’s session, allowing the attacker to take over the session after authentication.

We present Serene, a self-reliant client-side countermeasure that protects the user from session fixation attacks, regardless of the security provisions – or lack thereof – of a Web application. By specifically protecting session identifiers from fixation and not interfering with other cookies or parameters, Serene is able to autonomously protect a large majority of Web applications, without being disruptive towards legitimate functionality. We experimentally validate these claims with a large-scale study of Alexa’s top one million sites, illustrating both Serene’s large coverage (83.43%) and compatibility (95.55%).

In the past few years, the security community has witnessed a shift in attacks originating from malicious individuals and the organized criminal underground. Attacks usually targeting the server-side of the Internet (e.g. Web, Mail, and FTP servers) are now conducted on the client-side, targeting the site, the user’s browser, or even the user himself. This phenomenon can be ascribed to the enormous expansion of Web sites and Web applications, which currently almost monopolize a user’s online activities. A substantial fraction of these attacks target a Web application’s session management, the cornerstone of any stateful Web application. Session management enables building stateful applications on top of a stateless protocol (HTTP), by grouping multiple related requests together into a session. Each session is assigned a unique identifier and can keep track of session-specific data, such as preferences, user information, or authentication state. Sessions are typically maintained by cookies, part of the HTTP headers, or parameters, embedded in the content.

One well-known session attack is session fixation. In a session fixation attack, the attacker establishes a session between him and the target application and subsequently forces this session into the user’s browser. Any action taken by the user within the application is associated with the user’s session, which is, in this case, identical to the attacker’s session. For example, if the user authenticates herself to the application, the session remembers the user’s information and authentication state. In case of a session fixation attack, the attacker shares the same session, allowing him to perform actions in the user’s name. Session fixation is ranked third in the OWASP top 10 of Web application security risks and is assigned a prevalence of common.

An adequate, widely available by-design mitigation technique for session fixation is to issue a new (thus non-fixated) session identifier whenever the privilege level of a user changes, for example from unauthenticated to authenticated. Unfortunately, studies have shown that security guidelines are not applied as widespread as one would hope or expect, thus leaving the user vulnerable to potential session fixation attacks. We present Serene, a self-reliant client-side countermeasure against session fixation attacks. Serene is compatible with applications using both cookie-based and/or parameter-based session management. The main idea behind Serene is to prevent the browser from sending fixated session identifiers through cookies and to prevent the use of fixated session identifiers through parameters embedded in the pages’ contents. To distinguish session identifiers from other cookies or parameters, we present an elementary algorithm that supports a large majority of sites but still maintains a very low false-positive rate.


Virtually every non-static Web application embodies stateful behavior such as identifying individual users, enforcing access control rules, and distinguishing simultaneously submitted requests. Due to the stateless nature of HTTP, this stateful behavior is enabled on top of HTTP by introducing sessions. Sessions link multiple requests from the same client together and allow stateful information to be accessed and updated during the course of that session.

The de facto implementation of sessions consists of a server-side stored session state, for which the server generates a random, unique session identifier (SID). The client is instructed to include the assigned SID with every request, allowing the server to link multiple requests from this client to the same session. There are two common ways a Web application can instruct the client to include a SID: cookies and parameters. We discuss both approaches separately in the remainder of this section.


Cookies are key/value pairs belonging to the domain that sets them, potentially extended by certain options (e.g. Path, Secure, etc.). The browser keeps track of cookies in the so-called cookie jar. When the browser sends a request to a certain domain, it attaches all known cookies for that domain using the Cookie request header. Traditionally, cookies are set by the server using either the Set-Cookie response header, by embedding a Set-Cookie meta tag in the body, or by including JavaScript that sets a cookie when executed by the browser. Cookies typically belong to the domain that sets them but using the Domain option, they can also be bound to a parent domain (e.g. example.com), in which case they belong to all subdomains of example.com. This feature is often used to share the same cookies among different parts of an application (e.g. login.bank.com and payments.bank.com). Setting the Domain option to a top-level domain (e.g. .com) is not allowed.

Implementing session management using cookies is straightforward: a session is typically created by the server after receiving the first (cookieless) request, and the generated SID is attached as a cookie to the response. The browser stores the cookie containing the SID and attaches it to every request going to this specific domain. Upon receiving a request containing a cookie with a SID, the server can link the request to the associated session. A new SID can easily be assigned by sending the client a new cookie with the same name but a different value, which overwrites the old value.


Since not all clients support cookies, or cookie support can be explicitly disabled by the user, an alternative approach is to include the SID as a parameter in every request to the server. Examples are to include the SID as a parameter in the URL of a link, or as a hidden field in a form element. Maintaining a session this way requires the server to ensure that all URLs pointing to its own domain contain the SID of the associated session. When the user opens a URL with an embedded SID (e.g. by clicking on a link), the browser sends a request containing the embedded SID, allowing the server to extract the SID and link the request to the associated session. Popular Web frameworks offer embedded support for session management, which includes both cookie-based and parameter-based session management. Sites running on top of such a framework can easily support the parameter-based fallback mode if desired.


Attacks on session management are popular since they offer a high reward for the attacker. Successful attacks can involve the attacker making specific requests in the user’s name, or an attacker having full control over the user’s session, allowing him to access all information and perform all actions available to the user. Concrete attack examples include session hijacking and cross-site request forgery (CSRF). Existing work proposes specific client-side countermeasures to prevent both session hijacking and CSRF attacks.


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.


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.


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.


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. 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. At the end of this section, we discuss a real-life session fixation attack where the attacker is able to execute scripts in a subdomain, without having control over the headers.

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. Origin cookies can effectively prevent session fixation attacks from subdomains if both browsers and applications implement and deploy this feature.

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.


While researching possible attacks and defenses connected with session fixation, we encountered a two-step session fixation attack on Weebly, a Web 2.0 site builder boasting a userbase of more than 8 million people. When registering on www.weebly.com, a dedicated subdomain is assigned to the user (e.g. alice.weebly.com). The user can subsequently create her site using a combination of drag-and-drop elements as well as custom HTML, which allows a user to write arbitrary HTML and JavaScript code on her page. Weebly’s cookie configuration settings do not allow a page on a subdomain to steal cookies from sibling domains or the main www.weebly.com domain. This effectively prevents session hijacking attacks that attempt to steal cookie-based SIDs through JavaScript. As discussed in attack vector A6, JavaScript is allowed to create cookies with the domain option set to .weebly.com. This operates as a subdomain-wildcard, instructing the browser to send this cookie to all subdomains of weebly.com. Thus, an attacker can now set a cookie that will be sent to www.weebly.com when the user visits Weebly’s home page. At the same time, we noticed that if a user presents a session identifier to Weebly’s login screen and successfully logs in, Weebly maintains the same identifier. These two “features” provide all the necessary ingredients for a session fixation attack. If a user is lured into visiting a malicious site hosted on a subdomain of weebly.com, the attacker can fixate a cookie-based SID valid on www.weebly.com in the user’s browser. Once the user authenticates to Weebly, the attacker can take full control over the user’s session. All the attacker needs to do, is to poll one of Weebly’s authenticated pages until he is recognized as the logged-in victim.


The divine scriptures are God’s beacons to the world. Surely God offered His trust to the heavens and the earth, and the hills, but they shrank from bearing it and were afraid of it. And man undertook it.
Back to top button