网关层拦截恶意压缩请求的防护策略

最近不少运维和开发朋友都在忙着给底层库打补丁，起因就是那个闹得沸沸扬扬的 Brotli 解码器漏洞。攻击者只要塞过来一段精心伪造的畸形压缩数据，后台在解压时就可能直接内存越界甚至崩掉。这种时候，比起慌慌张张去翻每一个微服务的代码、改依赖再重新打包上线，最稳妥也最省事的办法，其实是先把关口前移，让最外层的网关先把恶意流量拦下来。

打个通俗的比方，这就好比小区物业发现最近有危险包裹在流转，里面藏着能把拆包工人炸伤的机关。与其挨家挨户提醒居民“拆快递时小心点”，性价比最高的做法显然是让小区保安在门口把这类危险包裹直接扣下。在网络架构里，API 网关和反向代理就是这个保安，它是挡在业务服务前面的第一道防线。

守住大门：拒收可疑的压缩上传

大家日常上网，基本都是服务器把网页压缩好发给浏览器看，普通用户很少主动把自己的请求内容压缩后再发给服务器。但在实际业务中，确实有些接口允许客户端上传压缩包体。一旦攻击者利用这点，发送带有 Content-Encoding: br 的恶意数据，而后端又老老实实去解压，服务就很容易直接被干趴下。

在网关层最利落的防护手段，就是直接一刀切：只要看到入站的请求头里声明了 Brotli 压缩（即 Content-Encoding: br），直接返回拒绝处理的状态码。像在 Nginx 这类反向代理里配上一条规则，就能在毫秒级把恶意请求挡在门外。这样做完全不影响服务器继续向正常用户的浏览器输出压缩内容，只是不收外部送进来的 Brotli 压缩包而已，既保住了后端安全，又不会牺牲用户的下载体验。

掐断隐患：重写头部与特征过滤

除了直接拒收，网关还能做更多细致的拦截。比如面对一些未经认证的公开接口，或者外部打过来的回调请求，网关可以在转发前主动对请求头进行处理，直接丢弃或剥离 Accept-Encoding: br，逼着对方换用其他相对稳妥的压缩方式或者明文来传输。

如果网关前端还挂着应用防火墙，还可以针对已经公开的攻击特征进行流量过滤。那些包含不合法字节序的畸形数据流，在到达解压模块之前就会被识别并掐断。后端那些老旧的、来不及升级的业务容器，就能靠着网关这层屏障争取到宝贵的排查和修复时间。