Can BREACH be thwarted by simply adding a sort of "salt" into the page being compressed?

Question

Django supplies GZip middleware, but the docs issue a stark warning about BREACH, which I had, hitherto, forgotten about. The first thought I had was that I should be able modify the middleware to first add a random amount of random characters into the request body before GZipping it, and render BREACH useless. Is this correct, or am I completely misunderstanding BREACH?

Answer 1

If you have always the same amount of random data the attack will probably still work in the same way. If you instead add a random amount of random data the original attack might not work any longer but I think it can be modified by simply trying again and again in the hope that the same amount of random data is added often enough. Which means it will slow down the attack only and how much depends on the amount of random data you add. For example if you add between 1 and 10 random characters at the top of the file it will probably only slow down the attack by a factor of 10. If you add 1..100 characters the slowdown will be factor 100.

A better approach would be to create some random value and modify the CSRF token so that it will consist of this random value and an XOR or with this value with the original CSRF token. This way the CSRF token will change all the time inside the HTML so that BREACH will no longer work. And the application can easily get the original CSRF token back.

Answer 2

add a random amount of random characters into the request body before GZipping it

This will slow down the attack, but not prevent it.

The idea behind BREACH (and compression oracles in general) is that the plaintext (and therefore the ciphertext) will be slightly shorter if the attacker guesses the next byte of the secret token correctly. If there is some randomness in the plaintext length, the attacker can make the same guess many times and "average out" the results. Requests made using the correct guess will be slightly shorter on average.

(A real attacker would use a more sophisticated statistical technique to reduce the number of requests required, but you get the idea.)