4

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.

1

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


from breachattack.com / 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

  • 1
    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 Gayret 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. – elipoultorak Mar 14 '16 at 8:44
1

If your site is vulnerable to BREACH, an attacker can guess anything in the body of the response one character at a time. The attacker does multiple requests, one per guess, and can see if he guessed correctly. For example, the attacker may try these guesses:

  • csrftoken=a
  • csrftoken=b
  • csrftoken=c
  • etc.

After a while he figures out the first character of the token, and moves on to the next character. As you can see there are hundreds of requests needed to guess the whole CSRF token.

This attack only works if the same CSRF token is returned in all requests. If the token differs between requests, the attacker can not use multiple requests to guess it. So to protect against the BREACH attack, the CSRF token should be different on each page.

However, it is not necessary to create a new token for each request. Simply obfuscating the CSRF token is sufficient. You could encrypt or even XOR the CSRF token with some salt you include in the form, as Django and Rails do. This means that the token is different on each page, but you still have to check only one value in the backend.

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.