9

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.

Community
  • 1
bitinn
  • 213
  • 2
  • 5

4 Answers4

4

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.

Sjoerd
  • 28,707
  • 12
  • 74
  • 102
2

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
that guy from over there
  • 3,476
  • 17
  • 26
  • 3
    `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 08: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 08:44
1

It depends what you mean by "session based".

The BREACH attack needs to guess your CSRF token one character at a time, and it needs to make a new request for each guess. So in order to guess your CSRF token, the attacker must be able to generate many requests which all include the same token in the returned data.

If by "session based" you mean the CSRF token is:

  • Renewed at every login;
  • Only sent to the browser once at login

Then the attack wouldn't work. Even if the attacker could replay the login, they would get a new CSRF token every time so wouldn't be able to guess it.

However simply saying "session based" is not in itself secure. Your CSRF token could be the same for the session, but still gets sent back with every request. For example a lazy implementation could return Set-Cookie: csrftoken=... with every request, even though the token doesn't change.

So in conclusion: whether the token is, conceptually, session based doesn't matter. What matters is whether the attacker can do repeated requests that always return the same CSRF token.

Alice Heaton
  • 111
  • 2
0

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?

Make sure HTTP compression is disabled for any dynamic response and you should be fine.

For static content, you should be able to safely enable compression as the second condition is not met: the page does not reflect user data query string or POST parameters.

ysdx
  • 851
  • 6
  • 14