On: Defending a website with Zip bombs

[TekMol]

I don't think this "Defends" your website. If anything, it draws attention to it.

Might also be used for some kind of reflection attack. Want to kill some service that let's users provide a url (for an avatar image or something) - point it to your zip bomber.

[_pctq → TekMol]

To be fair, people wanting to do that don't need author to have create a zip bomber, they can do it by themselves.

Actually, I don't see how to defend this. Is there any way to ask a gzip file which size it will be once unzipped, without needing to decompress it?

[halomru → _pctq]

>Is there any way to ask a gzip file which size it will be once unzipped, without needing to decompress it?

The closest is uncompressing it and counting and immediately discarding the bytes in the output stream.

But of course the proper defense is to give up if you exceed a predefined memory or time budget.

[Qantourisc → _pctq]

Yes, but your decompression middle ware might need an update/change: When you ask for a decompress, you specify the max size (if you are asking it to decompress everything).

[danesparza → _pctq]

I think this is exactly what the HTTP 'HEAD' verb is for: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/HE...

[_pctq → danesparza]

Wouldn't a HEAD give the size of the zipped content, and not the size of the content once decompressed?

[danesparza → _pctq]

This is a great question. I'm actually not sure, since gzip encoding/decoding is built-in to several webservers and browsers.

[c3833174 → _pctq]

Decompress it in chunks and stop when a preset limit is reached.