On Tue, Aug 20, 2013 at 5:12 PM, rmalayter <[email protected]> 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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
