When you run a penetration test on your web application, the report may point out BREACH as a high-risk vulnerability. BREACH attack works by trying to guess the secret keys in a compressed and encrypted response. Attacker makes many requests and try to figure out the encrypted information byte-by-byte using the pattern in responses.
Here is an example vulnerability test report that mentions the BREACH:
'id' : 'BREACH',
'port' : '443',
'severity' : 'HIGH',
'finding' : 'potentially VULNERABLE, uses gzip HTTP compression - only supplied '/' tested'
Mitigations
Common recommendations:
- 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 mitigate this vulnerability. However, this may have a performance effect
- Recommendations #2 to #5 are related to the coding of the application. They can help preventing this attack. They are also best practices for development
- Recommendations #6 and #7 are hosting-related. You may need to talk to your hosting company to make these changes
The question is how the scan tool is determining to raise this vulnerability? Is it just checking if the compression is enabled? If that’s the only check it does, then recommended mitigations from #2 to #7 won’t make this vulnerability disappear from the report.
My recommendation would be to keep the compression enabled but implementing the other recommendations (from #2 to #7).
