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.
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.
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.