BREACH attack works by trying to guess the secret keys in a compressed and encrypted response. Attacker sends many targeted requests to the server and try to figure out the encrypted information byte-by-byte using the pattern in responses.
When you run a penetration test on your web application, the report may point out BREACH as a high-risk vulnerability. Here is an example vulnerability test report that mentions the BREACH:
'id' : 'BREACH',
'ip' : 'domain.com/10.194.54.67',
'port' : '443',
'severity' : 'HIGH',
'cve' : 'CVE-2013-3587',
'cwe' : 'CWE-310',
'finding' : 'potentially VULNERABLE, uses gzip HTTP compression - only supplied '/' tested'BREACH stands for Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext and it is similar to the CRIME attack.
Mitigations for the BREACH vulnerability
Common recommendations for fixing this vulnerability are:
- Disabling HTTP compression
- Separating secrets from user input
- Randomizing secrets per request
- Masking secrets (effectively randomizing by XORing with a random secret per request)
- Protecting vulnerable pages with CSRF
- Length hiding (by adding a random number of bytes to the responses)
- Rate-limiting the requests
My comments about these mitigations:
- The first option (disabling HTTP compression) will certainly mitigate this vulnerability and the scan tool won’t bring it up anymore. However, this may have a performance effect
- Recommendations from #2 to #5 are related to the coding of the application. They are effective for preventing this type of attack. They are also best practices for development in general
- Recommendations #6 and #7 are hosting-related settings. You may need to talk to your hosting company to find out if they are applicable
One question to ask is: How is the scan tool determining to raise this vulnerability or not? (The owner of the tool can provide this information) Is it just checking if the compression is enabled? If that’s the only check it does for the determination of this vulnerability, then recommended mitigations from #2 to #7 won’t make this vulnerability disappear in the report.
My recommendation would be to keep the compression enabled but implementing the other recommendations (from #2 to #7). However, as I explained in the previous paragraph, the tool may still raise a flag even if you implement all those mitigations.
For more information about the common recommendations, click here. More details about this vulnerability can be found here.