ZIP-Bombing Vulnerability Scanners
Christian Haschek recently posted the article How to defend your website with ZIP bombs; the gist is that by compressing a whole lot of zeros, we can potentially cause a scanner to eat up a bunch of memory and CPU time. Gzip compresses down to about 1MB per GB of zeros, so this only uses a moderate amount of bandwidth but could have a big impact when decompressed.
While Christian used a PHP script to handle sending the response, which is much easier to match against a set of user agents or URLs, I figured that this could also be handled by Apache.
With some guidance from Drupal’s default .htaccess to handle serving pre-compressed versions of static assets, I ended up with this:
Zopfli is a newer application for gzip compression that can offer better compression ratios at the expense of taking more time to compress. Since in this case the data is precompressed the additional time doesn’t matter though. Unfortunately its output isn’t any better than gzip itself on nothing but null bytes, giving the same 1MB per GB result, so the limitation is likely in the compression format.
Brotli is a newer compression format, already supported by Chrome, Firefox, Edge, and soon in Safari. Compressing null bytes took about 2 minutes per gigabyte on my Macbook, so after just over an hour I have 32GB of zeros compressed down to only 423K. It’s less likely that scanners will support brotli, but here we can give an extra surprise to those that do with substantially less bandwidth usage than gzip.
It took Chrome 6.2 minutes at 250% CPU to process the 32GB brotli file on my Macbook