3 ms·

This would cause a big problem for us. we mobile web service serves around 3-4k concurrent requests on average. without compression our API would take 300% - 9

• pudquick 13y ago
  As gzip compression only applies to the content of the page, not the headers, I would assume that prefixing your page with content that is variably compressible and of varying lengths would throw a monkey wrench in the attacks. The compressed content of any part of a page very much depends on what came before it. Altering the content to include a script comment block full of random text and various common HTML and JavaScript elements (Markov chains anyone?) would definitely change how a page is compressed. If the compressed length of the replies varies significantly with every request - even if the request content is identical - attacks like this can no longer reveal hidden information. Edit: You could improve this significantly by including false positive matches as well. If your HTML content has: csrf="45a7..." in it, you could hash that content into enough material to generate 19 or so identical looking code blocks embedded in a script comment. You've now provided a 95% chance they attack the wrong one / increased the number of attacks they'll need to try by 20x. This method (minus the above part) would actually be cacheable by smart CDNs like Cloudflare.
  • Daniel_Newby 13y ago
    Random padding can be averaged out. It increases the work factor of the attack, but not by much.