3 ms·

I think the idea is to find e.g. a query string parameter that gets reflected back in the response's HTML along with a target secret. The attacker can then spaw

by sdevlin 13y ago

I think the idea is to find e.g. a query string parameter that gets reflected back in the response's HTML along with a target secret. The attacker can then spawn requests and monitor the size of the response.

AnIrishDuck 13y ago
This sounds like the most plausible theory, though it makes the attack pretty limited. It could bypass CSRF protections, which don't work with GETs. So it sounds like an attacker needs an endpoint that contains sensitive information and puts information from a request's query parameters into the response body. I imagine tons of applications do this, but it's nowhere near as far reaching as CRIME.
- sdevlin 13y ago
  In many web application frameworks, CSRF tokens are session scoped. So an attack might look like this: 1. User logs in to target web app (e.g. hapless.com). 2. User visits your malicious content (e.g. evil.com). 3. Your page does a BREACH attack, issuing tons of HTTPS GET requests (by creating images in JavaScript, maybe) to hapless.com with query string parameters that manipulate the response. 4. You observe the responses and recover the CSRF token. 5. You attack the user with a standard CSRF attack on evil.com or elsewhere. Note that this attack requires the user to interact with attacker-controlled content via a MITM'd connection. > I imagine tons of applications do this, but it's nowhere near as far reaching as CRIME. This is very common in web applications. Echoing query string parameters in the server response is the basis for reflected cross-site scripting, for example. And in a complex web application, tons of pages will have CSRF tokens embedded somewhere. I do agree that CRIME is a much more dangerous attack.
  - AnIrishDuck 13y ago
    Yeah, the more I think about this, the worse it is. It's certainly not as general as the original CRIME TLS exploit, but that almost makes it more insidious. The big problem is that there's no blanket solution to this like there was with the TLS break. Then you could just turn off TLS compression, which wasn't a huge deal. Now, turning off HTTP compression is a much bigger problem. You're going to take a huge performance hit. The alternative is auditing every route in your application to ensure that it won't leak attacker info into a response - a very daunting proposition.

by sdevlin 13y ago

AnIrishDuck 13y ago

This sounds like the most plausible theory, though it makes the attack pretty limited. It could bypass CSRF protections, which don't work with GETs. So it sounds like an attacker needs an endpoint that contains sensitive information and puts information from a request's query parameters into the response body. I imagine tons of applications do this, but it's nowhere near as far reaching as CRIME.

sdevlin 13y ago
In many web application frameworks, CSRF tokens are session scoped. So an attack might look like this: 1. User logs in to target web app (e.g. hapless.com). 2. User visits your malicious content (e.g. evil.com). 3. Your page does a BREACH attack, issuing tons of HTTPS GET requests (by creating images in JavaScript, maybe) to hapless.com with query string parameters that manipulate the response. 4. You observe the responses and recover the CSRF token. 5. You attack the user with a standard CSRF attack on evil.com or elsewhere. Note that this attack requires the user to interact with attacker-controlled content via a MITM'd connection. > I imagine tons of applications do this, but it's nowhere near as far reaching as CRIME. This is very common in web applications. Echoing query string parameters in the server response is the basis for reflected cross-site scripting, for example. And in a complex web application, tons of pages will have CSRF tokens embedded somewhere. I do agree that CRIME is a much more dangerous attack.
- AnIrishDuck 13y ago
  Yeah, the more I think about this, the worse it is. It's certainly not as general as the original CRIME TLS exploit, but that almost makes it more insidious. The big problem is that there's no blanket solution to this like there was with the TLS break. Then you could just turn off TLS compression, which wasn't a huge deal. Now, turning off HTTP compression is a much bigger problem. You're going to take a huge performance hit. The alternative is auditing every route in your application to ensure that it won't leak attacker info into a response - a very daunting proposition.