有关如何在网页中嵌入更好的 gzip 炸弹

[LeeReamond]

如果网站遇到高频请求攻击，在回文里添加 gzip 炸弹似乎是一个不错的方法。通常来说的做法是使用

dd if=/dev/zero bs=1M count=1024 | zip zipbomb.zip -

这个命令，从 /dev/zero 生成压缩包，然后将被攻击的链接指向这个文件就可以了。

但是一般来说这么搞的话 headers 里面的 content-type 会变成 application/octet-stream ，或者攻击方的爬虫单纯根据回文大小也可以比较轻松地过滤掉这些炸弹。有没有什么办法可以嵌入压缩率更高的炸弹呢？比如在 contetn-type=application/json 的类型的回文里插入一些高压缩内容，如果要读取回文的话就需要较大的内存占用，从而限制攻击方的物理资源。

我简单看了一下，似乎 gzip 格式的高压缩都是通过嵌套实现的，而 http 的 gzip 压缩似乎是整个回文都会被压缩，很难单独在 json 里面插入一个嵌套压缩的 gzip 这种东西。万能的 v 友有什么方法吗？

[3dwelcome]

这种只要客户端设置一下 Accept-Encoding ，声明一下不支持压缩格式，不就轻松绕过去了。

[shyling]

想过滤都能过滤的吧。。有什么区别呢

[ryd994]

也许你可以试试 http://nginx.org/en/docs/http/ngx_http_gzip_static_module.html
With the “always” value, gzipped file is used in all cases, without checking if the client supports it.

[ysc3839]

你这方法就错了，gzip 不是 zip ，要用 gzip 来压缩。而且 content-type 肯定要改掉呀，肯定不能直接返回 octet-stream ，要保证 response header 和你原接口一致。另外压缩炸弹确实很容易检测绕过的，这个没有什么好办法。

[sampeng]

突然想到一个问题。。。
难道流量不要钱么。。。

[jim9606]

感觉没多大用，单纯 request flooding 的话客户端都是直接丢弃响应的，回个响应都是浪费。如果是对付爬虫什么的，被投毒的话攻击方也能很快调整吧。不过后者通常上个强认证就能拦住了，或者你可以考虑在正常响应里填充垃圾数据（这个感觉操作起来也很麻烦，搞不好先把自己放倒了）。

@sampeng 之所以叫炸弹是因为 payload 压缩之后会变得很小，所以如果客户端要处理响应需要在内存解压把内存撑爆。

[sampeng]

@jim9606 压缩后再小，也是要流量的。这种炸弹假定对方要处理相应头 Content-Type 。
普通用户进来也会拿到这个 payload 。浏览器 /客户端必处理。就像你上面说的，这等于七伤拳，图啥呢？

[sampeng]

高频请求攻击，除非是 ddos 。ddos 是另外的处理方式。。通过接口限速即可。单 ip 只能请求多少次。前面网关就可以拦截下来，非常简单

[jim9606]

@sampeng 我觉得楼主讨论的是定向投毒，识别恶意请求后重定向为有毒 payload 。这类对抗求的是不对等的代价，即防守的代价远小于发动攻击的代价。但如果攻击方就是有远高于防守方的资源，那还是没辙。

[LeeReamond]

@jim9606 不考虑极端情况，毕竟阎王好过小鬼难缠，阎王怎么会在意我们这种体量的网站，能防御小鬼就行了