The essence of SecSess is establishing a shared secret used for session management between browser and server, which cannot be obtained by an attacker, thus effectively binding an established session to its initiating parties. In this section, we elaborate on our session management mechanism in two stages. First, we introduce the general idea and achieved properties without getting lost in details. In the second stage, we explain how these properties are achieved by highlighting each aspect of SecSess.
All session management instructions are contained in the newly introduced Session header, which keeps track of the parameters needed to establish a session, as well as the session identifier of the established session. Session management is based on a shared session secret, which is safely contained in the browser, inaccessible to any script code, and never sent over the network. Using this shared session secret, we can generate a message authentication code (HMAC) for a request, which is sent to the server in the Session header. Using the shared secret associated with the session, the server can calculate the same HMAC in order to verify whether the received request is actually valid within the session.
Note that an eavesdropper can easily get hold of the session identifier, which is sent in the clear, but that the session identifier is only used to simplify bookkeeping. It is no longer the bearer token for the session, nor is it supposed to be secret. Using a simple incremental counter as an identifier is sufficient. An attacker attempting to use a stolen session identifier on a crafted request also needs the session secret to generate a valid HMAC for the request. Since this shared secret is safely contained within the browser, it cannot be obtained by an attacker.
In this section, we further detail each aspect of SecSess in three steps: (i) the actual session management mechanism, (ii) establishing the shared session secret, and (iii) the resulting request flow, which is identical to the flow in cookie-based session management mechanisms.
Session Management. Associating the server-side stored state with the appropriate requests is simplified by using a simple session identifier (ID) for bookkeeping. The session identifier is provided by the server using a Session response header (response 1). The browser attaches the session identifier to each request, using the newly introduced Session request header. Note that while the use of a session identifier strongly resembles traditional cookie-based session management, the session identifier is no longer considered to be a bearer token, and is useless without knowledge of the shared secret.
Instead of using the session identifier as the bearer token, SecSess uses the shared secret to add a hash-based message authentication code (HMAC) to the request, thereby legitimizing the request within the session. Since this HMAC takes the request and the shared secret as input, only the browser, and the server can compute the correct values. Incoming requests with an invalid HMAC are simply discarded by the server. Note that the input for the HMAC should be chosen carefully.
Technically, a network attacker can steal the valid HMAC from an eavesdropped request and attach it to a crafted request, having the crafted request reach the server first. In order to maintain a valid HMAC on the crafted request, the attacker can only modify the parts of the request that are not part of the input to the HMAC function. Including the URL of the request in this input prevents an attacker from directing the request to a different destination, but still allows him to modify sensitive information in the request headers and body (e.g. the destination account of a wire transfer).
Therefore, the HMAC also covers the request headers containing sensitive data, and, if present, the request body. Covering the URL, request headers, and request body in the HMAC does not prevent an attacker from taking the valid HMAC value and attaching it to a crafted request. However, it does ensure that the attacker cannot change the sensitive data, hence limiting the contents of the crafted request to those of the original request, thereby reducing the problem to the common double submission problem.
Establishing the Shared Secret. The shared session secret, needed to compute and verify HMACs on requests, is established using the Hughes variant of the key exchange algorithm, which allows exchanging the key even in the presence of eavesdropping attackers. The server sends his public value (Y) after seeing the first request, in which the browser indicates support for the Session header. Using the server’s public component Y, the browser can calculate the second public part (X), which the server needs to calculate the key. In the next request, the browser sends the public value X, allowing the server to calculate the full key and verify this and any subsequent requests, effectively establishing the session, as acknowledged in the second response.
Note that the advantage of the Hughes variant is that the browser can compute the key before the first request is sent. This is required to attach an HMAC to the first request, so the server can verify that the sender of the first and second requests is in fact the same. Omission of the first HMAC allows an eavesdropper to respond to the first response, injecting his key material into the session, which is problematic when the first request already caused some server-side state to be stored in the session.
Preserving the Request Flow. By design, SecSess is an application-agnostic session management mechanism, preserving the same flow of requests and responses as a currently deployed cookie-based session management mechanism. This property supports a gradual deployment, where client and server software can be upgraded to opt-in to SecSess next to cookie-based session management. If the client does not support SecSess, no Session header is sent, so the server simply defaults to cookie-based session management. Alternatively, if the client supports SecSess, but the server does not, the Session header will be ignored by the server, and the default cookie-based session management mechanism will be used.