Cookie-Attribute request header proposal

In https://github.com/httpwg/http-extensions/issues/223 the idea of a Cookie-Attribute request header was suggested as a way to inform HTTP servers if a cookie could be trusted or not, without breaking backwards compatibility.  It would work as follows in the hypothetical request to https://example.com/:

   GET / HTTP/1.1
   Host: example.com
   Cookie: tz=America/Los_Angeles;SESSIONID=a1b2c3
   Cookie-Attribute: ;Secure,HttpOnly,SameSite=Strict

The order of the attributes would match the order of the cookies. In the above example, the server could be confident that the SESSIONID cookie was set over a secure connection and was not vulnerable to being set via an XSS attack. It can also infer that the tz cookie may have been set by an untrusted party, and might choose to ignore it.

To accommodate more security and non-security related use cases, the Cookie-Attribute header could also include all of the other attributes, like Domain, Path, Expires.  Due to header size concerns they probably shouldn't be included by default.  Servers could opt-in to receiving these additional attributes by setting a uniquely named cookie that enumerates desired attributes, like "__Cookie-Attribute=Path,Domain". This could be useful when debugging, deleting cookies, and distinguishing between multiple cookies with the same name.  Example:

   GET /index HTTP/1.1
   Host: www.example.com
   Cookie: analyticsId=1;analyticsId=2;__Cookie-Attribute=Path,Domain
   Cookie-Attribute: Path=/,Domain=www.example.com;Path=/index,Domain=.example.com;Path=/,Domain=www.example.com

Known concerns:
   - Sending a new header and attributes increases the request size (per mnot's suggestion, this could be partially mitigated by abbreviating the header to something like "Cookie-A: ;S,H,SS=S" in the first example)
   - Opt-in security means a long road to adoption
   - Overlaps with Secure flag improvements in https://github.com/httpwg/http-extensions/blob/master/draft-ietf-httpbis-cookie-alone.md

Thoughts?

David Eckel

Received on Saturday, 3 September 2016 08:13:25 UTC