文件上传漏洞审计：从入口校验到存储隔离的完整验证方法

文件上传是 Web 系统中较常见、也容易被低估的一类风险。很多项目只在前端限制扩展名，或仅依赖请求头中的 Content-Type，结果导致恶意脚本被当作静态资源执行、路径穿越覆盖文件、压缩包消耗过多资源等问题。

这类问题的审计重点并不是“能不能上传一个文件”，而是要完整梳理文件从接收、解析、存储到访问的生命周期。只有把入口校验、文件内容识别、权限控制、存储位置和后处理流程放在一起分析，才能判断实际影响。

一、先明确上传功能的安全边界

审计开始前，建议先回答几个问题：

• 允许上传哪些业务类型，例如头像、附件、报表或压缩包？
• 文件是否会被直接通过 URL 访问？访问时由 Nginx、对象存储还是应用程序处理？
• 上传后的文件是否会进入图片解析、Office 预览、OCR、解压或杀毒流程？
• 上传目录是否与应用代码目录、配置目录处于同一文件系统？
• 普通用户能否修改文件名、目录、Content-Type 或其他元数据？

如果这些问题没有明确答案，通常说明系统的文件处理边界还不清晰。安全设计的第一原则是：用户上传的内容应被视为不可信数据，而不是“图片”“文档”这类可信对象。

二、常见风险点及审计思路

1. 仅校验扩展名或请求头

扩展名和 Content-Type 都属于可控输入。客户端可以修改文件名，请求头也不能证明文件的真实格式。因此，以下代码逻辑是不充分的：

if (filename.endsWith('.jpg') && contentType.equals('image/jpeg')) {
    save(file);
}

更可靠的做法是将校验拆成多层：

• 使用服务端解析得到的 MIME 类型，而不是直接信任请求头。
• 根据业务类型检查文件签名和结构，例如 JPEG、PNG、PDF 等。
• 使用对应解析器尝试读取文件，确认它至少符合预期格式。
• 对图片进行重新解码和编码，尽量丢弃原始元数据与不必要的数据块。
• 最终保存时使用服务端生成的随机名称，不保留用户提供的路径和扩展名。

需要注意，文件签名也不是绝对安全边界。有些格式允许附加任意数据，单纯检查开头几个字节无法替代完整解析。

2. 文件名与路径处理不当

用户提交的文件名可能包含目录分隔符、路径回退片段、特殊 Unicode 字符或控制字符。即使操作系统最终能够规范化路径，应用层的拼接逻辑也可能在校验前后产生差异。

安全实现通常不应使用原始文件名作为磁盘路径。可以保留一个经过清洗的展示名称，但实际存储名称应由服务端生成。例如：

String displayName = sanitizeForDisplay(originalName);
String objectKey = UUID.randomUUID().toString().replace('-', '') + '.bin';
Path target = uploadRoot.resolve(objectKey).normalize();

if (!target.getParent().equals(uploadRoot.toAbsolutePath().normalize())) {
    throw new SecurityException('invalid storage path');
}

这里的路径比较只是防御性校验，不能替代随机文件名和固定存储根目录。对于对象存储，应将用户可控名称作为元数据保存，而不是直接拼入对象键的敏感路径。

3. 上传目录可执行或可直接访问

即使文件内容校验存在缺陷，只要上传目录不具备脚本执行能力，风险通常会明显降低。生产环境建议将用户文件放在应用代码目录之外，并通过独立的文件服务或对象存储提供下载。

如果必须由 Web 服务器提供静态访问，应明确关闭脚本解析能力，并限制响应头。例如：

location /user-files/ {
    alias /srv/app-data/user-files/;
    default_type application/octet-stream;
    add_header X-Content-Type-Options nosniff always;
    add_header Content-Disposition 'attachment' always;
}

配置的具体写法要结合实际服务器版本和部署方式验证。尤其要确认别名目录、默认 MIME 类型、缓存策略和错误页面不会把用户文件重新交给应用解释。

4. 压缩包与解析器风险

压缩包上传常见于导入、批量附件和插件包场景，风险不只在于文件类型。审计时还要关注：

• 解压路径是否经过规范化，是否可能写出目标目录。
• 压缩包内文件数量、单文件大小和解压总大小是否有限制。
• 是否允许嵌套压缩包，是否存在递归解压。
• 符号链接和硬链接是否会指向工作目录之外。
• 解压过程是否在低权限、临时隔离目录中执行。

安全解压应在写入前检查每个条目的目标路径，并同时限制数量、压缩后总大小和处理时间。下面是一个简化的伪代码示例：

for (Entry entry : archive) {
    if (entry.isSymbolicLink() || entry.isHardLink()) {
        reject('link entry is not allowed');
    }

    Path output = sandbox.resolve(entry.name()).normalize();
    if (!output.startsWith(sandbox)) {
        reject('entry escapes sandbox');
    }

    totalSize += entry.uncompressedSize();
    if (totalSize > MAX_TOTAL_SIZE || count++ > MAX_ENTRIES) {
        reject('archive limit exceeded');
    }
}

三、推荐的审计流程

1. 从路由和数据流入手

先定位所有接收文件的入口，包括 Multipart 上传、Base64 上传、远程 URL 导入、富文本附件和后台导入接口。不要只搜索 upload 关键词，还应关注文件流、临时目录、对象存储 SDK 和异步任务。

建议记录以下数据流：

• 原始文件名来自哪里，是否经过编码转换。
• 文件内容经过哪些校验和解析器。
• 临时文件创建在哪里，权限和生命周期如何。
• 最终文件名、路径和访问地址由谁生成。
• 下载接口是否会根据用户输入拼接文件路径。

2. 检查服务端实际识别结果

测试时应使用无害的本地样本，包括正常图片、损坏图片、扩展名与内容不一致的文件、超限文件和结构异常的压缩包。重点观察服务端返回、日志和落盘结果，而不是直接尝试投递可执行内容。

file --mime-type sample.bin
sha256sum sample.bin
xxd -l 32 sample.bin

对于图片，可以使用 ImageMagick 或项目实际使用的库重新读取并导出，再比较导出结果是否仍包含原始的非必要数据。对于 PDF、Office 文档等复杂格式，应确认解析过程是否在隔离环境中完成，并设置资源限制。

3. 验证访问控制与响应行为

上传成功不代表文件应该公开访问。应分别验证未登录用户、普通用户和文件所有者访问不同文件时的权限结果。下载接口还要关注：

• 是否使用不可预测的文件标识，而不是连续 ID。
• 是否在服务端重新校验文件归属关系。
• 是否允许用户控制 Content-Type、Content-Disposition 或缓存头。
• 文件不存在时是否泄露真实磁盘路径。

如果业务要求公开下载，也建议使用短时效、最小权限的签名地址，并将原始存储桶设置为私有。

四、代码审计中的重点反模式

• 直接使用用户传入的 filename 作为保存路径。
• 只通过 endsWith、正则或 MIME 请求头判断文件类型。
• 把上传目录放在 Web 应用根目录，并允许服务器自动解析脚本。
• 使用固定临时文件名，导致并发覆盖或符号链接风险。
• 解压前不限制条目数量、解压总大小和嵌套层级。
• 下载接口根据用户输入拼接路径，却没有做规范化和归属校验。
• 将文件内容交给图像、文档或音视频解析器处理，却没有超时和资源限制。

五、修复方案的落地建议

一个相对稳妥的上传链路可以按以下顺序实现：

• 在网关或应用层限制请求体大小和单文件大小。
• 在临时隔离目录接收文件，并使用随机临时名称。
• 校验业务类型、服务端识别的 MIME、文件签名和结构。
• 对图片等格式执行安全重编码；对压缩包执行安全解压。
• 使用随机对象键保存到应用代码目录之外的私有存储。
• 保存文件哈希、大小、类型、创建者和安全扫描结果，便于追溯。
• 下载时执行对象级授权检查，并设置安全响应头。
• 记录失败原因、调用方、文件哈希和处理耗时，但避免把文件内容写入日志。

文件上传的安全性通常取决于最弱的一环。扩展名校验、内容识别、存储隔离和访问控制不能相互替代，应作为一条完整链路设计。

六、总结

审计文件上传功能时，建议把关注点从“能否上传恶意文件”转向“用户可控数据是否能够影响解析、路径、执行和访问权限”。入口校验解决的是输入质量问题，存储隔离解决的是执行边界问题，授权和响应头解决的是数据暴露问题，而日志与哈希则决定了后续能否追踪和复盘。

在验证过程中应优先使用无害样本和本地测试环境，结合代码审计、配置检查、日志观察和单元测试完成闭环。对于高风险解析器、压缩包处理和第三方文件预览服务，还应增加资源限制与隔离运行。这样既能减少误报，也能让修复方案真正落到生产环境的文件生命周期上。