从一次代码审计看文件上传漏洞的识别与加固

背景

文件上传功能在业务系统里很常见，比如头像、附件、工单截图、文档导入等。它看起来只是一个普通表单，但从攻防视角看，上传链路往往同时涉及前端校验、后端解析、文件存储、访问控制、Web 容器解析规则、对象存储权限等多个环节，任何一个点处理不当，都可能演变成高危问题。

这篇文章结合日常代码审计和漏洞复现经验，整理一套比较通用的文件上传安全分析方法。内容侧重识别风险与加固思路，不提供违法攻击、恶意控制或绕过授权类操作。

典型场景

常见业务代码里，文件上传接口大致会做三件事：

• 接收 multipart/form-data 请求中的文件对象。
• 校验文件名、后缀、大小、MIME 类型。
• 保存到本地目录、NFS、对象存储或 CDN 回源目录。

问题经常出现在“只做了表面校验”或“保存路径位于 Web 可执行目录”这类细节上。例如只根据原始文件名后缀判断类型，或者上传后文件可被 Web 容器当作脚本解析。

审计时优先看的几个点

1. 文件类型校验是否可信

不少代码只检查用户提交的文件名后缀，甚至只检查 Content-Type。两者都不能作为唯一依据，因为它们都来自客户端，可信度较低。更稳妥的方式是后端同时做扩展名白名单、文件头特征校验，以及业务层面的内容解析。

一个容易出问题的示例逻辑如下：

String filename = file.getOriginalFilename();
if (filename.endsWith(".jpg") || filename.endsWith(".png")) {
    file.transferTo(new File(uploadDir, filename));
}

这类代码有几个问题：

• 直接信任原始文件名。
• 只做后缀判断，没有做大小写归一化。
• 没有处理双后缀、特殊字符、路径分隔符。
• 没有校验真实文件内容。

推荐采用白名单方式，并基于服务端生成的新文件名保存：

Set<String> allowExt = Set.of("jpg", "jpeg", "png", "gif", "pdf");
String ext = getNormalizedExt(originalFilename);
if (!allowExt.contains(ext)) {
    throw new IllegalArgumentException("unsupported file type");
}

String safeName = UUID.randomUUID().toString().replace("-", "") + "." + ext;
Path target = uploadBase.resolve(safeName).normalize();
if (!target.startsWith(uploadBase)) {
    throw new SecurityException("invalid path");
}
Files.copy(file.getInputStream(), target, StandardCopyOption.REPLACE_EXISTING);

2. 保存目录是否会被脚本引擎解析

这是文件上传风险里非常关键的一点。即使限制了文件类型，也建议把上传目录放在 Web 根目录之外，或者明确关闭该目录的脚本执行能力。对于图片、附件这类静态文件，应该按静态资源处理，不应该具备动态脚本执行条件。

Nginx 场景下，可以对上传目录做静态化处理，并避免转发到后端脚本解析器：

location /uploads/ {
    alias /data/app/uploads/;
    autoindex off;
    default_type application/octet-stream;

    location ~* \.(php|jsp|jspx|asp|aspx)$ {
        return 403;
    }
}

如果是 Java Web 应用，建议不要把上传文件写入 webapps 应用目录下，而是写入独立数据目录，再通过受控下载接口或静态服务读取。

3. 文件名和路径处理是否存在穿越风险

上传接口经常会把用户提交的文件名拼接到保存路径里。如果未做规范化处理，可能出现路径穿越、覆盖已有文件、写入异常目录等问题。

审计时可以重点搜索如下模式：

new File(uploadDir + "/" + filename)
Paths.get(uploadDir, filename)
file.transferTo(new File(path))

需要关注 filename 是否完全来自用户输入，是否过滤了 ../、..\、绝对路径、URL 编码后的路径分隔符，以及是否在保存前执行 normalize 并校验最终路径仍位于预期目录内。

4. 文件访问是否需要权限控制

并不是所有上传文件都适合公开访问。比如合同、工单附件、用户导出的报表，如果上传后返回一个可直接访问的 URL，且 URL 可枚举，就可能形成敏感信息泄露。

比较稳妥的设计是：

• 公开资源和私有资源分桶或分目录存储。
• 私有文件通过下载接口鉴权后返回。
• 文件 ID 使用不可预测随机值，不使用连续自增 ID 暴露给前端。
• 对象存储默认私有，按需生成短期有效访问链接。

5. 业务解析链路是否安全

上传文件不一定只用于存储，还可能被后端解析。例如 Excel 导入、PDF 预览、图片压缩、文档转换。这类场景要关注解析库历史漏洞、外部命令调用、压缩包解压路径、资源消耗等风险。

压缩包处理尤其容易出问题。解压前要检查条目路径，防止写出目标目录：

Path dest = baseDir.resolve(entry.getName()).normalize();
if (!dest.startsWith(baseDir)) {
    throw new SecurityException("zip entry path traversal detected");
}

同时还要限制压缩包大小、解压后总大小、文件数量和递归层级，避免压缩炸弹造成服务不可用。

复现与验证思路

在授权测试环境中，可以按以下顺序验证上传功能是否安全：

• 确认接口是否只依赖前端校验，直接调用后端接口看是否仍有限制。
• 尝试不同大小写后缀，观察服务端是否统一归一化处理。
• 检查上传后的文件存储位置，判断是否位于 Web 可执行目录。
• 查看响应中返回的访问 URL，确认是否存在越权访问或可枚举问题。
• 上传异常文件名，验证路径规范化和重命名策略。
• 对需要解析的文件类型，观察是否存在解析报错、资源占用异常或外部命令调用痕迹。

这里的重点不是追求“绕过技巧”，而是验证安全边界是否真正落在服务端，并且覆盖存储、访问、解析三个阶段。

加固建议清单

日志与监控

文件上传接口建议记录必要的安全日志，便于事后排查。日志不需要记录文件内容，但应包含用户 ID、来源 IP、文件大小、文件类型、保存 ID、处理结果、失败原因等字段。

upload_user_id=12345
client_ip=10.0.1.8
file_ext=png
file_size=384221
storage_key=2025/01/ab12cd34.png
result=success

如果短时间内出现大量失败上传、异常后缀、超大文件、重复探测同一接口等行为，可以接入限流或告警策略。

常见误区

• 认为前端限制了 accept 属性就安全。前端限制只能改善体验，不能作为安全边界。
• 只检查 Content-Type。该字段由客户端提交，不能单独信任。
• 上传后改名就足够。改名能降低覆盖和路径风险，但不能解决解析和访问控制问题。
• 对象存储一定安全。对象存储权限配置错误同样会造成公开泄露。
• 图片一定无害。图片处理库、元数据解析、格式转换都可能带来额外攻击面。

总结

文件上传安全不能只看一个 if 判断，应该把它当成完整链路来审计：入口校验、文件命名、路径处理、存储位置、访问控制、后续解析、日志监控都要覆盖。

实际项目里，我更建议采用“白名单 + 服务端随机命名 + 非 Web 可执行目录 + 私有文件鉴权 + 解析隔离”的组合方案。这样即使某个单点出现疏漏，也不容易直接扩大成高危漏洞。

做代码审计时，上传功能值得单独拉清单检查。它看似基础，但往往连接了文件系统、Web 容器和业务权限，是很多安全问题的交汇点。