Go gzip 解压时如何限制解压炸弹的输出大小

Go 里处理 gzip 数据时，限制上传文件大小还不够：攻击者可以提交一个压缩体积很小、解压后远超预期的文件。安全做法是把“压缩输入上限”和“解压输出上限”分开设置，先限制请求体能读入多少字节，再限制 gzip.Reader 能交给业务多少明文。超过解压阈值就立即拒绝，不能把截断结果继续交给 JSON、归档或文本解析器。

最小可靠方案是对解压后的 Reader 使用 io.LimitReader(zr, maxOutput+1)，多读一个字节来判断是否超限；只有完整读到 io.EOF 且未超过上限，才把结果交给下游。

先把压缩输入和解压输出分成两道上限

gzip.NewReader 返回的是解压后的 io.Reader。因此，包在 HTTP 请求体里的大小与解压后产生的明文大小是两个不同指标：前者可能只有几百 KB，后者却可能达到几百 MB。只在网关限制请求体，无法覆盖已经进入应用的解压放大；只在内存缓冲上限制，又可能让应用先读入过大的压缩请求。

工程上可以给请求体设一个较小的压缩上限，再给业务允许的明文设一个独立上限。压缩体上限应该放在进入 gzip.NewReader 之前；输出上限则必须放在 gzip.Reader 之后。

用多读一个字节识别超出限制

io.LimitReader 到达限制后会返回 EOF。若只读 maxOutput 个字节，业务无法判断数据是“刚好达到上限”还是“后面还有内容”。把窗口设为 maxOutput+1 后，读取结果长度大于 maxOutput 就是明确的超限信号。

package gziplimit

import (
    "compress/gzip"
    "errors"
    "fmt"
    "io"
)

var ErrOutputLimit = errors.New("gzip 解压输出超过限制")

func ReadGZIPLimited(src io.Reader, maxOutput int64) ([]byte, error) {
    // 预留一个字节用于识别“超过上限”；避免极端配置发生整数溢出。
    if maxOutput = 1 maxOutput {
        return nil, ErrOutputLimit
    }
    // 未超限时已经读到 EOF，gzip Reader 才有机会校验尾部 checksum。
    return data, nil
}

这个函数拒绝的是解压后的输出，不是压缩包本身。若要限制 HTTP 请求体，还应在调用它之前给原始请求体加输入层限制；如果数据最后要写入文件或消息队列，也要继续限制下游写入，不能因为内存读取安全就默认整个链路安全。

单个 gzip 成员和多成员要分清

Go 的 gzip Reader 默认把连续的 gzip member 当作一个逻辑输入。对上传的单文件格式，如果业务只接受一个 member，可以在创建 Reader 后调用 zr.Multistream(false)，并把“是否还有额外数据”作为格式检查的一部分。若业务明确允许拼接成员，则输出上限必须覆盖所有成员的累计解压结果，而不是每个成员分别重置。

还有一个容易被忽略的细节：gzip.Reader.Close 本身不负责验证校验和，完整读到 io.EOF 才能让正常路径完成校验。因此，超限分支可以提前停止并拒绝；未超限分支不能只读一小段就认为成功。读取中出现格式错误、校验和错误或底层 I/O 错误，都应当直接返回失败。

上线前检查哪些资源边界

上线前至少逐项确认：入口是否限制了压缩输入；解压是否使用了独立的输出上限；是否拒绝了超限结果；是否避免用无界的 io.ReadAll(zr)；解析器是否还有字段、嵌套和单值限制；超限日志是否只记录大小、请求标识等必要信息，而不保存用户提交的完整压缩内容。

如果明文很大，优先把受限 Reader 流式写入受限目标，而不是先构造完整 []byte。无论采用缓冲还是流式方案，判断超限的原则不变：达到业务上限可以继续收尾，读出第一个额外字节就停止并拒绝。

常见问题

只限制 gzip 文件大小，能防住解压炸弹吗？

不能。文件大小限制只约束压缩输入，必须再约束解压后的输出字节数。

为什么不是直接使用 io.LimitReader(zr, maxOutput)？

这样只能得到最多 maxOutput 个字节，无法知道后面是否还有第 maxOutput+1 个字节；多读一个字节才能明确判定超限。

超限后还需要把 gzip 读完再关闭吗？

通常不需要。超限已经是拒绝结果，可以停止读取并释放 Reader；只有接受的数据才需要读到 EOF 完成校验。

关闭 gzip.Reader 会自动关闭 HTTP 请求体吗？

不会。官方文档说明 Close 不关闭底层 Reader，HTTP 请求体或文件句柄仍应由拥有它的调用方负责关闭。

参考：Go compress/gzip 文档、Go io 文档。