从一次代码审计看文件上传链路的常见风险与加固思路

背景

文件上传是 Web 系统里很常见的功能，头像、附件、报表导入、工单图片、富文本资源都离不开它。也正因为入口多、链路长，上传功能经常成为漏洞审计里的高频风险点。

这篇文章整理的是我在日常代码审计和漏洞复现中比较常见的一类问题：上传接口本身看起来做了扩展名校验，但在存储、访问、解析、权限控制等环节存在缺口，最终形成安全风险。文章重点放在防御视角和审计方法，不提供非法利用或攻击控制类操作。

典型场景

一个常见的业务上传链路大致如下：

• 前端限制文件类型，例如只允许 jpg、png、pdf、docx。
• 后端接收 multipart/form-data 请求。
• 后端检查文件扩展名或 Content-Type。
• 文件保存到本地目录、对象存储或共享存储。
• 数据库记录文件名、路径、上传人、业务 ID。
• 用户通过下载接口或静态资源路径访问文件。

问题往往不只出现在“能不能上传某个后缀”，而是出现在多个环节叠加之后。例如：文件名未规范化、上传目录可被脚本引擎解析、下载接口没有鉴权、对象存储桶策略过宽、临时文件处理不当等。

风险点拆解

1. 仅依赖扩展名或 Content-Type 校验

很多项目的上传校验类似下面这种逻辑：

String filename = file.getOriginalFilename();
String suffix = filename.substring(filename.lastIndexOf(".") + 1);
if (!Arrays.asList("jpg", "png", "pdf").contains(suffix)) {
    throw new RuntimeException("unsupported file type");
}

这类代码的问题不在于“扩展名校验完全没用”，而是它只适合作为第一层过滤。真实场景里还需要考虑：

• 扩展名大小写：JPG、Png。
• 文件名包含多个点：a.jpg.xxx。
• 前后空格、不可见字符、Unicode 归一化问题。
• Content-Type 可由客户端声明，不能作为可信依据。
• 文件内容与扩展名不一致，例如把非图片内容命名为 .jpg。

更稳妥的做法是组合校验：扩展名白名单、MIME 探测、文件头检查、业务场景限制以及后续存储隔离。

2. 上传目录可被 Web 容器直接解析

这是传统 Web 环境里非常典型的问题。比如上传目录位于 Web 根目录下，并且服务器会对某些后缀交给脚本引擎处理。即使当前白名单看似只允许图片，也可能因为校验缺陷、历史兼容配置或中间件解析规则导致风险扩大。

防御上比较推荐的原则是：上传文件不进入可执行目录，不让上传目录具备脚本解析能力。访问文件时通过受控下载接口或静态服务读取，而不是直接把用户文件放到应用可执行路径下。

# Nginx 示例：上传目录只作为静态文件读取，禁用脚本解析思路
location /uploads/ {
    alias /data/app/uploads/;
    autoindex off;
    add_header X-Content-Type-Options nosniff;
}

# 不要在 uploads 下配置 fastcgi、proxy 到脚本解释器等规则

3. 原始文件名直接落盘

直接使用用户上传的原始文件名保存文件，会带来不少问题：

• 路径穿越风险：文件名中包含 ../ 或特殊分隔符。
• 覆盖已有文件：同名文件冲突。
• 日志与页面展示污染：文件名中包含特殊字符。
• 跨平台兼容问题：Windows 与 Linux 对文件名保留字符处理不同。

比较稳妥的处理方式是：原始文件名只作为展示字段保存，落盘文件名由服务端生成，例如 UUID、雪花 ID 或哈希值，并按日期、业务类型分目录存储。

String originalName = cleanDisplayName(file.getOriginalFilename());
String ext = getSafeExtension(originalName);
String storedName = UUID.randomUUID().toString().replace("-", "") + "." + ext;
Path target = baseDir.resolve(LocalDate.now().toString()).resolve(storedName).normalize();

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

4. 下载接口缺少鉴权和范围校验

上传安全不只是“传上去”的问题，还包括“谁能下载”。审计中经常能看到这样的下载接口：

GET /file/download?id=12345

如果接口只根据 id 查询路径并返回文件，而没有校验当前用户是否有权限访问对应业务数据，就可能出现越权下载。尤其是合同、工单附件、身份证明、内部报表这类文件，一旦对象 ID 可枚举，影响会比较直接。

审计下载接口时，可以关注几个点：

• 文件记录是否绑定业务对象，例如 orderId、ticketId、projectId。
• 是否校验当前用户对业务对象的访问权限。
• 是否存在连续递增 ID 可枚举问题。
• 是否支持任意 path 参数读取本地文件。
• 是否对响应头进行安全处理，避免浏览器错误解析。

响应下载时建议显式设置 Content-Disposition，并结合业务情况使用 attachment，减少浏览器直接渲染带来的风险。

Content-Disposition: attachment; filename="report.pdf"
X-Content-Type-Options: nosniff
Cache-Control: private, max-age=0

5. 富文本和图片上传的组合风险

富文本编辑器通常自带图片、视频、附件上传能力，而且很多项目会把它作为公共组件复用。问题在于：业务方可能认为它只是“上传图片”，但实际组件支持的格式更多，或者历史配置中打开了文件管理功能。

这类入口建议单独审计：

• 编辑器上传接口是否需要登录。
• 是否区分不同业务模块的上传权限。
• 是否允许任意文件管理、删除、重命名。
• 返回的 URL 是否为永久公网地址。
• 图片是否经过服务端重新编码处理。

对于头像、封面、评论图片这类场景，可以考虑服务端重新解码再编码，去除潜在的冗余数据和异常结构。注意这不是万能方案，但能显著降低“伪装成图片的复杂文件”带来的风险。

代码审计关注点

在 Java、PHP、Python、Node.js 项目里，上传逻辑写法不同，但审计思路基本类似。建议从入口到出口按链路梳理。

关键加固步骤

如果要给现有系统做一次上传链路加固，可以按下面顺序推进，成本相对可控。

第一步：明确允许上传的业务类型

不要用一个“通用上传接口”承载所有业务。不同场景应该有不同的限制。例如：

• 头像：只允许 jpg、png、webp，限制尺寸和大小。
• 合同附件：允许 pdf、docx，限制最大大小，必须绑定业务单据。
• 报表导入：只允许 xlsx、csv，上传后进入解析队列，原文件隔离保存。
• 工单图片：限制图片格式和数量，访问权限跟随工单。

把限制写在服务端，不要只依赖前端 accept 属性。

第二步：建立统一的文件检测函数

可以封装一个统一的检测组件，避免各业务模块重复写不一致的校验逻辑。检测项至少包括：

• 文件大小限制。
• 扩展名白名单。
• MIME 探测结果。
• 文件头或结构检查。
• 图片尺寸、页数、压缩包层级等业务特征。

public FileCheckResult checkUpload(MultipartFile file, UploadPolicy policy) {
    if (file.isEmpty()) return FileCheckResult.reject("empty file");
    if (file.getSize() > policy.getMaxSize()) return FileCheckResult.reject("file too large");

    String ext = extractExtension(file.getOriginalFilename());
    if (!policy.getAllowedExtensions().contains(ext.toLowerCase(Locale.ROOT))) {
        return FileCheckResult.reject("extension not allowed");
    }

    String detectedMime = tika.detect(file.getInputStream());
    if (!policy.getAllowedMimes().contains(detectedMime)) {
        return FileCheckResult.reject("mime not allowed");
    }

    return FileCheckResult.accept();
}

第三步：隔离存储与访问

上传文件建议放在应用执行目录之外，例如 /data/app/uploads。访问时通过受控下载接口，或者通过对象存储的短期签名 URL。不要把对象存储桶配置成全公开，除非文件确实是公开资源，并且已经明确脱敏和分类。

如果使用对象存储，建议关注：

• 桶策略是否允许匿名列目录。
• 是否存在永久公开读权限。
• 上传 key 是否可预测。
• 是否按业务隔离前缀和权限。
• 是否配置生命周期清理临时文件。

第四步：下载接口做业务权限校验

下载文件时不要只校验“这个文件存在”。更重要的是校验“当前用户是否能访问这个文件所属的业务对象”。

FileRecord file = fileService.getById(fileId);
if (file == null) {
    return notFound();
}

BusinessObject obj = businessService.getById(file.getBizId());
if (!permissionService.canRead(currentUser, obj)) {
    return forbidden();
}

return download(file);

第五步：补充日志、限流和告警

上传入口建议记录必要安全日志，包括用户 ID、业务 ID、文件大小、扩展名、检测结果、来源 IP、失败原因等。对于频繁上传失败、异常大文件、短时间大量上传的行为，可以做限流或告警。

日志注意不要记录完整敏感文件内容，也不要把用户可控文件名直接拼接到结构化日志外层，避免影响日志分析。

漏洞复现中的注意点

在授权测试或内部自查中，建议把验证目标限定在“证明风险存在”即可，不要扩大影响。几个基本原则：

• 不要上传真实恶意程序或具备控制能力的样本。
• 不要尝试读取、下载无关用户的敏感文件。
• 不要破坏业务数据，不覆盖已有文件。
• 优先使用无害测试文件和专用测试账号。
• 测试完成后清理上传文件和临时记录。

很多风险可以用无害方式验证。例如，验证类型校验缺陷时，可以使用普通文本内容配合错误扩展名观察服务端是否拒绝；验证越权下载时，使用两个测试账号分别创建业务数据，确认是否存在跨账号访问即可。

常见误区

• 认为前端限制等于安全限制。前端限制只改善体验，不能作为安全边界。
• 认为 Content-Type 可信。该字段由客户端提交，必须结合服务端检测。
• 认为内网系统不需要严格校验。内网系统一旦被低权限账号滥用，影响同样明显。
• 认为对象存储公开读没问题。公开资源需要有明确分类，不能把所有上传文件默认公开。
• 认为上传接口加了登录就安全。还需要业务权限、类型校验、存储隔离和访问控制。

总结

文件上传风险的核心不是某一个校验点，而是整条链路是否把用户文件当作不可信输入处理。比较稳的思路可以概括为几句话：

• 服务端白名单校验，不相信前端和客户端声明。
• 文件名、路径、存储位置全部由服务端控制。
• 上传目录不具备执行能力，最好与应用目录隔离。
• 下载访问必须绑定业务权限，不只看文件 ID。
• 日志、限流、生命周期清理要跟上。

从代码审计角度看，上传功能很适合作为切入点，因为它连接了认证、权限、文件系统、中间件配置和对象存储策略。把这条链路梳理清楚，往往能发现一些长期被忽略但实际影响不小的问题。