People's Newsroom


Implementing SecSess’s functionality at the client side is best done within the browser, which is responsible for managing sessions, sending requests, and receiving responses. A browser-based implementation has full control over all outgoing requests, regardless of whether they originate from within a page, JavaScript, or the browser core. Currently, we implemented SecSess as a lightweight add-on, enabling easy development of a proof-of-concept for evaluation with the latest browser. The long-term deployment strategy integrates the current codebase into the browser core, enabling SecSess as an opt-in mechanism at the client-side.

At the server-side, SecSess can be supported through two complementary implementation strategies. The first option is to integrate SecSess directly into the Web platform, while remaining transparent to the target applications, for example as a module within the Web server (e.g. as an Apache module), or as part of the underlying application framework (e.g. our Express middleware implementation). The alternative strategy focuses on supporting legacy applications, where the underlying frameworks cannot easily be upgraded. Implementing SecSess as a reverse proxy in front of the server provides secure session management towards the browser while shielding the server from these changes.

Since SecSess follows the same traffic flow as current cookie-based session management mechanisms, it remains fully compatible with advanced Web technologies. One common example is load balancing techniques deployed at the server-side, where multiple servers serve requests for the same target application. Since cookie-based mechanisms already require session tracking or state sharing between servers, SecSess can benefit from the same technology.


A session management mechanism is responsible for establishing and maintaining a session, threatened by adversaries aiming to gain control of a session established between a user’s browser and the target application. SecSess effectively prevents these session transfer attacks, while meeting the objectives proposed earlier. In this section, we discuss two related attacks which are out of scope for a session management mechanism but are nonetheless related.

Replay Attacks. In a replay attack, the attacker replays earlier-recorded traffic towards the target application, making the application believe the user performed the same operations twice. Common protection mechanisms against replay attacks are the use of nonces or counters, which in turn require storing previously seen nonces, or a sliding window of valid counters, as often applied in various network protocols. While preventing replay attacks at the application level is out of scope for a session management mechanism, SecSess does ensure that the properties of an HTTP request cannot be modified. Essentially, an attacker can only replay an exact copy of an HTTP request, which reduces the problem to a user hitting the refresh button in his browser, or impatiently submitting a form twice. Therefore, we have deliberately decided to exclude replay protection from SecSess, since these double submission issues have to be handled within the application anyway.

Man-in-the-Middle Attacks. A special case of an active network attack is a man-in-the-middle attack, where an attacker actively manipulates the network infrastructure, positioning himself in between the user’s browser and the target application. If this occurs before a session has been established, the victim’s browser will establish a session with the attacker, after which the attacker establishes a session with the target application. Note that this does not violate SecSess’s security guarantees, since the session is still tied to its initiating parties, albeit that one of the parties is the attacker. Protecting against man-in-the-middle attacks requires explicit entity authentication, as offered by the TLS protocol. Integrating such protection in a session management mechanism would result in a “re-invention” of the TLS protocol on a higher level, an effort that does not seem useful. Note however that SecSess is only vulnerable to man-in-the-middle attacks during session establishment, but is resilient against these attacks after the shared secret has been exchanged.

Related work offers several proposals to tackle the current session management problems. While these approaches offer significant benefits over cookie-based mechanisms, they only partially meet the objectives. Additionally, many of the proposals depend on the presence of a TLS-channel and do not withstand passive network attacks when such a channel is unavailable.

SessionLock. SessionLock uses a JavaScript library to augment requests with an HMAC based on a shared session secret. The session secret is established over a TLS channel and stored in a secure cookie. For HTTP pages, it is stored in the fragment identifier, a part of the URL that is never sent over the network. SessionLock also supports a non-TLS scenario, where the client performs an out-of-band key exchange with the server. The idea behind SessionLock is similar to the idea behind SecSess, but the implementation differs significantly. The implementation as a JavaScript library not only fails to protect the session against script-based attacks but also requires significant changes to existing applications, as all requests are through AJAX calls.

BetterAuth. BetterAuth is an authentication protocol for Web applications, offering protection against several attacks, including network attacks, phishing, and cross-site request forgery. BetterAuth considers a user’s password to be a shared secret and uses that shared secret to agree on a session secret over an insecure channel. The session secret is used to sign requests, offering authenticity. BetterAuth offers strong security properties and is even capable of protecting against man-in-the-middle attacks. However, BetterAuth requires the exchange of the password over a secure channel, as well as the modification of existing applications. Additionally, BetterAuth depends on the password, it is incompatible with current third-party authentication services.

HTTP Integrity Header. The HTTP Integrity Header is an expired draft proposing to add integrity protection to HTTP, which includes a session management mechanism. The header depends on a key exchange, either over TLS or with a traditional exchange, after which the integrity of the selected parts of a message is protected. The HTTP Integrity header actually shares the same idea as SecSess, using a shared secret for session management and integrity properties. However, the HTTP Integrity header uses the original protocol, which only establishes a secret at the client after the first request and response have been exchanged. This leaves the setup phase of the session vulnerable to passive network attacks. Additionally, the HTTP Integrity header does not account for the adverse effects of caches or out-of-order requests during session establishment.

One-Time Cookies. One-Time Cookies proposes 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. To share the initial credential, One-Time Cookies depends on the use of TLS during the authentication phase. One-Time Cookies would be a good replacement for traditional cookie-based session management mechanisms. However, since the initialization must be done over TLS, it loses its security properties when deployed for applications that only use HTTP, making a short-term deployment infeasible.

TLS Origin-Bound Certificates. Origin-Bound Certificates (OBC) is an extension for TLS, that establishes 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. TLS-OBC offers strong security guarantees and is able to eliminate the bearer token-properties of sensitive cookies. However, since TLS-OBC obviously depends on a TLS-only deployment, it is not a feasible solution for securing current and future HTTP deployments.

The current de facto standard for session management on the Web is extremely vulnerable to session transfer attacks. Best practices advocate deployment over TLS with the appropriate cookie flags, but several factors hinder such wide-scale TLS deployment. Alternative proposals for new session management mechanisms either also depend on the presence of a TLS channel or fail to robustly deal with the Web’s infrastructure, such as widely deployed Web caches. We have proposed SecSess, a lightweight session management mechanism that prevents unauthorized session transfers, and is explicitly designed to be compatible with the current Web. SecSess preserves the flow of requests observed today with cookie-based session management mechanisms, hence SecSess is compatible both with current infrastructure and with current Web applications.

Back to top button