HTTP Compression Enabled — Potential for Sensitive Data Leakage via BREACH

Vulnerability Explanation

BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) is a compression side-channel attack that targets HTTP-level response compression (gzip, Brotli, deflate). When a server compresses responses that contain both attacker-controlled input and a secret (e.g., a CSRF token), the attacker can observe changes in compressed response sizes across many crafted requests to recover the secret byte-by-byte. The attack works because compression algorithms like DEFLATE/LZ77 produce shorter output when repeated byte sequences are found — so when the attacker's guess matches part of the secret, the response is measurably smaller. This is entirely independent of TLS version or cipher suite; it operates at the HTTP layer above TLS.

Root Cause

HTTP compression is applied to the full response body before encryption. Because the length of the encrypted payload is still observable (ciphertext length leaks plaintext length after compression), an attacker who can observe ciphertext lengths and influence part of the plaintext can mount a chosen-plaintext oracle attack. The vulnerability is not a bug in a specific library but a structural weakness in combining compression with encryption when attacker-controlled data and secrets share the same compression context.

Technical Impact

An attacker who can observe the victim's encrypted traffic (e.g., via a network vantage point or by tricking the victim into visiting a malicious page with hidden iframes) can recover secrets from HTTP responses — including CSRF tokens, session identifiers, email addresses, or other sensitive values reflected in the response body. The attack can be completed in under a minute with a few thousand requests. Practical exploitability requires: (1) HTTP compression enabled, (2) attacker-controlled input reflected in the response, and (3) a secret present in the same response body.

Severity Justification

CVE-2013-3587 has no official CVSS score from NVD, but the attack requires multiple preconditions: the attacker must be able to observe encrypted traffic AND the application must reflect user input alongside secrets in compressed responses. Many applications do not meet all conditions, reducing real-world exploitability. The scanner only tested '/' and cannot confirm the full attack chain is viable.

Affected Components

• HTTP compression (gzip) — all versions when combined with secret reflection
• HTTP compression (Brotli/br) — all versions when combined with secret reflection
• Any web framework or server with HTTP response compression enabled globally

Remediation Steps

1. Audit which pages reflect user-controlled input (query params, POST data, URL fragments) in the response body alongside secrets such as CSRF tokens. These are the only pages at real risk.
2. Preferred mitigation — disable compression on cross-origin requests: configure your web server to suppress the Content-Encoding response header when the Referer header is absent or does not match your own origin. This preserves compression for same-origin traffic while blocking the attack vector.
3. Alternative mitigation — add response length randomization (Heal-the-BREACH / HTB): inject a random number of padding bytes into each response to prevent the attacker from reliably measuring size differences. This is the most transparent mitigation with no functional impact.
4. Alternative mitigation — separate secrets from reflected input: restructure pages so that CSRF tokens and other secrets are not in the same response body as user-reflected content. Deliver tokens via a separate API call or HTTP header.
5. Ensure all session cookies are set with SameSite=Strict or SameSite=Lax — this prevents cross-site requests from carrying cookies, breaking the attacker's ability to force authenticated requests.
6. If none of the above is feasible in the short term, disable HTTP compression globally as a last resort — note this will have a bandwidth and performance impact.

Verification Steps

1. Run: curl -sI -H 'Accept-Encoding: gzip, br' https://yourdomain.com/ | grep -i content-encoding — if no Content-Encoding header is returned, compression is disabled.
2. For referrer-based mitigation, test: curl -sI -H 'Accept-Encoding: gzip' -H 'Referer: https://evil.example.com/' https://yourdomain.com/ | grep -i content-encoding — the response should NOT include Content-Encoding: gzip.
3. Re-run testssl.sh against your domain after applying mitigations: testssl.sh --breach https://yourdomain.com/ — the BREACH finding should be downgraded or cleared.
4. Verify SameSite cookie attribute: curl -sI https://yourdomain.com/ | grep -i set-cookie — confirm SameSite=Lax or SameSite=Strict is present on session cookies.

Best Practices

• Never compress responses that contain both user-reflected input and secrets in the same body — separate these concerns at the application layer.
• Apply SameSite cookie attributes universally; this is a low-effort, high-value defence against multiple cross-site attack classes.
• Use per-request randomized CSRF tokens (rather than session-scoped static tokens) to reduce the value of any extracted token.
• Monitor for anomalous request volume to the same endpoint from the same client — BREACH requires thousands of requests and is detectable with basic rate limiting.

References

• cve.mitre.org/cgi-bin/cvename.cgi
• www.breachattack.com/
• en.wikipedia.org/wiki/BREACH
• docs.veracode.com/r/prevent-ssl-breach
• www.acunetix.com/blog/articles/breach-attack/