New attack plucks secrets from HTTPS-protected pages

Re:New attack plucks secrets from HTTPS-protected pages by sdevlin on Thursday August 01, 2013 @03:00PM (#6142628)

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.

[ Parent | on HN ]

Re:New attack plucks secrets from HTTPS-protected pages by AnIrishDuck on Thursday August 01, 2013 @03:22PM (#6142794)

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.

[ Parent | on HN ]