> Let's let this stew for a while with security researchers doing their
> analysis on various approaches and wait and see what the security community
> as a whole recommends.
>
> My only concern to rushing out a release is that we do something equally
> dumb and end up creating a different problem for our users.
>
> We can roll out fixes as it becomes clear what the consensus is as to the
> best solution for a generalised framework like Rails.
* Be served from a server that uses HTTP-level compression
* Reflect user-input in HTTP response bodies
* Reflect a secret (such as a CSRF token) in HTTP response bodies
These things are easy to tell about your application, but are much harder for frameworks to detect generally, which is why projects like Django and Rails will take some time to evaluate exactly how to best handle this at the framework level.
It's not Django, but us over at Rails have been discussing various parts of BREACH and how we'll handle it: https://github.com/rails/rails/pull/11729
The important two comments are here: https://github.com/rails/rails/pull/11729/#issuecomment-2206... and https://github.com/rails/rails/pull/11729/#issuecomment-2208...
As http://breachattack.com/ says: These things are easy to tell about your application, but are much harder for frameworks to detect generally, which is why projects like Django and Rails will take some time to evaluate exactly how to best handle this at the framework level.