Verifying webserver compression - BREACH attack
A few lines of Bash script let you check which compression methods are supported by a SSL/TLS-enabled webserver.
target=URL-OF-TARGET
for compression in compress deflate exi gzip identity pack200-gzip br
bzip2 lzma peerdist sdch xpress xz; do
curl -ksI -H "Accept-Encoding: ${compression}" https://${target} | grep -i ${compression}
done
If you see any output (and the server supports one of these
compression algorithms), the site might be vulnerable to a BREACH
attack. Might, because an attacker has to 'inject' content into the
output (and have some control over it): This is called a chosen
plaintext attack.
By carefully injecting certain content to the page, an attacker is
able to deduce (parts) of the page content by merely looking at the
response size (speed). An attacker therefore also has to be able to
observe the server's response. A third prerequisite is that the secret
(that an attacker wants to steal) is contained in the server
response's body, and not 'just' in the response's header. Cookies are
therefore out of scope.
The easiest mitigation is to disable HTTP compression completely. Other less practical mitigations are adding random content to each page, which changes the compressed size per page request, rate limiting the …
more ...