The implementation of web sessions is a somewhat anarchic and largely unstructured process. Our goal with the present paper is to provide a disciplined perspective of which are the relative strengths and weaknesses of the most common techniques to implement web sessions, with a particular focus on their security. We clarify common misconceptions in the recent \cookies vs tokens" debate and we propose a more useful classi cation of web session implementations, based on where session information and session credentials are stored. We then propose a new implementation technique for web sessions which combines the strengths of existing web technologies to overcome their weaknesses and we successfully deploy our solution on top of WordPress and the Auth0 library for web authentication to demonstrate its feasibility.
This research is supported by the MIUR project ADAPT. rather than at the server side, which voids the need of a centralized database and simpli es the deployment of the web application over multiple independent servers.
As it usually happens when implementation freedom is rampant, it did not take too much time before the \cookies vs tokens" debate started spreading over the web. There is a wealth of blog posts and discussions in online communities like Stack Over ow which argue for the use of one of the approaches over the other one, but they are often biased, su er from a lack of rigor or provide only a very partial point of view. Our goal with the present paper is to provide a more disciplined perspective of which are the relative strengths and weaknesses of the most common techniques to implement web sessions, with a particular focus on their security. 1.1
In this paper, we make the following contributions: (i) we clarify common misconceptions in the recent \cookies vs tokens" debate and we propose a more useful classi cation of web session implementations, based on where session information and session credentials are stored, which we use to perform a critical assessment of the relative strengths and weaknesses of the di erent implementation techniques; (ii) we propose a new implementation technique for web sessions which combines the strengths of existing web technologies to overcome their weaknesses; and (iii) we successfully deploy our solution on top of WordPress and the Auth0 library for web authentication to demonstrate its feasibility. 2 2.1
The rst degree of freedom in web session implementations is related to the storage of session information, like the user identity, the content of the shopping cart or the preferred language of choice for the website. This information can be stored either at the server or at the browser.
In a stateful session, the session information is stored at the server side and the browser only stores a \pointer" to this information. For example, the server S may generate a unique session identi er Xa33YkW1, which is used to index a database containing session information and supplied to the browser B. When B sends back the session identi er, S uses it to perform a query to its database. The result of the query includes the required session information, like the identity of the user and her preferred language; this information is used to dynamically assemble a personalized web page, which is returned in response to the browser.
In a stateless session, the session information is stored at the browser side, so the server does not need to rely on a database for session management. To prevent tampering at the browser side, the server uses cryptography to protect the integrity (and possibly the con dentiality) of the stored session information. For example, the server S may use the signing key sk(K) to produce a signature of the identity of the user and her preferred language. When the browser B provides back the signature, S uses the veri cation key vk(K) to check its integrity and restore the session like in the previous case. 2.2
The second degree of freedom in web session implementations is related to the storage of session credentials at the browser side. By \session credential" we mean everything which unambiguously identi es a web session and can be used to start the process of resuming it, e.g., the session identi ers typical of stateful sessions or the signatures used to implement stateless sessions. 2.2.1
The most common technology to store session credentials are cookies. Roughly, a cookie is a key-value pair generated by a web application and sent to the user's browser to be stored therein; the browser then automatically attaches the cookie to the next HTTP(S) requests sent to the web application, which can inspect the cookie value to start resuming the session.
Cookies have a well-de ned scope, since they are attached by default to all the HTTP(S) requests directed to the domain and the sub-paths of the HTTP(S) endpoint setting them. For instance, a cookie set by https://www.example.com/ will be attached to any HTTP(S) request to example.com. Path visibility can be con gured by means of the Path attribute, but most notably cookies can be shared among multiple domains by means of the Domain attribute. Speci cally, a page can set cookies for a parent domain as long as the latter does not occur in a list of public su xes1: these cookies are shared between the parent domain and all its subdomains. For instance, a page at www.example.com can set a cookie with the Domain attribute set to .example.com, which is sent with all requests to sub-domains like mail.example.com and accounts.example.com. 2.2.2
A more modern alternative to cookies is web storage, a novel feature of HTML5. Web storage is a browser-side storage mechanism which can be accessed by means of JavaScript APIs. Compared to cookies, it o ers larger storage capacity and it is only intended for browser-side scripting, i.e., web storage data is not automatically attached to every HTTP(S) request and just stays in the browser, though it is possible to implement di erent behaviors in JavaScript if desired.
Web storage o ers two storage areas: local storage and session storage. The only di erence is that data stored in the local storage persist until explicitly deleted, while the content of the session storage is only made available to a given window or tab (depending on the browser); once the window or tab is closed, the storage is deleted. We will not distinguish between local storage and session storage in the rest of the paper. 2.2.3
The same-origin policy (SOP) is the baseline defense mechanism of web browsers and it mediates
accesses to both cookies and the web storage. It prevents the theft of sensitive credentials
by scripts of untrusted websites, e.g., credentials owned by bank.com cannot be accessed by
evil.com. More precisely, an origin is de ned as a triple including a scheme, a hostname and
a port, like (https; example.com; 443). A script can read or write the contents of the web
storage of a given origin only if it runs exactly in the same origin. The same idea applies to
cookies, but with the important di erence that cookies implement a more relaxed notion of
origin, which does not provide isolation by scheme and port [
1The common domain su x must not occur in a list of public su xes at https://publicsuffix.org/. 2.3
Web security traditionally considers di erent threat models, which we reuse in the present paper.
The web attacker runs a set of malicious websites hosting arbitrary attacker-controlled contents
and can exploit content injection vulnerabilities on trusted websites, i.e., he may be able to
place maliciously crafted contents in otherwise benign web pages. A more powerful variant of
the web attacker, known as the related-domain attacker, can host his malicious websites on a
sibling domain of the target website [
A common attempt in technical blogs and web communities is comparing cookies and tokens as two di erent mechanisms to implement web sessions. However, such a comparison is ill-founded, because, irrespective of which technology is chosen, the lack of native support for sessions on HTTP(S) encourages web developers and authors of web development frameworks to come up with custom techniques for session management. In practice, both cookies and tokens can be used to implement sessions in many di erent ways. A much better way to classify and reason about web session implementations is just based on where session information and session credentials are stored, as we do after clarifying two common misconceptions. 3.1.1
Cookies = Stateful and Tokens = Stateless Traditionally, cookies are associated to stateful sessions, while tokens are associated to stateless sessions, but actually the need of storing and accessing session information at the server side is orthogonal to the use of cookies and tokens. Since cookies are just a generic storage mechanism, stateless sessions can be easily implemented on top of them. Indeed, we found real services using cookies to implement stateless sessions, with WordPress being a notable example.
Dually, stateful sessions may be built on top of tokens, most notably to implement token revocation. Although tokens typically include an expiration date, there is no way to invalidate them before expiration without implementing a stateful blacklisting mechanism at the server side. Revoking tokens may be useful for several reasons, e.g., when a password theft is reported, when a user logs out or when a user's password is changed. We found plugins to implement token revocation for popular token-based web development frameworks, like Express2. 3.1.2
A common misconception is that cookie-based sessions work well with single domains and their sub-domains, while tokens are easier to share between domains. The reason underlying this observation is that cookies have a well-de ned scope based on domain matching, while tokens do not have a xed scope and are shared via the implementation of custom JavaScript logic.
2The plugin is available at https://github.com/auth0/express-jwt Still, although cookies have well-de ned scoping rules respected by web browsers, they can still be accessed by JavaScript and shared across domains just like tokens.
Ironically, we observe that tokens can be actually harder to share than cookies when they are stored in the web storage, because read and write accesses to the web storage are subject to stricter access control checks than the cookie jar - cookies are not isolated by scheme and port. For instance, if a token is saved in the web storage by a script at http://example.com, it cannot be read by scripts from https://example.com, while cookies set by http://example.com are visible to https://example.com and vice-versa. 3.2
The main arguments in favor of stateless sessions are e ciency and scalability. In stateful sessions, every authenticated request requires a database access to be processed, which is costly and makes server-side replication and load balancing more complex to deal with. On the ip side, stateless sessions typically require to exchange more data upon communication, because session information is entirely stored at the browser side. From a security perspective, however, there is no strong argument to prefer stateful sessions over stateless sessions or vice-versa, because robust programming practices are known for both.
When stateful sessions are implemented, web developers should ensure that session
information is only bound to unpredictable session identi ers. This is important to guarantee that valid
session identi ers cannot be forged or detected by brute-forcing [
When stateless sessions are preferred, web developers should rely on appropriate signature
and encryption algorithms to ensure the integrity and, possibly, the con dentiality of the session
information [
Cookies are signi cantly easier to use than web storage when it comes to storing session credentials, because they have a well-de ned semantics for web browsers based on their scoping rules. When credentials are stored inside a cookie, web sessions can be implemented entirely at the server side, because browsers will automatically perform the task of attaching the cookie. If instead credentials are stored in the web storage, the web application must implement enough JavaScript logic to attach them to HTTP(S) requests.
This also limits the attachment of the credentials to requests which can be programmatically generated by JavaScript, i.e., using the XMLHttpRequest API. If a user clicks an external link pointing to the web application, for instance among the results of a search engine, no JavaScript logic will be triggered by the browser and no credentials will be attached to the request. Hence, any ongoing session will be broken when clicking the link, unless a script on the landing page forces a page refresh to provide the credentials. 3.3.2
Both the cookie jar and the web storage are protected by the same-origin policy, which mediates both read and write accesses, but does not constrain cross-origin communication. This means that, normally, any script running in the same origin which set the session credentials is entitled to read them and communicate them to any HTTP(S) endpoint on the web. Session credentials are then vulnerable to ex ltration via script injection (XSS) or accidental leaks over HTTP, which allow the hijacking of legitimate user sessions (impersonation attacks).
Although the cookie jar relies on a more relaxed notion of origin than the web storage,
the former provides better con dentiality guarantees than the latter, because cookies can be
protected using the HttpOnly and Secure attributes [
It is well-known that cookies do not provide strong integrity guarantees against related-domain
attackers and network attackers, given their more relaxed notion of origin [
Cookie integrity can be enforced by placing web contents so that security-sensitive cookies
cannot be set by untrusted sibling domains and by using HSTS [
Since cookies are attached by default to every HTTP(S) request, they enable cross-site request
forgery attacks (CSRF) [
If the session credentials are stored in the web storage, they are not attached by the browser to any request by default; rather, the web developers are completely in charge of implementing which credentials should be attached to which requests. This means that CSRF attacks are automatically prevented: if authenticated cross-site requests are really needed, they should be explicitly supported by the implementation of appropriate JavaScript logic. 4
We have discussed the relative strengths and weaknesses of cookies and web storage for saving session credentials. We discuss here two possible ways to combine cookies and web storage to implement more robust web sessions. 4.1
Our key idea is to take advantage of the con dentiality guarantees o ered by cookies, without sacri cing the integrity assurances and the protection against CSRF granted by the use of web storage. Speci cally, we propose two ways to combine these existing web technologies.
In our rst scheme, we store the session credentials in the web storage and an HMAC of the session credentials inside a cookie. The HMAC is computed using a symmetric key which never leaves the server. The cookie is protected with the HttpOnly attribute and, if full HTTPS support is available, also with the Secure attribute. When a request including valid session credentials is received, the website veri es the HMAC of the credentials before processing it. If no valid HMAC is attached to the request, the request is discarded.
In our second scheme, we store the session credentials inside a cookie and a cryptographic hash of the session credentials inside the web storage. The cookie is protected with the HttpOnly attribute and, if full HTTPS support is available, also with the Secure attribute. When a request including valid session credentials is received, the website veri es the hash of the credentials before processing it. If no valid hash is attached to the request, the request is discarded. 4.2
Both schemes prevent CSRF attacks by construction, because part of the information needed to authenticate the requests is saved in the web storage and thus is not automatically attached to cross-site requests. Moreover, both schemes protect against user impersonation attempts by the attacker. In the rst scheme, even if session credentials are leaked from the web storage, e.g., via XSS, their HMAC is not, because it is stored in a cookie protected with security attributes ensuring its con dentiality. Notice that the HMAC cannot be computed by the attacker, unless the symmetric key used to construct it is leaked, which would require the attacker to compromise the server. In the second scheme, the session credentials are directly stored in a cookie protected with security attributes ensuring their con dentiality and they cannot be reconstructed from the hash, because cryptographic hash functions are non-invertible.
Finally, observe that both schemes also prevent malicious attempts to force the user's browser in the attacker's session by compromising the integrity of the session credentials, unless the target website is a ected by an XSS vulnerability. This is because the same-origin policy ensures the integrity of the web storage against cross-origin write attempts, thus compensating the weak integrity guarantees provided by cookies alone. 4.3
Though both schemes support the same security guarantees, there are a number of deployment considerations which should be taken into account when comparing them. The rst important observation to make is that there are several cases where authenticated cross-site requests should not to be considered CSRF attempts and are actually desired, e.g., users would like to stay authenticated to a website when clicking a hyperlink pointing to its homepage in the results of a search engine. The security policy enforced by the second scheme is easier to relax to support these cases, because session credentials are stored inside a cookie and thus attached by default to HTTP(S) requests; in contrast, in the rst scheme only an HMAC of the session credentials is available in the cookie, which does not contain enough information to restore the session. With the second scheme, relaxing the security policy for selected web pages is straightforward, since it is enough to skip the check of the hash for those pages. This can be implemented without changing the web application code, for instance by using a web application rewall like ModSecurity or by writing an Apache module which performs the task.
Relaxing the security policy of the rst scheme is more complicated. The most natural way
to achieve this is by implementing enough JavaScript logic to force the attachment of the session
credentials to selected HTTP(S) requests, but this may require a signi cant e ort and a good
understanding of the web application code. A simpler solution is based on service workers [
Though this analysis seems to suggest that the second scheme is easier to implement than the rst one, the main problem in the deployment of the second scheme is that session credentials are not available to JavaScript, because they are stored inside a cookie protected with the HttpOnly attribute. Though accessing session credentials at the browser side is uncommon for stateful sessions, it may be useful for stateless sessions, e.g., when user information is stored inside a JWT. In these cases, the rst scheme is the only available solution to deploy. 5
We retro tted two existing open-source applications to improve the security of their sessions based on the authentication schemes proposed in the previous section. We comment here on our deployment experience. 5.1
WordPress is the world's most used Content Management System, powering about the 28%
of the Internet websites4. Sessions in WordPress are built on top of cookies. The core of
WordPress is protected against CSRF attacks by means of random nonces, a standard solution
which prevents the sending of valid cross-origin requests which may produce dangerous
sidee ects at the server [
In the case of WordPress, we chose to implement our second authentication scheme, because session credentials are already stored in cookies. We developed a WordPress plugin which extends login responses to include a fresh cookie cookie hash containing a hash of the credentials and to register a new service worker. The plugin also injects a script which reads the value of cookie hash and communicates it to the service worker using the postMessage API; the service worker then saves the hash value in the web storage and extends each request to the WordPress core to include it as a GET parameter. Finally, the plugin changes the WordPress core to make 3https://hacks.mozilla.org/2016/03/referrer-and-cache-control-apis-for-fetch/ 4Data retrieved on 02/10/2017 from https://wordpress.org/ it check the validity of the hash before processing incoming requests. We successfully tested our plugin on a fresh WordPress 4.8.2 installation and we will proceed soon to its public release. 5.2
Auth0 is a popular identity management platform, o ering a uni ed access interface to a huge number of identity providers implementing single sign-on systems, like Facebook and Google. Auth0 o ers its authentication services by means of a JavaScript library, which performs the single sign-on process with the chosen identity provider and stores in the web storage a JWT containing unencrypted authentication data signed with RSA-SHA256. Web developers are left in charge of choosing how to use the JWT for session management at the server side.
Since the Auth0 library stores session credentials in the web storage, we chose to implement the rst authentication scheme. Speci cally, we patched the Auth0 library to provide the JWT to a (customizable) server endpoint and we implemented an Apache module which performs two tasks. First, the module listens for JWTs at the designated server endpoint: when a JWT is received, the module computes its HMAC and returns it to the browser inside a fresh cookie jwt hmac - future requests to the endpoint providing the same JWT will be discarded. Then, the module automatically performs the check of the HMAC on every incoming request before forwarding it to the protected web application. We successfully tested our implementation by hosting on Apache an example single page application.
This implementation signi cantly strengthens session security by leveraging our scheme, though it does not provide bullet-proof protection against session hijacking. An attacker who is able to steal the JWT before it is sent by the user's browser to the designated server endpoint may be able to acquire a valid HMAC for the user and intrude the session. Nevertheless, observe that the attack surface for session hijacking was signi cantly reduced: in the current Auth0 implementation, an XSS attack on any page at any time would allow an attacker to hijack the session. With our implementation, instead, an attacker can only hijack the session if he is able to steal the session credentials exactly when they are rst established, before they are used to get a valid HMAC. This means that the attacker must perform an XSS attack at the right time and exactly on the page hosting the Auth0 library to hijack the session. 6
The implementation of web sessions is a largely unstructured process, which the wide availability of partial and biased information on informal web documentation does not help streamlining. With the present paper, we proposed a clear-cut classi cation of web session implementations to perform a critical discussion of the strengths and weaknesses of popular solutions. We then put forward a new implementation technique based on a combination of cookies and web storage, where we exploit the distinctive strengths of these web technologies to overcome their limitations. Our solution has good security properties and proved to be easy to implement on existing services like WordPress and the Auth0 library for web authentication.
The quest for more robust and easier to deploy web sessions is still ongoing and there are several avenues for future work. For instance, designing and implementing libraries for web session management which are secure by construction is an important research direction, which we are investigating in ongoing work. A particularly intriguing challenge is complementing these libraries with tools which automatically retro t the security of existing web session implementations, thus providing improved session security to the largest possible audience.