Most of the discussions about the BREACH vulnerability are around stealing session-based CSRF tokens. But if you can steal a session-based token, could you also steal the session token itself? Obviously there are some finer points of the BREACH attack which I don't understand :)

I'm specifically interested in Django. In all requests for which browser sends a csrftoken cookie, the browser also sends a sessionid cookie.


If my newfound understanding is correct, then the answer is trivially NO. The BREACH paper says:

To be vulnerable to this side-channel, a web app must: (1) Be served from a server that uses HTTP-level compression, AND (2) Reflect user-input in HTTP response bodies, AND (3) Reflect a secret (such as a CSRF token) in HTTP response bodies.

Do (2) and (3) refer to the same thing? That is, is the attack only possible if the user-input repeated in the HTTP response body is THE SAME THING as the secret you're trying to steal?

If this is correct, then it makes sense.

You can steal an CSRF token, because it's inputted by the user (generally either via a form POST param or cookie), AND it may be repeated again in the response (either as hidden input to a form, or as a cookie), AND it's the secret that you're trying to steal.

You can't steal a session token, because the user can't alter the output based on that input. I mean, sure, the user can submit an altered session cookie, but the server (hopefully) won't ever repeat that invalid session token in the response.


So BREACH is an attack specifically against response bodies, not headers. Since cookies are sent as headers, they aren't susceptible to the technique described by BREACH, but have been vulnerable to other compression side-channel attacks such as CRIME.

What they mean by:

(2) Reflect user-input in HTTP response bodies, AND (3) Reflect a secret (such as a CSRF token) in HTTP response bodies.

Is that (2) the attacker must be able to submit user input that he controls that is then added to the response body in such a way that he can submit guesses as to what the secret is, and (3) the application must also contain the secret he's guessing in the response body.

What this does is it creates an oracle. Because it's attack on compression, he's submiting guesses for the first part of the secret, and when his guess is correct, it will cause the response body to be slightly shorter, because the duplication between his guess and the real secret will be eliminated by the commpression algorithm. So, in simplictic terms, he keeps guessing a character at a time until he gets the correct next character, and the response body becomes a byte shorter. Then, he moves to the next character and repeats the process until he knows the full secret.

| improve this answer | |
  • Thanks! Out of curiosity, why doesn't the attack work against headers? – simmbot Feb 27 '15 at 23:25
  • 1
    Ah, I see. It's because this attack relies on HTTP compression, and HTTP only allows compression on the response body. – simmbot Feb 27 '15 at 23:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.