I was just reading about CRIME which is an attack to steal sensitive information by creating requests. Could this attack be mitigated, if the Server wouldn't send the client the actual session key to save in a cookie, but a random generated string, which maps to the session key? On each request (or every 100 requests) this random string is generated anew, so the client will have an ever-changing secret in his cookie.

This would make any attacks which require many requests which contain the same secret very difficult and would also provide the benefit that each of the random strings is only valid for a very short time...

Are there any obvious downsides to this approach? Or anything which wouldn't actually make it safer than today methods ?

  • Well, CRIME specifically can easily be entirely mitigated by turning off compression. (Or, at least, not compressing secrets like cookies.) Aug 6, 2014 at 16:37

2 Answers 2


In the case of CRIME, the attack is on the client. Hostile Javascript in the client triggers requests to the server, that the attacker observes from the outside; and (that's the important point here) the attacker can block the outgoing request. The attacker needs to see the encrypted records, but not necessarily to let them go all the way to the server.

Thus, during all the attack, the server never sees any request with the cookie in it. Even if the server changed the cookie for every request (a "one-time-cookie"), the attack would still work.

  • Good Point! But the attacker would need a way to send the request to the LAN, where he can sniff it, but still prevent it from reaching the Server. - The request would have to go to the server-domain though, because any other URL would not get the cookie delivered. - If he would block the request alltogether the browser would wait until timeout. And he cannot interfere in any other way because of HTTPS...
    – Falco
    Nov 6, 2014 at 11:51
  • 1
    The usual scenario is one where the attacker sets up and maintains a fake WiFi access point -- that is, a very real access point, but not the one the victim expected to connect to. That way, the attacker can easily see and alter all traffic. As for "blocking" the request, the attacker would send a RST packet so as to break the connection and thus avoid having the browser wait forever (the breakage won't be visible to the user since the connection was for a request triggered from the hostile Javascript, that acts "under the hood"). Nov 6, 2014 at 13:03

Perhaps, but if there is a script performing attacks with the session cookie immediately after it is intercepted the damage will already be done. If a person is interacting with the session data they may not be able to act fast enough. Really, this means that you would be mitigating untargeted or unsophisticated attacks.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .