On Tue, Aug 20, 2013 at 5:12 PM, rmalayter <nginx-forum@nginx.us> wrote:
> No, the conclusion is: don't echo back values supplied by the requester as
> trusted in your *application* code. This is the most basic of
> anti-injection
> protections. BREACH is the result of an application-layer problem, and
> needs
> to be solved there. Why would you *ever* echo arbitrary header or form
> input
> back to the requester alongside sensitive data?
>
> A huge number of established security best practices prevent the BREACH
> attack at the application layer; a man-in-the-middle as well as an
> exploitable XSS/CSRF vulnerability is needed to even get the attack
> started.
> Fix those issues first. Also, you should likely be rate-limiting responses
> by session at your back-end to prevent DoS attacks. For the extra paranoid,
> randomly HTML-entity-encode characters of any user data supplied before
> echoing it back in a response, and add random padding of random length to
> the HEAD of all responses.
>
> At the nginx layer, some sensible rate limits might also be an appropriate
> mitigation: thousands-to-millions of requests are needed to extract secret
> data with BREACH.
>
> I haven't seen Google or any other large web site turn of gzip compression
> of HTTPS responses yet because of BREACH. If *you* can actually afford to
> do
> so, your traffic level is simply trivial. We would see approximately an 8x
> increase in bandwidth costs (and corresponding 8x increase in end-user
> response time) if we disabled GZIP for HTTPS connections.
>
I took a shortcut.
You're right: deactivating gzip compression is usable only for relatively
small websites.
Anyway, I wonder which real-world scenario need to send back user requests
in its answers... maybe some application need this? I can't imagine a
serious use-case however.
For a quick cheat-sheet on possible mitigations, starting with the most
radical ones, some advice has already been provided here:
http://breachattack.com/#mitigations.
I maintain the 'turn the gzip compression off' piece of advice here, as I
suspect people managing HA or populated websites already understand the
problem deeper and don't need to ask on a specific webserver's mailing list
what 'recommendation' they provide... Thus I guess What I wrote fits the
audience here.
---
*B. R.*
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx