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.


1 Answer 1


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.

  • Thanks! Out of curiosity, why doesn't the attack work against headers?
    – simmbot
    Feb 27, 2015 at 23:25
  • 2
    Ah, I see. It's because this attack relies on HTTP compression, and HTTP only allows compression on the response body.
    – simmbot
    Feb 27, 2015 at 23:34
  • 1
    Actually, if for some reason, the cookie is reflected in the answer, it might be leaked through BREACH. This might be the case, if the server uses a "Double Submit Cookie" technique (cheatsheetseries.owasp.org/cheatsheets/…) or if the cookie is somehow reflected in some error message.
    – ysdx
    Jun 24, 2021 at 14:41
  • @ysdx How is the CSRF Token reflected in the response body using the "Double Submit Cookie" technique? In a response, the CSRF Token is placed in a cookie. You first place the CSRF Token during a request in the body. I'm no expert, but isn't the "Synchronizer Token" a technique where the CSRF Token is sent via an AJAX, hence the response body?
    – Advena
    Apr 1, 2023 at 19:23
  • 1
    @Tanckom, In the double submit cookie approach, the client sends the cookie and sends the same value in some request parameter (eg. csrf=${cookie_value}). This might be implemented by having the server send HTML forms with a hidden `<input type="hidden" name="csrf" value="${cookie_value}">. In this case, the cookie value is included in the server response and might therefore possibly be exfiltrated using BREACH (assuming some reflected parameter can be triggered by the attacker).
    – ysdx
    Apr 2, 2023 at 20:42

You must log in to answer this question.

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