Cookie Encryption - duplicate cookies
TL;DR has anyone written code to deduplicate cookies before the cookie encryption feature is used? We had a ticket C1649037 to do with the Cookie Encryption breaking if the cookie was duplicated in the server's response headers. e.g. Server says: set-cookie A hello set-cookie A hello F5 told to encrypt A says: set-cookie encrypted gfddsgde34fwqf34 set-cooke A hello e.g. F5's Cookie encryption was only encrypting one copy of a set-cookie header in the server's response. Its a minor edge case, although for the vendor we spotted it with duplicate the session cookie in response to a successful login request so the session cookie doesn’t get encrypted. Also leaking the plain text of some cookies may make cryptanalysis even easier ;) Since the ticket was raised, we mentioned it to PortSwigger Web Security, who write BurpSuite security testing tool, and they added a duplicate cookie test (they are really good with these kinds of requests). Since then it has become clear: 1) the vendor is not going to remove the duplicate cookies any time soon. 2) duplicated cookie headers are very common in web applications, although usually it is deletion where it goes wrong as the session headers are written and then the deletion. 3) HTTP/2 header compression makes it all the more complicated to diagnose as you need to ensure you have the same protocol version as the browser seeing the issue, since HTTP/2 effectively dedups cookies for you. As such I’m minded to finally address the issue by fixing the F5's behaviour. Presumably de-duplicating cookie headers before encryption. Has anyone written this already? Should be easy, but I vaguely recall at the time that the cookies were presented as an associative array. The “best” solution would be for a supported change to the F5 Cooke Encryption feature, that always prefers later cookies headers with the same name when encrypting a request from the server to the client, as this is the RFC compliance resolution that the browser should do. Cookie encryption is notoriously tricky to do right and generally shouldn't be relied on. Here we are treating it as an additional measure to discourage poking at cookies, and to avoid the issue with sensitive data in the cookies being stored in the browser for long duration. Rather than trying to obscure a known cookie parsing weakness (down this road lies madness and being hacked).Solved1KViews0likes2Comments