Updated: Comment #N
Problem/Motivation
Moving this into a public issue form the security team tracker, since the attack is a general one on web servers, and not specific to Drupal, and the information is already public.
Django made a security announcement regarding the BREACH attack:
https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/
Their approach of suggesting you turn off gzip/deflate seems infeasible for most people.
There's more information here: http://breachattack.com/
Drupal is less vulnerable than many web applications, since the CSRF token is usually different per form.
However, if a sensitive or administrative form is on the same page with a form without CSRF protection (e.g. a search form that takes values from the query string), it's possible to be vulnerable to this attack. You could also be vulnerable if there is other sensitive data on a page that includes such a form.
Also, this attack is more effective against a stream cipher like rc4, which many people witched to using due to the BEAST attack.
Proposed resolution
Possible suggested BREACH mitigations:
- 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 random number of bytes to the responses)
- Rate-limiting the requests
#1, #2, and #3 don't seem very feasible.
#4 could be pretty trivially implemented by essentially splitting the form token into 2 parts - a secret that's constant (essentially what we send as the token today), and a XOR mask that varies on every request. The the valid token check would XOR the 2 parts and compare to the expected secret.
#5 We already protect most forms and actions against CSRF, so Drupal start out from a relatively strong position against this attack already.
#6 should be easy to implement as well:
At least for BREACH and possibly for the vulnerabilities described at http://www.isg.rhul.ac.uk/tls/ for rc4, a possible counter-measure would be injecting a random number of random bytes as a header, and also injecting a random number of random bytes into the HTML content (e.g. in the HEAD section)
#7 seems more suitable to a WAF or load balancer outside Drupal.
Remaining tasks
pick 1 or more aproaches and implement
User interface changes
N/A
API changes
Possible changes to token generation/checking, but these could be transparent at the API level