3 ms·
The cookie jar isn't the only place the cookie could be leaked from. For example, it could be leaked from: * Someone inspecting the page with developer tools
by thayne 1y ago
The cookie jar isn't the only place the cookie could be leaked from. For example, it could be leaked from:
* Someone inspecting the page with developer tools
* Logs that accidentally (or intentionally) contain the cookie
* A corporate (or government) firewall that intercepts plaintext traffic
* Someone with temporary physical access to the machine that can use the TPM or secure enclave to decrypt the cookie jar.
* A mistake in the cookie configuration and/or DNS leads to the cookie getting sent to the wrong server.
This would protect against those scenarios.
- dgoldstein0 1y agoThat last one should largely be solved by 1) TLS 2) make your cookie __Secure- or __Host- - which then require the secure attribute. If DNS is wrong, it should then point to a server without the proper TLS cert and your cookie wouldn't get sent.
- peanut-walrus 1y agoOops your developer accidentally enabled logging for headers. Now everyone with access to your logs can take over your customer accounts.
- londons_explore 1y agoYou could have similar secure handling of cookies on your server. For example, the server could verify the cookie and replace it with some marker like 'verified cookie of user ID=123', and then the whole application software doesn't have access to the actual cookie contents. This replacement could be at any level - maybe in the web server, maybe in a trusted frontend loadbalancer (who holds the tls keys), etc.
- thayne 1y agoIf DNS is wrong, that server can get a domain validated certificate. What I am imagining here is that you set a cookie with Domain set, and not __Host, possibly because you need the cookie to be accessible on multiple domains, and then someone sets up a CNAME that points to a third party hosting service without thinking about the fact that that would leak the cookie. Sure