文件上传漏洞中的压缩炸弹攻击与限制

服务器在接收到一个只有1MB大小的ZIP文件时，却能在解压后膨胀至数GB甚至数TB，瞬间耗尽磁盘空间和内存，导致业务瘫痪。这种攻击手法被称为“压缩炸弹”或“解压缩炸弹”，它是文件上传功能中最容易被忽视但又极其致命的逻辑漏洞。很多人认为只要限制了上传文件的大小就万事大吉，但压缩炸弹恰恰利用的是高压缩比的特性，绕过了基于原始文件体积的防护策略。

要理解这种攻击，必须跳出“文件大小”的惯性思维。一个典型的压缩炸弹，例如经典的“42.zip”，本身只有42KB，但其中嵌套了多层ZIP文件，每一层都包含大量重复数据，最终解压后能产生4.5PB的恐怖数据量。攻击者不需要上传大文件，只需要构造一个高压缩比的恶意压缩包，就能对服务器发起拒绝服务攻击。更危险的是，如果服务器上的杀毒软件或内容检测引擎试图自动解压扫描，攻击甚至不需要等到业务层处理，在安全扫描阶段就能直接把服务器压垮。

压缩算法的核心逻辑是去除数据冗余。对于全零文件或高度重复的文本，压缩算法能把它们压缩到极小。攻击者正是利用这一点，生成包含数GB甚至数TB重复数据的文件，然后压缩成只有几十KB的压缩包。常见的构造方式有三种：单一高压缩比文件、嵌套压缩包和跨格式压缩炸弹。

单一高压缩比文件最简单，比如一个全由零组成的10GB文件，用ZIP压缩后可能只有10MB。嵌套压缩包则更隐蔽，攻击者会在压缩包内放置多个压缩包，层层嵌套，解压时每一层都会指数级膨胀。跨格式压缩炸弹则利用不同压缩算法之间的差异，例如一个tar.gz文件，gzip层解压后得到一个巨大的tar包，tar包内又包含大量文件，总解压体积远超预期。

攻击者还会利用某些压缩格式的特性来增强杀伤力。例如ZIP格式支持多种压缩算法，其中Deflate算法对重复数据的压缩率极高。BZIP2和LZMA算法在某些场景下压缩比甚至更高。攻击者会针对服务器支持的解压格式选择最优的压缩算法，让炸弹体积更小、威力更大。一个精心构造的压缩炸弹，压缩比可以达到百万比一，这意味着1MB的压缩包能解压出1TB的数据。

任何接受压缩文件上传并执行解压操作的业务都是潜在的攻击入口。最典型的是网站后台的模板上传、批量图片导入、日志分析平台的数据上传、邮件系统的附件扫描、以及各种SaaS平台的数据导入功能。这些场景中，服务器往往会在用户上传后自动解压文件，以便进行内容校验、索引建立或格式转换。

攻击者通常会先对目标进行侦察，确认上传接口是否接受压缩文件、支持哪些压缩格式、是否有文件大小限制。如果发现接口只限制了上传文件的原始大小而没有限制解压后的体积，攻击者就会尝试上传压缩炸弹。有些系统虽然限制了上传文件大小，但限制值设置得较高，比如50MB，攻击者仍然可以构造一个解压后达到数TB的炸弹。

更隐蔽的攻击路径是利用多层压缩包绕过安全扫描。攻击者会构造一个看起来正常的压缩包，外层包含一些无害的文件，但深层嵌套了高压缩比的炸弹。当杀毒软件或恶意代码扫描器逐层解压检查时，在解压到某一层时突然遭遇指数级膨胀，导致扫描进程崩溃甚至服务器宕机。这种攻击不需要业务层主动解压，安全机制本身就变成了攻击的放大器。

解压操作对服务器资源的消耗体现在三个维度：磁盘I/O、内存占用和CPU计算。当服务器解压一个压缩炸弹时，首先会大量写入磁盘，如果解压路径在系统盘，可能导致整个服务器无响应。即使解压路径在数据盘，瞬间的磁盘写满也会导致数据库写入失败、日志无法记录、会话无法持久化等一系列连锁反应。

内存消耗同样致命。很多解压库为了性能，会将解压后的数据缓存在内存中，或者维护大量的解压状态信息。面对嵌套压缩包，解压库需要同时维护多层解压上下文，内存占用呈指数级增长。一个设计不当的解压流程，可能在几秒内就触发OOM Killer，导致关键进程被系统强制终止。

CPU资源虽然相对次要，但压缩炸弹通常包含高熵数据或特殊构造的压缩流，某些解压算法在处理这类数据时会出现性能退化，CPU占用率飙升到100%，进一步加剧服务不可用。三者的叠加效应使得压缩炸弹攻击比单纯的DDoS流量攻击更难防御，因为它只需要一次成功的上传就能从内部击垮服务器。

最有效的防御策略是在解压过程中实时监控解压后的数据量，一旦超过阈值立即中止解压并删除已解压的文件。这种方案不依赖上传文件的原始大小，而是直接控制解压产物的体积上限。实现方式通常是在解压流的读取过程中插入一个计数包装器，每解压出一段数据就累加计数器，达到限制值时抛出异常终止解压。

具体到代码实现，以Java为例，可以包装InputStream进行限流：

import java.io.IOException;
import java.io.InputStream;

public class BoundedInputStream extends InputStream {
    private final InputStream delegate;
    private final long maxBytes;
    private long totalBytesRead = 0;

    public BoundedInputStream(InputStream delegate, long maxBytes) {
        this.delegate = delegate;
        this.maxBytes = maxBytes;
    }

    @Override
    public int read() throws IOException {
        int result = delegate.read();
        if (result != -1) {
            totalBytesRead++;
            if (totalBytesRead > maxBytes) {
                throw new IOException("解压体积超过限制");
            }
        }
        return result;
    }

    @Override
    public int read(byte[] b, int off, int len) throws IOException {
        int bytesRead = delegate.read(b, off, len);
        if (bytesRead > 0) {
            totalBytesRead += bytesRead;
            if (totalBytesRead > maxBytes) {
                throw new IOException("解压体积超过限制");
            }
        }
        return bytesRead;
    }
}

使用Apache Commons Compress库解压时，将自定义的BoundedInputStream传入即可：

ZipFile zipFile = new ZipFile(uploadedFile);
Enumeration entries = zipFile.getEntries();
while (entries.hasMoreElements()) {
    ZipArchiveEntry entry = entries.nextElement();
    if (!entry.isDirectory()) {
        InputStream boundedStream = new BoundedInputStream(
            zipFile.getInputStream(entry), 
            100 * 1024 * 1024  // 限制100MB
        );
        // 使用boundedStream进行文件写入
    }
}

Python中同样可以实现类似机制，通过继承IOBase或直接包装文件对象来限制读取字节数。核心思路都是在数据落盘之前进行拦截，而不是等文件完全解压后再检查大小。

仅限制解压体积还不够，嵌套压缩包攻击会通过多层结构消耗大量的内存和文件句柄。防御方案需要限制压缩包的嵌套层数，通常建议最大递归深度不超过3层。在代码中维护一个深度计数器，每进入一层压缩包就加一，达到上限后拒绝继续解压。

实现时需要注意区分真实嵌套和格式特性。有些压缩格式如tar.gz本质上是两层，但这是正常的格式结构。防御策略应该将tar.gz这种标准组合视为一层，或者将总深度限制适当放宽到5层。关键是要在解压入口处统一管理深度状态，避免不同格式的处理逻辑各自维护深度计数导致不一致。

除了深度限制，还应该限制单次解压的总文件数量。攻击者可能在一个压缩包内放置数百万个空文件或小文件，虽然总解压体积不大，但创建大量文件会耗尽inode、拖慢文件系统、导致目录遍历性能急剧下降。建议将单次解压的文件数量上限设置为10000个，这个数字足以满足绝大多数正常业务需求，同时能有效防御文件数量炸弹。

解压过程必须运行在受控的资源沙箱中。对于内存，应该在启动解压任务前设置明确的内存上限，超出后直接终止任务。Java可以通过启动参数限制堆内存，Python可以使用resource模块设置内存限制。更精细的做法是在解压线程中定期检查内存使用量，接近阈值时主动清理缓存或中止操作。

对于磁盘空间，绝不能将解压文件直接写入生产存储。应该创建一个独立的临时目录，该目录挂载在单独的磁盘分区或使用磁盘配额限制。Linux下可以使用quotatool或设置文件系统的配额属性，确保即使解压失控也不会影响系统盘的正常运行。容器化部署的环境可以利用容器的磁盘限制，为解压服务分配独立的临时卷。

临时文件的清理机制同样重要。解压完成后无论成功还是失败，都必须立即删除临时文件。建议使用try-finally或上下文管理器确保清理逻辑一定会执行。同时设置一个定时任务，定期扫描临时目录并删除超过一定时间的残留文件，防止程序异常退出导致的磁盘泄漏。

并非所有业务都需要接受所有压缩格式。安全团队应该根据实际需求制定压缩格式白名单，只开放业务必需的格式。如果业务只需要ZIP格式，就禁止上传RAR、7z、tar.gz等格式。减少支持的格式数量直接缩小了攻击面，因为不同格式的解压库可能存在不同的漏洞和性能特征。

文件类型判断不能仅依赖扩展名，必须检查文件的魔数。ZIP文件的魔数是PK\x03\x04，GZIP是\x1f\x8b，RAR是Rar!\x1a\x07。通过读取文件头部字节进行匹配，可以有效防止攻击者通过修改扩展名绕过格式限制。同时要注意，某些格式允许在魔数之前存在额外数据，判断逻辑需要处理这种情况。

对于必须支持的压缩格式，应该对解压库进行安全加固。使用最新版本的解压库并及时修补已知漏洞，避免使用社区长期不维护的库。配置解压库的安全选项，例如禁用符号链接解压、禁止绝对路径解压、限制文件名长度等。这些配置能防止路径穿越攻击，攻击者可能通过构造特殊的压缩包将文件解压到任意目录，覆盖系统配置文件或植入Webshell。

将解压操作从Web请求线程中剥离是提升系统韧性的关键。用户上传压缩文件后，Web服务器只负责接收文件并存储，然后通过消息队列将解压任务异步分发给独立的工作进程。这样即使解压过程出现资源异常，也不会直接影响Web服务器的响应能力，用户看到的是“处理中”的状态而非连接超时。

工作进程应该运行在独立的容器或虚拟机中，拥有独立的CPU、内存和磁盘资源配额。这种隔离架构确保了解压炸弹即使成功引爆，影响范围也被限制在单个工作实例内，不会波及整个业务集群。工作实例崩溃后可以由编排系统自动重启，未完成的任务重新分配。

异步架构还允许对解压任务进行更精细的调度和限流。可以设置并发解压任务的上限，避免多个压缩炸弹同时触发造成资源争抢。任务执行时间也可以设置超时，超过合理时间范围的任务直接标记为失败，防止某些构造特殊的压缩包导致解压进程陷入死循环或长时间计算。

防御体系需要配合完善的监控才能形成闭环。应该记录每次解压操作的详细信息，包括上传用户、文件名、原始大小、解压后大小、解压耗时、文件数量等。当解压后体积与原始体积的比值超过预设阈值时，触发告警并标记为可疑行为。正常文件的压缩比通常在1:1到1:20之间，超过1:100就应该引起警惕。

建立基于行为特征的检测规则。同一用户在短时间内多次上传高压缩比文件，或者上传的压缩包解压后体积异常但文件内容无实际业务价值，这些都是攻击的前兆。将这些特征输入到风控系统中，可以实现自动封禁和人工审核的联动机制。

定期对解压服务进行压力测试，使用受控的压缩炸弹样本验证防御机制的有效性。测试应该在隔离环境中进行，模拟各种攻击场景，包括单一高压缩比文件、嵌套压缩包、大量小文件等。通过持续的测试和优化，确保防御策略始终领先于攻击手法的演进。