Thoughts On BREACH

Posted Fri Aug 09 @ 07:10:30 PM PDT 2013

A new attack on HTTPS was recently published by Angelo Prado, Neal Harris and Yoel Gluck. It created quite a stir and now there are calls to disable gzip compression in HTTP responses. On how practical the attack is, the authors say:

The BREACH attack can be exploited with just a few thousand requests, and can be executed in under a minute. The number of requests required will depend on the secret size. The power of the attack comes from the fact that it allows guessing a secret one character at a time.


For the attack to work, three conditions must be met by the web app:

  1. Some form of HTTP-level compression must be used
  2. The HTTP response must reflect user input (for example, outputting one of the GET parameters)
  3. The page must contain a secret (otherwise, what motivation is there for the attack?)

The attacker must be able to:

  1. View the victim's encrypted traffic
  2. Send HTTP requests to the vulnerable web server on behalf of the victim

Item #2 can be accomplished by tricking the victim into viewing a website controlled by the attacker (which would contain a malicious iframe) or by modifying the content of any HTTP response not over SSL (the attacker could inject an iframe into the response directly).

If we assume the attacker has wedged himself snugly between the victim and the web app, it seems just about every web application is vulnerable. After all, what web app isn't (1) using gzip, (2) reflecting input, and (3) displaying secret data?

I've built a lot of web applications in my day, and after thinking about all those apps, I've come to the conclusion that conditions 2 and 3 are rarely met at the same time. Typically, the GET parameters reflected back to the user will be some kind of numeric ID, which is (hopefully) validated before the response is generated. When the range of values accepted by the GET parameter is so restricted, the attacker cannot craft the necessary string to extract part of the secret. When the range of values accepted by the GET parameter is large (like on a search page that accepts an arbitrary string), the HTTP response typically doesn't contain secrets (assuming the actual search results aren't secret, and the page isn't generating a CSRF token).

But user input can come from POST parameters too. So what about that? Let's assume the attacker can make arbitrary POST requests to the vulnerable web server on behalf of the victim. The web application should reject every POST request because the CSRF token is missing or invalid.

However, if the attacker can retrieve a valid CSRF token from a BREACH vulnerable page (like a search page), then he can make arability POST requests on the victim's behalf. At that point, the victim is in trouble.

<< Home