从一次代码审计看文件上传链路的防护盲点

背景

文件上传是 Web 系统里很常见的功能，但也是长期高发的问题点。很多系统在设计时只关注“能不能上传成功”，对上传后的存储、访问、解析、权限边界考虑不足。实际审计里，单点校验做得再多，只要链路上某个环节处理不当，仍然可能引出越权访问、敏感文件泄露、存储型 XSS，甚至在特定部署环境下触发脚本解析风险。

这篇文章不讨论如何利用漏洞拿权限，而是从代码审计和防护设计角度，整理一条文件上传链路中常见的风险点，以及可以落地的检查和加固方法。内容偏工程实践，适合用于自查上传模块、做安全评审或补齐测试用例。

典型场景

常见业务场景包括头像上传、附件上传、工单截图、富文本图片、合同文件、导入模板等。它们看起来差别很大，但上传链路一般都包含以下步骤：

• 客户端选择文件并提交请求。
• 服务端接收 multipart/form-data 请求。
• 校验文件大小、扩展名、MIME 类型等信息。
• 生成文件名并写入本地磁盘、对象存储或内网文件服务。
• 返回文件 URL、文件 ID 或预览地址。
• 后续通过下载、预览、转码、缩略图等接口访问。

审计时不要只看上传接口本身，下载、预览、转码和静态资源解析方式同样重要。很多问题并不是上传时发生的，而是在“上传后被如何使用”这个阶段暴露出来。

技术分析：上传链路中的常见盲点

1. 只校验扩展名，忽略文件真实类型

只检查文件名后缀是最常见也最脆弱的做法。攻击面不一定来自服务端脚本执行，也可能来自浏览器解析行为、办公文档宏、SVG 脚本、HTML 附件被内联打开等。

较稳妥的方式是组合校验：

• 扩展名白名单：只允许业务确实需要的类型。
• MIME 类型检查：不能作为唯一依据，但可以作为辅助信号。
• 文件魔数检查：读取文件头判断实际格式。
• 内容解析校验：对图片可尝试解码，对 PDF、Office 文档可做更细粒度策略。

示例：Java 中基于文件头做基础识别时，不要只读取用户提交的 Content-Type。

public static String readMagic(byte[] data) {
    StringBuilder sb = new StringBuilder();
    int len = Math.min(data.length, 8);
    for (int i = 0; i < len; i++) {
        sb.append(String.format("%02X", data[i]));
    }
    return sb.toString();
}

// PNG: 89504E470D0A1A0A
// JPG: FFD8FF
// PDF: 25504446
// ZIP/Office OOXML: 504B0304

需要注意，魔数也不是万能的。比如 OOXML 文档本质是 ZIP 结构，SVG 是 XML 文本，某些格式可以被构造出兼容特征。因此建议把“允许什么”定义得足够窄，而不是试图识别所有危险类型。

2. 文件名处理不当，导致覆盖、路径穿越或信息泄露

文件名不能直接使用用户上传的原始名称。常见问题包括：

• 使用原始文件名写盘，导致同名覆盖。
• 未处理 ../、..\、绝对路径等特殊路径。
• 文件名中包含控制字符、Unicode 混淆字符，影响日志和审计。
• 返回路径中包含真实目录结构，泄露部署信息。

推荐做法是服务端重新生成文件名，只保留必要扩展名，并把原始文件名作为普通文本字段入库展示。生成规则可以使用随机 UUID、雪花 ID 或内容哈希加随机盐，不建议用用户 ID 加时间戳这种可枚举方式。

String ext = getAllowedExt(originalName);  // 从白名单中取，不直接拼接用户输入
String safeName = UUID.randomUUID().toString().replace("-", "") + "." + ext;
Path target = uploadRoot.resolve(safeName).normalize();

if (!target.startsWith(uploadRoot)) {
    throw new SecurityException("invalid upload path");
}

3. 上传目录暴露在 Web 根目录下

这是老问题，但仍然常见。把上传目录直接放在 Web 根目录下，等于把文件访问控制交给了 Web 容器和浏览器。即使当前只允许图片，后续业务放开 PDF、HTML、SVG、压缩包后，也容易引入新的风险。

更推荐的架构是：

• 上传文件存储在非 Web 根目录，或使用对象存储私有桶。
• 下载和预览统一经过受控接口。
• 接口内进行鉴权、范围校验、文件类型响应头设置。
• 对公开资源使用短期签名 URL，而不是永久可猜测地址。

Nginx 场景下，如果必须提供静态访问，至少要关闭脚本解析能力，并固定响应类型策略。例如上传目录只作为静态资源，不允许被 PHP、JSP 等运行时处理。

location /uploads/ {
    alias /data/app/uploads/;
    autoindex off;
    default_type application/octet-stream;
    add_header X-Content-Type-Options nosniff;
}

# 避免上传目录内的脚本被解释执行，具体规则需结合实际运行环境调整
location ~* ^/uploads/.*\.(php|jsp|jspx|asp|aspx)$ {
    return 403;
}

4. 预览接口缺少响应头控制

很多存储型 XSS 并不是上传接口本身的问题，而是预览接口把用户上传内容以内联方式返回给浏览器。比如 HTML、SVG、XML、某些文本类型，如果 Content-Type 和 Content-Disposition 设置不当，浏览器可能直接解析。

对非可信上传文件，建议默认下载而不是内联展示：

Content-Type: application/octet-stream
Content-Disposition: attachment; filename="download.bin"
X-Content-Type-Options: nosniff

如果业务需要图片预览，应确保只对确认过的图片类型返回 image/jpeg、image/png 等类型，并避免把 SVG 当作普通图片直接内联展示。SVG 虽然是图片格式，但由于其 XML 与脚本能力，实际风险边界更接近可执行文档，通常不建议开放上传。

5. 图片处理库和转码服务成为新攻击面

很多系统会在上传后生成缩略图、压缩图片、提取元数据。这类处理链路依赖 ImageMagick、GraphicsMagick、libjpeg、ExifTool、LibreOffice 等组件。历史上这些组件多次出现过解析漏洞，尤其是在处理畸形文件时。

建议从以下方面控制风险：

• 图片处理服务独立部署，使用低权限运行。
• 限制输入文件大小、分辨率、页数、压缩比。
• 转码任务放入队列，设置超时和资源限制。
• 及时更新第三方解析组件。
• 转码后的文件重新生成，不直接复用原文件作为预览源。

Linux 下可用 systemd 或容器限制转码进程资源，避免单个异常文件拖垮服务。

# 示例：使用 timeout 限制命令执行时间
/usr/bin/timeout 10s convert input.jpg -resize 300x300 output.jpg

# 对上传文件先做基础检查
file input.jpg
identify -verbose input.jpg

注意，上述命令只适合防守侧排查和处理流程示例，不应把用户输入直接拼接到命令行中。涉及外部命令调用时，优先使用参数数组形式，并禁用 shell 拼接。

关键步骤：一次上传模块审计可以怎么做

下面是我在审计上传功能时常用的检查顺序，比较适合落到代码审计清单里。

步骤一：梳理入口和业务类型

• 找出所有上传接口，不只看 /upload，也包括富文本、导入、头像、附件、API 网关转发接口。
• 确认每个接口允许的文件类型、大小和使用场景。
• 检查是否存在调试接口、旧版接口或未接入统一鉴权的上传入口。

步骤二：检查服务端校验逻辑

• 是否使用白名单，而不是黑名单。
• 扩展名是否经过规范化处理，比如统一小写、去除尾部空格和点号。
• 是否检查真实文件类型和基础内容结构。
• 是否限制文件大小、图片尺寸、压缩包层级和解压后总大小。
• 是否对失败原因做了合理返回，避免泄露路径和堆栈。

步骤三：检查存储位置和文件名生成

• 上传目录是否在 Web 根目录内。
• 文件名是否由服务端重新生成。
• 路径拼接是否使用安全 API，并在 normalize 后验证根目录边界。
• 对象存储桶权限是否为私有，是否存在公开读写。
• URL 是否可枚举，是否需要签名和有效期。

步骤四：检查访问接口

• 下载、预览、缩略图接口是否鉴权。
• 用户是否只能访问自己有权限的文件。
• 响应头是否正确设置 Content-Type、Content-Disposition、X-Content-Type-Options。
• 是否支持任意路径读取或通过 fileId 枚举下载。
• 日志中是否记录上传者、文件 ID、原始文件名、大小、类型、访问来源等审计信息。

步骤五：检查后处理链路

• 是否调用图片压缩、文档转 PDF、解压缩、杀毒扫描等异步任务。
• 第三方组件版本是否存在已知漏洞。
• 处理进程是否低权限、隔离运行。
• 是否设置超时、内存限制和任务失败重试上限。

常见风险与防护建议对照

一个较稳妥的后端处理流程

实际项目里，可以把上传处理拆成几个明确阶段，避免校验逻辑散落在各处。

1. 鉴权：确认用户是否具备上传权限
2. 限流：限制单用户上传频率和并发
3. 基础校验：大小、扩展名、MIME、文件头
4. 内容校验：图片解码、文档结构检查、压缩包安全检查
5. 文件落盘：服务端生成文件名，存储到非 Web 根目录
6. 元数据入库：记录文件 ID、业务归属、Hash、大小、类型、状态
7. 异步处理：缩略图、转码、扫描，运行在隔离环境
8. 访问控制：下载和预览接口统一鉴权并设置安全响应头

其中比较容易被忽略的是“状态”字段。上传完成不代表文件立刻可用，尤其是需要扫描或转码的场景。建议文件有 pending、available、blocked、deleted 等状态，访问接口只允许读取 available 状态的文件。

注意点

• 不要相信前端校验。前端限制只能提升用户体验，不能作为安全边界。
• 不要只做黑名单。危险扩展名和解析方式很多，黑名单很容易漏。
• 不要把对象存储桶直接设为公开写。公开读也要评估数据敏感性。
• 不要把原始文件名用于路径。展示时也要做 HTML 转义。
• 不要忽略多租户场景。文件 ID 必须绑定租户和业务对象权限。
• 不要让转码进程拥有过高权限。解析不可信文件本身就是高风险操作。

总结

文件上传安全不是一个简单的“后缀名过滤”问题，而是一条完整链路的设计问题。上传入口、存储位置、访问方式、响应头、后处理组件、权限模型都要一起看。

从防守角度看，比较有效的原则有三条：第一，允许类型尽量少，使用白名单；第二，不可信文件不要直接暴露给 Web 容器和浏览器解析；第三，所有下载和预览都经过统一鉴权与响应头控制。只要这几条落到工程实现里，大多数上传类问题都能提前压住。

做代码审计时，建议把上传模块当成“文件进入系统的边界”来看，而不是一个普通表单接口。边界越清晰，后续维护成本越低。