Chrome engineers propose an HTTP State Management plan

by ddos ·

Recently, Chrome Engineer Mike West published an article proposing to modify the cookie standard to enhance HTTP state management.

Mike analysed several aspects of the current cookie, including the difficulty of using it safely, wasting user resources, and privacy issues, which can be used to track user activity on the web in a surprising way.

Image: By Tizio [GFDL or CC-BY-SA-3.0], from Wikimedia Commons

Regarding wasting user resources, Mike explained that the server could store a large number of cookies for a registered domain name, and many cookies can be sent via HTTP requests. For example, Chrome allows approximately 180 cookies to be stored for each domain name, which is equivalent to approximately 724kB of data. Among the many cookies, the median size of the request header is 409 bytes, but 90% of them have 1589 bytes, 95% of them are 2549 bytes, 99% even reach 4601 bytes, and about 0.1 The % cookie header is huge, over 10kB. So abused and inefficient.

Regarding privacy, it is well known that cookies can be used for authentication, but it can also be used to track user information quietly.

About the difficulty of using it safely, Mike lists several issues encountered in the safe use of cookies in development:

  • Cookies are available to JavaScript by default (via document.cookie), which enables a smooth upgrade from one-time XSS to theft of persistent credentials (and also makes cookies available to Spectre-like attacks on memory). Though the HttpOnly attribute was introduced well over a decade ago, only ~8.31% of Set-Cookie operations use it today.
  • Cookies are sent to non-secure origins by default, which enables trivial credential theft when you visit your local Evil But Delicious Coffee Shoppe™. The Secure attribute locks the cookie to secure origins, which is good! Still, only ~7.85% of Set-Cookie operations use it today.
  • Cookies are often delivered without any indication of the request’s initiator, meaning that a server’s own requests look identical to requests initiated by your good friends at https://evil.com. The SameSite attribute aims to mitigate the CSRF risk, but the fact that ~0.06% of Set-Cookie operations use it today is not inspiring.

Mike believes that on the one hand, the attributes that cookies use to mitigate security issues are weak and that cookies do not meet the security boundaries we have decided to enforce on other types of Web-accessible data. They flow through the source in a given registrable domain, they ignore ports and schemes, which means network attackers can easily forge them, and they can be narrowed down to specific paths, which make them difficult to reason and motivate A homology strategy that weakens the rest of the platform.

Mike gave a new set of solutions. He explained that the user agent could control the HTTP state it represents on behalf of the user by generating a unique 256-bit value for each security source accessed by the user. This token can be passed as a structured HTTP request header. To the source:

Sec-HTTP-State:token = * J6BRKagRIECKdpbDLxtlNzmjKo8MXTjyMomIwMFMonM *

This identifier is more or less similar to a client-controlled cookie, but with some notable differences:

  • The client controls the value of the token, not the server.
  • The token can only be used at the network layer, not for JavaScript (including web-like JavaScript, such as Service Workers).
  • The user agent generates only one 256-bit token per source and exposes just the token to the source from which it was generated.
  • Tokens are not generated or passed for non-secure sources.
  • By default, the Token will be provided with the same site request.
  • Tokens persist until the server, user, or user agent is reset.

On this basis, developers will be provided with some control points that can be triggered by the Sec-HTTP-State-Options HTTP response header. The options are as follows:

1. Some servers need to access their Tokens across sites. Other servers may wish to narrow the delivery to homogenous requests. The server can specify either option:

Sec-HTTP-State-Options: ..., delivery=cross-site, ...

or:

Sec-HTTP-State-Options: ..., delivery=same-origin, ...

2. Some servers want to limit the lifecycle of Tokens and allow them to set the TTL (in seconds):

Sec-HTTP-State-Options: ..., ttl=3600, ...

The value of the Token will be automatically reset after the time expires. At the same time, the server may also want to explicitly trigger the reset behaviour of the Token (for example, when logging out), which can be achieved by setting the TTL to 0:

Sec-HTTP-State-Options: ..., ttl=0, ...

In either case, the currently running page can be notified of the user’s state changes to perform the cleanup operation. When a reset occurs, the user agent can send a message to the BroadcastChannel of the source named http-state-reset (and possibly wake up the source’s Service Worker in response to the user-driven reset):

Let resetChannel = new BroadcastChannel('http-state-reset'));
resetChannel.onmessage = e => { /* Do exciting cleanup here. */ };

3. For some servers, the Token generated by the client is sufficient to maintain state, they can be treated as an opaque session identifier, and the user’s state is bound to the server. Other servers require additional assurance that they can trust the source of the Token. To do this, the server can generate a unique key, associate it with the session identifier on the server, and pass it to the client via an HTTP response header:

Sec-HTTP-State-Options: ..., key=*ZH0GxtBMWA...nJudhZ8dtz*, ...

The client will store the key and use it to generate signatures for specific data sets, reducing the risk of Token being captured:

Sec-HTTP-State: token=*J6BRKa...MonM*, sig=*(HMAC-SHA265(key, token+metadata))*

Mike also said that the program is not a new thing that is entirely different from cookies. It is not intended to replace cookies at the moment. Although it is appropriate to deprecate cookies, the current solution only proposes a situation where cookies exist at the same time. A supplementary mechanism that can also play a role.

Tags: HTTP State Management