Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is something I haven't been able wrap my head around, if BREACH allow leaking of information, do we have to mask or generate CSRF token in a time-based or per-request fashion to make it more secure?

As far as I know, session-based CSRF token can protect user from CSRF just fine. But how accurate is this in context regarding SSL? The problem here is no longer whether attacker can perform CSRF, but whether such CSRF token can be extracted from HTTPS with compression on, even be used to leak other information?

Basically I am asking if this older question now have an different answer.

share|improve this question

To answer your question: It is still secure, if you dont use session-based CSRF-tokens AND HTTP-Compression (see explanation below)

from / Am I affected?

If you have an HTTP response body that meets ALL the following conditions, you might be vulnerable:

  • HTTP-Compression Your page is served with HTTP compression enabled (GZIP / DEFLATE)
  • User Data: Your page reflects user data via query string or POST parameters
  • A Secret: Your application page serves PII, a CSRF token, sensitive data

Mitigations / ordered by effectiveness

  1. Disabling HTTP compression
  2. Separating secrets from user input
  3. Randomizing secrets per request
  4. Masking secrets (effectively randomizing by XORing with a random secret per request)
  5. Protecting vulnerable pages with CSRF
  6. Length hiding (by adding random number of bytes to the responses)
  7. Rate-limiting the requests

share|improve this answer
Protecting vulnerable pages with CSRF - the page doesn't really go into what type of CSRF token implementation is secure, which is more or less my question. – bitinn Oct 11 '13 at 8:19
One of the migitations is randomizing secrets per request as opposed to a secret per session, so isnt this answer is also saying; No it is not secure to use session based csrf – Philipp Oct 11 '13 at 12:31
@Philipp: No it is not secure to use session based csrf + HTTP-Compression; i cleared my answer – that guy from over there Oct 11 '13 at 13:26
@bitinn It means instead of using CSRF only on POST requests (and requests that perform an action on the server), you also use it for any GET request that displays user input in the HTML.The attack relies on the fact that the attacker can force the browser to send requests to your URL. If you use CSRF, he can't. – user3576887 Mar 14 at 8:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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