The Web generally uses protocols that are essentially stateless, but applications often depend on context and prior actions. Web 2.0 further complicates how we must deal with the gap between stateless protocols and some notion of session required by applications.

Cookies are used in various ways to solve these problems. The two most important aspects are how cookies support session maintenance and how cookies help keep the server-side stateless. For session support, the most basic form is setting a cookie containing some form of a session identifier. Various attacks exist that try to get the cookie value and use it to take over the session. The generic solution to keep the server-side stateless is to push all state information back and forth between server and client. The server gets the previous state from the client, modifies it, and sends the modified state back to the client. Sensitive elements in the state are encrypted by the server before sending it to the client and decrypted when receiving the updated state from the client. The most obvious risk here is playback of the encrypted session content (a replay attack).

Compared to standard techniques, the paper adds proof of origin for the whole request by adding a signature for the complete content. This sounds a little better than it actually is. In the discussion section, the authors note that their solution is vulnerable to cross-site request forgery (CSRF). Properly done, an attack can mimic a user action and get its malicious requests signed as well. Exploits such as the man-in-the-browser threat are not blocked either.

The authors propose a method to establish a key for the encryption of security state information. They derive the key from a global key and a random value that is transmitted “in the clear.” This method enables stateless operation. Using “exclusive or” for the key derivation has me a little worried, but I leave it to the cryptographers to judge.

Finally, the authors separate the normal cookies from the security tokens, both in the protocol (a different hypertext transfer protocol (HTTP) header) and in a different store browser-side. Such a change has a big impact, although it also may not be in the right direction. Since we need to modify browser software anyway, why not incorporate the secure and HttpOnly flags into a system with more and better controls? That way, other cookie users could benefit from it.

There are other details that make me uneasy. The authors downplay the tendency to move from HTTP to secure HTTP (HTTPS) everywhere. The client signature contains a session timeout set by the client, but this should really be decided by the server.

The authors spent time building the system and working on its performance, and the paper provides ample data on those efforts, but this is only relevant if the proposal is solid enough. Browser-side security is problematic, and we could use some good proposals for improving it. For me, this one is not good enough.