In a cookie-based session management mechanism, the server generates a random identifier for a session and sends it to the browser using the Set-Cookie header. The browser stores the cookie in the so-called cookie jar, and whenever a request is sent to a domain for which cookies are present in the cookie jar, the browser attaches these cookies using the Cookie header. Unfortunately, the bearer token properties of the session identifier make cookie-based session management vulnerable to unauthorized transfering of the session. One such attack is a session hijacking attack, where an adversary is able to steal a user’s session identifier. Simply attaching this session identifier to crafted requests is typically sufficient to hijack the user’s session, granting the adversary the same level of access as the user. Concrete attack vectors for a session hijacking attack are script-based cookie exfiltration using the document.cookie property, or eavesdropping attacks on the network, as aptly demonstrated by the Firesheep add-on, which reduces a session hijacking attack to a point-and-click operation.
A second attack is session fixation, where the adversary forces the user’s browser to use a compromised session. The aim of a session fixation attack is to have the user authenticate himself within a session known to the attacker, causing the server to store the user’s authentication state in the attacker’s session. A session fixation attack is typically carried out by writing to the document.cookie property.
Since these attacks are well-known and well-documented, several countermeasures are available. Most relevant are the HttpOnly and Secure cookie flags, which respectively restrict script-based access to cookies, and prevent the transmission of cookies over insecure channels. While these countermeasures offer adequate protection if deployed correctly, they do not fundamentally prevent unauthorized transfers, as the session identifier remains a bearer token. Additionally, these countermeasures are often not or incorrectly deployed, even within the Alexa top 100 sites, and new attacks that compromise secure deployments have been discovered.
THREAT MODEL FOR SESSION MANAGEMENT
In an attack on the session management mechanism, the attacker aims to take control of the victim’s session. Based on this observation, we define the threat model for session management as a session transfer attack. Concretely, in a session transfer attack, the attacker is able to transfer a session defined between the victim’s browser and the target application to his own browser. Transfering the session grants the attacker the same privileges with the target application as the user holds.
Next to these in-scope attack vectors of a session transfer attack, we consider attack vectors based on a compromise of the client-side or serverside infrastructure to be out of scope. The most common example is machines compromised by malware, both at the client and server-side. Concretely, we expect an uncompromised machine and browser codebase at the client, as well as an uncompromised machine and Web application codebase at the server.
OBJECTIVES FOR NEW SESSION MANAGEMENT MECHANISMS
Based on the discussion of the current cookie-based session management mechanism and its associated threats, we identify four design objectives for a new session management mechanism. The first objective is a core design feature, focusing on preventing unauthorized session transfers. The three remaining objectives ensure the feasibility of deployment, covering induced overhead, compatibility with current applications and infrastructure, and a gradual migration path.
Preventing Unauthorized Session Transfer. State-of-practice session management mechanisms are vulnerable to session transfer attacks by design, due to their reliance on the session identifier as a bearer token. Newly designed session management mechanisms should actively try to prevent session transfer attacks. Additionally, session management mechanisms should still support authorized transfers, such as desktop-to-mobile synchronization at the client-side, and load balancing at the server-side.
Minimal Overhead. A crucial requirement for a new session management mechanism on the Web is a minimal overhead, well illustrated by browser vendors and Web application developers focusing on minimizing page load times. Overhead in the Web is twofold, with on one hand performance overhead, such as additional computations, and on the other hand networking overhead, with increased message sizes and additional roundtrips. Especially the latter is considered problematic, since it delays the processing of the page and the loading of sub-resources, such as style sheets, images, etc.
Compatibility with Current Applications and Infrastructure. A newly proposed session management mechanism should be compatible with the current Web and its peculiar deployment scenarios. Examples are the integration of third-party content in Web sites, and the redirection towards third-party service providers, such as a centralized authentication provider. On the infrastructure level, the Web deploys numerous middleboxes, such as Web caches at various levels and content inspection systems at network perimeters.
Gradual Migration. Finally, a new mechanism looking for adoption on the Web should support a gradual migration path, starting with early adopters on the client and server-side, followed by a gradual increase of coverage in the Web. Key in this process is an application-agnostic opt-in session management mechanism, supporting implementation in current clients and server software or application development frameworks, thereby preventing the need for each individual application to incorporate the new mechanism. Additionally, backward compatibility with parts of the Web that will not quickly adopt the new mechanism is also important, since the Web cannot be updated in a single step.