I am not an information security expert (just a developer) and recently discovered this kind of vulnerability, and have a few questions (so sorry if I misinterpreted something about how the attack works).
In the product I am developing where i'm employed, there are two cookies, a regular session cookie and a cookie with an authorization token inside (it is not relevant why I need two cookies).
Both live as long as the session is live, but because i am a bit paranoid i made the authorization token encrypted.
What I mean is that the random string (the authorization token) that never changes (server-side) through the session lifespan is not sent in plaintext (the client never knows his authorization token) but is encrypted with AES CBC before sending it to the client. I think it's particularly relevant that IV is changed for each request, so basically authorization token is a constant 200B long sting, of random data that changes for each request.
Is that enough to break the relation between compressed text and length, or does the relation also involve where data are?
I mean if the session cookie (that an attacker would like to guess) is at the beginning of the request, and the random authorization cookie is at the bottom, even if randomized it's too far to give me any benefit (I expect gzip have some locality in applying compression).