How to defend your Web apps against the new BREACH attack

The new exploit lets attackers snag sensitive Web application data even if it's protected by SSL

At Black Hat last week, researchers revealed a new hacking technique called BREACH that enables attackers to snag SSL-secured Web application data, including login tokens and session ID numbers. The reseachers dubbed their presentation "SSL, Gone in 30 Seconds," because 30 seconds is about how long it would take a would-be malicious attackers to pull off the hack.

BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) is a close cousin of the CRIME (Compression Ratio Info-leak Made Easy) exploit, which also enables attackers to swipe SSL-protected data. Any Web app can be vulnerable to BREACH, so long as it's delivered from a server the uses HTTP-level compression, it reflects user input in HTTP responses bodies, and it reflects a secret -- such as a CSRF (Cross-Site Forgery Request) token -- in the response body.

The news has grabbed the tech industry's attention. Django co-creator Jacob Kaplan-Moss, for example, issued a security advisory today: "BREACH may be used to compromise Django's CSRF." Fortunately, the researchers -- Angelo Prado, Neal Harries, and Yoel Gluck -- and other experts in the field have provided some mitigation techniques to defend against the attack.

The key difference between BREACH and CRIME is that CRIME recovers the headers of an HTTP request, like cookies delivered during authentication, while BREACH takes advantage of HTTP responses, which are compressed using mechanisms like GZip and deflate, according to Omar Santos, incident manager at Cisco. Further, CRIME relies on TLS-level compression, and BREACH does not. (There's a thorough report about the BREACH attach available.)

According to Santos, there are several ways for organizations to reduce the risks associated with BREACH. One option is to disable HTTP compression, though Santos cautioned that doing so could adversely affect Web-app performance.

Django's Kaplan-Moss similarly advised disabling compression of Web responses. For Django apps, that could entail disabling Django's GZip middleware or disabling GZip compression for your Web server's configuration. "For example, if you're using Apache, you'd want to disable mod_deflate; in nginx you'd disable the gzip module," he wrote.

He added that you should ensure you disable TSL compression by adjusting your server's SSL ciphers.

Another BREACH mitigation technique option: "Separating secrets from user input by using input-less servlets and chunked secret separation."

He mentioned a third technique, which would be to embrace CSRF best practices. Alternatively, one could "'perform randomization' and masking by XORing with a random secret per request; however, this could also be tricky and requires an application change."

Yet another option: Set a rate limit on requests coming from the same client IP to the same server/application. This could be effective in that the attack requires hundreds if not thousands of those types of requests. "However, it is not uncommon for certain applications/implementations (for example, JSON) where clients could generate numerous requests," Santos cautioned.

This story, "How to defend your Web apps against the new BREACH attack," was originally published at Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest developments in business technology news, follow on Twitter.

Copyright © 2013 IDG Communications, Inc.