Cookies with secrets should be encrypted.

[jensmeindertsma]

Currently cookies with secrets are only signed, which can lead to security vulnerabilities as it's easy to see what's inside the cookie. Providing secrets implies that the cookie is encrypted, so I would like to ask for either a docs update to clarify this or a change to cookies such that they are encrypted when providing secrets.

[milamer]

The Django project has a big warning about this in its docs:

Warning

If the SECRET_KEY is not kept secret and you are using the PickleSerializer, this can lead to arbitrary remote code execution.

An attacker in possession of the SECRET_KEY can not only generate falsified session data, which your site will trust, but also remotely execute arbitrary code, as the data is serialized using pickle.

If you use cookie-based sessions, pay extra care that your secret key is always kept completely secret, for any system which might be remotely accessible.

The session data is signed but not encrypted

When using the cookies backend the session data can be read by the client.

A MAC (Message Authentication Code) is used to protect the data against changes by the client, so that the session data will be invalidated when being tampered with. The same invalidation happens if the client storing the cookie (e.g. your user’s browser) can’t store all of the session cookie and drops data. Even though Django compresses the data, it’s still entirely possible to exceed the common limit of 4096 bytes per cookie.

No freshness guarantee

Note also that while the MAC can guarantee the authenticity of the data (that it was generated by your site, and not someone else), and the integrity of the data (that it is all there and correct), it cannot guarantee freshness i.e. that you are being sent back the last thing you sent to the client. This means that for some uses of session data, the cookie backend might open you up to replay attacks. Unlike other session backends which keep a server-side record of each session and invalidate it when a user logs out, cookie-based sessions are not invalidated when a user logs out. Thus if an attacker steals a user’s cookie, they can use that cookie to login as that user even if the user logs out. Cookies will only be detected as ‘stale’ if they are older than your SESSION_COOKIE_AGE.

Performance

Finally, the size of a cookie can have an impact on the speed of your site.

[jasonk]

Encrypted cookies means either that none of the data in the cookie can be used in the browser, or that the information necessary to decrypt the cookie must also be available in the browser for the browser to decrypt it, which means your secrets aren't actually secret.

The most common use for cookies is to hold something like a session ID, or a user ID. If the values stored in the cookie are intended to be secret then you might want to encrypt the cookies, but if it's just something like a Session ID then you don't really gain anything by encrypting it, because there is nothing useful that someone can do with the cookie.

The warning in Django isn't really relevant, it's warning you about two things: 1. that someone who obtains your secret key can use it to create valid cookies that include any content they want (which should be obvious, that's why they are called "secrets") and 2. that if you were using the "PickleSerializer" that the cookie data can include an executable payload (that anyone would choose to use a serializer that could include executable code is the real WTF in that warning).

It's also worth nothing that the Django warning clearly says that their cookies are also signed but not encrypted.

It might be worthwhile to add an option to encrypt cookies, but I'd argue that if you are storing information in cookies that is sensitive enough to need encryption, then it makes just as much sense for you to encrypt it before putting it into the cookie, because for everybody else there is no security risk from having the cookies signed but not encrypted and nothing to gain by encrypting them.

[machour]

Converting this to a Proposal discussion, as per our Development Process.

[Markyiptw]

Isn't HttpOnly enough? Combined with signing, they ensure the cookie

• cannot be modified with third party script (unless the secret is leaked)
• cannot be read with third party script

And for the first case, your encryption key should be as safe / vulnerable as your secret, so I can't see how an encrypted cookie give you extra protection?

[ryan0x44]

Not supporting encryption of cookies on the basis that it could lead to accidentally disclosing the secret in the client highlights another issue with the current verification/use of secret: today, if you use a secret and it's accidentally disclosed to the client, you might be working on the assumption that the cookie has been signed and verified, when in fact someone can sign any cookie value themselves because they have the secret.

On that basis, I would suggest encryption should be supported, or otherwise the verification mechanism should be removed as the justification is contradictory.

Also worth noting that other communities like Rails support both signed and encrypted session cookies https://guides.rubyonrails.org/v7.0/security.html

[ryan0x44]

I've created a package which implements encryption of session cookies here: https://www.npmjs.com/package/remix-webcrypto-cookie-session

Note that this has only been tested on Cloudflare Pages platform and uses Web Crypto APIs.