2

How does an application control whether or not its http content is compressed? I am not talking about TLS level compression, but rather about the compression of https:// response bodies only.

In cases where the response contains both anti-CSRF tokens and user reflected input, I believe such compression can lead to a BREACH compromise. So, then, how do I choose not to compress those responses?

1 Answer 1

2

HTTP compression is controlled by the webserver, you configure IIS/Apache/Other as appropriate and this sets the compression header which your browser understands and treats the content as accordingly.

BREACH is a vulnerability in applications that use HTTP compression, reflect some sort of user input and also reflect a secret, such as - as you say - a CSRF token. the attacker then takes advantages of differences in the response sizes to determine secrets. There is a good explanation of BREACH here

Simple mitigations include disabling the compression which or may not be practical depending on your application. As the compression is performed at web server level, determining when to compress in the application may be tricky, a simpler approach is to inject noise the response on pages which are vulnerable. A random string of random length injected into the response is a good countermeasure if you wish to keep compression enabled.

Not the answer you're looking for? Browse other questions tagged .