People's Newsroom


A session hijacking attack allows the attacker to transfer an authenticated session from the victim’s browser to an attacker-controlled browser. Using the transferred session, the attacker can impersonate the user, and perform all actions available to the user. Session hijacking, together with other session-related problems, is ranked second in the OWASP Top 10. Additionally, with the ubiquitous, freely accessible, unprotected wireless networks, session hijacking has become a straightforward attack.


The goal of a session hijacking attack is to transfer the user’s authenticated session to a different machine or browser, enabling the attacker to continue working in the victim’s session. To achieve this, the attacker hijacks the session that the user has established with the target application. Note that if the attacker manages to hijack an unauthenticated session, he simply has to wait until the user authenticates himself since this state will be stored in the serverside session object. Technically, once a session between the user’s browser and the server is established, future requests will be handled within the context of this session. The de facto standard session management mechanism in modern Web applications is cookie-based, where a random, unique session identifier is stored in a cookie within the browser. In a session hijacking attack, an attacker succeeds in stealing the session identifier, which he can subsequently use to send requests to the server. This is possible because the session identifier acts as a bearer token, and the mere presence of this identifier in a cookie attached to the request suffices for legitimizing the request within the session.

Depending on the security parameters of the cookie, an attacker has several ways of obtaining the session identifier. One way is by calling the document. cookie property from within the target’s application origin, which can for example be achieved through cross-site scripting. Another way is by directly accessing the cookie store from a compromised browser, for example by installing a malicious browser add-on. A third alternative is by eavesdropping on the network traffic, and snatching the session identifier from the response, or any subsequent request, as illustrated by point-and-click tools such as Firesheep. Finally, a weak or predictable session identifier can be guessed or obtained through a brute force attack.

An alternative session management mechanism is based on URI parameters, including a session identifier as a parameter in the URI in every request to the application. This mechanism is often used as a fallback mechanism for browsers that do not support cookies or refuse to store them. Technically, little few changes for a session hijacking attack, other than the means to obtain the session identifier. An attacker can still access it from JavaScript or eavesdrop on the network to extract it. Additionally, an attacker can attempt to trigger a request to an attacker-controlled resource, hoping that a Referer header will be included, since it contains the full URI, including the parameter with the session identifier. In essence, a session hijacking attack is possible because the session identifier, which acts as a bearer token for an authenticated session, is easily obtained and transferable between browsers. Making the session identifier accessible through JavaScript or by eavesdropping on the network is a suboptimal decision, which enables a highly dangerous and harmful attack.

Mitigation Techniques

A traditional mitigation technique for session hijacking is IP address binding, where the server binds a user’s session to a specific IP address. Subsequent requests within this session need to come from the same IP address, and any requests coming from another IP address will be discarded. While this mitigation technique works well in scenarios where every machine has a unique, unchanging public IP address, it is ineffective when the same public IP address is shared among multiple machines, or when the public IP address changes during a session. Precisely these two cases have become ubiquitous in modern network infrastructure, with NATed home and company networks, publicly accessible, shared wireless networks, and mobile networks. Recently, the technique of tracking a client has been refined through browser fingerprinting, where numerous characteristics of the browser are compiled into a fingerprint. Anomaly detection based on the browser fingerprint triggers alerts when an unexpected fingerprint is seen, which may be an attacker stealing a session.

Another approach focuses on preventing the theft of the session identifier, which is commonly stored and transmitted in a cookie. The HttpOnly and Secure cookie attributes can be used to respectively prevent a cookie from being accessible through JavaScript, and prevent a cookie issued over HTTPS from being used (and thus leaked) on a non-HTTPS connection. Correctly applying both attributes to cookies holding a session identifier effectively thwarts script-based session hijacking attacks, as well as session hijacking attacks through eavesdropping on network traffic. One long-lived line of research focuses on providing protection against session hijacking attacks from within a Web application, not by hiding the session identifier, but by ensuring that the session identifier no longer acts as a bearer token, meaning that the mere knowledge of the session identifier is insufficient to hijack a session.

SessionSafe combines several mitigation techniques against session hijacking into a single countermeasure, and thereby effectively prevents script-based session hijacking attacks. To summarize, the three combined mitigation techniques are (i) deferred loading, which hides the session identifier from malicious JavaScript before main content is loaded, (ii) one-time URLs, where a secret component prevents URLs from being guessed by an attacking script, and (iii) subdomain switching, which removes the implicit trust between pages that happen to belong to the same origin, but not necessarily trust one another. SessionLock negotiates a shared secret between client and server and stores this in the client-side context. The secret is used to add integrity checks to outgoing requests. Since the secret value is never transmitted in the clear, SessionLock prevents an attacker with a stolen session identifier from making valid requests. Unfortunately, because the secret is stored in the JavaScript context, it cannot be protected against script-based attacks.

The HTTP Integrity Header uses a similar approach as SessionLock but makes the secret negotiation and integrity check part of the HTTP protocol, thereby avoiding modifications to the application logic. SecSess further improves on the HTTP Integrity header by achieving compatibility with commonly deployed middleboxes, such as Web caches. GlassTube also ensures integrity on the data transfer between client and server and can be deployed both within an application or as a modification of the client-side environment, for example as a browser plugin. Finally, other approaches look into strengthening cookies to prevent session hijacking attacks. One-Time Cookies propose to replace the static session identifier with disposable tokens per request, similar to the concept of Kerberos service tickets. Each token can only be used once but using an initially shared secret, every token can be separately verified and tied to an existing session.

Macaroons improve upon cookies by placing restrictions on how, where, and when the implicit authority of the bearer token can be used. The technology behind macaroons is based on chains of nested HMACs, built from a shared secret and a chain of messages. Macaroons target cloud services, where delegation between principals without a central authentication service is often required, for example for sharing access to the user’s address book on another service.

Other techniques follow a similar approach but base their security measures on the user’s password, which is in itself a shared secret between the user and the Web application. BetterAuth revisits the entire authentication process, offering secure authentication and a secure subsequent session. Hardened Stateless Session Cookies use unique cookie values, calculated using hashing functions based on the user’s password, effectively preventing the generation of new requests within an authenticated session.

Alternatively, Origin-Bound Certificates (OBC) extend the TLS protocol to establish a strong authentication channel between browser and server, without falling prey to active network attacks. Within this secure channel, TLS-OBC supports the binding of cookies and third-party authentication tokens, which prevents the stealing of such bearer tokens. A final line of research targets session hijacking problems from the client-side, without explicit support from the target application. SessionShield is a client-side proxy that mitigates script-based session hijacking attacks by ensuring all session cookies are marked HttpOnly before they reach the browser. Determining which cookies are session cookies at the client-side, in an application-agnostic way, is achieved by applying sensible heuristics, including an entropy test.


Unfortunately, many sites still use unprotected cookies to store session identifiers, leaving users vulnerable to session hijacking attacks. On the bright side, the adoption of the HttpOnly and Secure attributes is gaining ground, starting to be turned on by default. July 2014 survey of the Alexa top 10,000 domains shows that more than half of the domains use the HttpOnly attribute (5,465 domains in total), and 1,419 domains use the Secure attribute, which is a significant increase compared to a study from 2010. Another practice that is being deployed by major sites is to operate split session management between HTTP- and HTTPS-accessible parts of the site. For example, a Webshop can run its catalog inspection and shopping cart filling operations over HTTP, and use HTTPS for sensitive operations, such as logging in, checking out the cart, payments, or account modifications. Technically, they use two different session cookies, one for HTTP usage and one for HTTPS usage, where the latter is declared HttpOnly and Secure. While this leaves the user vulnerable to a session hijacking attack on the HTTP part, it effectively protects the HTTPS part, where sensitive operations are conducted.

Back to top button