从代码审计角度梳理文件上传风险：常见缺陷、验证方法与加固建议

背景

文件上传功能在业务系统里很常见，比如头像、附件、工单材料、富文本图片等。它看起来只是一个普通的输入点，但在真实审计中，上传点往往会牵出一整条风险链：类型校验不严、存储路径可控、文件可被直接访问、解析规则不一致、对象存储权限配置错误等。

这篇文章主要从代码审计和安全测试的角度，整理文件上传风险的排查思路。重点放在如何识别问题、如何验证风险边界、如何加固，不提供针对真实目标的攻击操作，也不讨论绕过授权或恶意控制场景。

典型问题场景

我在审计 Web 项目时，比较常见的上传问题可以归纳为以下几类：

• 仅依赖前端校验文件类型，后端没有二次校验。
• 后端只检查文件后缀，没有检查 MIME、文件头或内容特征。
• 上传目录位于 Web 可访问目录，并且服务器会对其中某些扩展名进行解析。
• 文件名直接使用用户输入，导致路径穿越、覆盖已有文件或特殊字符问题。
• 上传后返回可预测路径，且缺少访问控制。
• 对象存储桶权限过宽，导致文件被公开读取或枚举。
• 图片处理、压缩、转码组件存在历史漏洞或处理异常。

这些问题单独看可能只是中低风险，但如果和错误的服务器配置、弱访问控制、敏感信息泄露组合在一起，就可能变成高危入口。

审计切入点

审计文件上传时，不建议只盯着控制器接口。完整链路至少要看四个环节：接收、校验、存储、访问。

1. 接收层：确认输入来源

常见 Java Spring 项目中，可以先检索 MultipartFile、RequestPart、RequestParam 等关键字：

grep -R "MultipartFile\|RequestPart\|CommonsMultipartFile" -n src/main/java

PHP 项目可以检索：

grep -R "\$_FILES\|move_uploaded_file" -n .

Node.js 项目可以关注 multer、formidable、busboy 等库：

grep -R "multer\|formidable\|busboy" -n src

这里主要确认三个问题：

• 上传接口是否需要登录或权限校验。
• 上传大小是否有限制。
• 是否存在多处上传逻辑，各自实现不一致。

2. 校验层：不要只看后缀

很多代码会这样判断：

String suffix = filename.substring(filename.lastIndexOf(".") + 1);
if (!allowList.contains(suffix)) {
    throw new RuntimeException("file type not allowed");
}

这种写法至少有几个问题：

• 没有统一转小写，大小写绕过会导致策略失效。
• 没有处理无后缀、多个点、特殊 Unicode 字符。
• 只校验后缀，无法判断文件真实内容。
• filename 可能为空，lastIndexOf 返回 -1 时容易触发异常。

更稳妥的方式是组合校验：扩展名白名单、MIME 类型、文件头特征、内容安全扫描，以及业务侧的用途限制。对于图片类上传，还可以在服务端进行解码重编码，避免原始文件直接落地对外提供。

示例伪代码如下：

private static final Set<String> ALLOWED_EXT = Set.of("jpg", "jpeg", "png", "pdf");

public void validateUpload(MultipartFile file) throws IOException {
    if (file == null || file.isEmpty()) {
        throw new IllegalArgumentException("empty file");
    }

    if (file.getSize() > 5 * 1024 * 1024) {
        throw new IllegalArgumentException("file too large");
    }

    String originalName = file.getOriginalFilename();
    String ext = getSafeExt(originalName).toLowerCase(Locale.ROOT);
    if (!ALLOWED_EXT.contains(ext)) {
        throw new IllegalArgumentException("unsupported file type");
    }

    String contentType = file.getContentType();
    if (!isExpectedMime(ext, contentType)) {
        throw new IllegalArgumentException("mime mismatch");
    }

    byte[] head = file.getInputStream().readNBytes(16);
    if (!matchMagicBytes(ext, head)) {
        throw new IllegalArgumentException("file header mismatch");
    }
}

注意：MIME 和文件头都不是银弹，但组合使用能明显降低误判和低成本绕过。真正关键的是上传后的文件不要进入可执行路径。

3. 存储层：隔离比过滤更重要

上传文件不应存放在应用代码目录、模板目录或服务器会解释执行的目录中。比较稳妥的做法是：

• 上传文件存储到独立目录或对象存储。
• 文件名由服务端生成，避免使用用户原始文件名作为实际存储名。
• 保存原始文件名时只作为展示字段，输出时做好 HTML 转义。
• 上传目录禁用脚本执行权限。
• 文件访问通过受控下载接口或带过期时间的签名 URL。

例如 Nginx 下对上传目录增加保守配置：

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|cgi|pl|sh)$ {
    return 403;
}

如果使用对象存储，建议默认私有桶，业务访问通过后端签名生成短时 URL。不要把“上传成功后返回永久公网地址”当成默认方案，尤其是工单附件、合同、报表这类文件。

4. 访问层：确认是否存在越权读取

上传功能的另一个常见问题是“上传安全，但下载不安全”。例如用户 A 上传的附件，用户 B 可以通过猜测 ID 或 URL 直接访问。审计时需要确认：

• 文件元数据是否绑定租户、用户、业务对象。
• 下载接口是否校验当前用户对业务对象的访问权限。
• 文件 ID 是否可枚举。
• 外链是否有过期时间和访问范围限制。

一个相对合理的下载流程是：用户请求文件 ID，服务端查询文件元数据，校验当前用户是否有权访问对应业务对象，然后再读取文件流返回。不要仅通过路径参数直接读取磁盘文件。

关键验证步骤

在授权测试或内部自查场景中，可以按下面顺序验证，不建议一上来就构造复杂样本。很多问题通过配置和代码逻辑就能判断出来。

步骤一：梳理上传接口清单

• 从路由、控制器、网关日志中收集所有上传接口。
• 标记接口是否需要认证。
• 记录每个接口允许的文件类型、大小、存储位置。
• 确认是否存在历史遗留接口或调试接口。

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

• 确认校验逻辑是否在服务端执行，而不是只依赖前端。
• 确认白名单是否统一维护，避免不同接口策略不一致。
• 检查异常分支，例如空文件名、无后缀、多后缀、大小写扩展名。
• 确认是否限制文件大小，避免资源消耗问题。

步骤三：检查落地目录和 Web 服务器配置

Linux 环境可以快速查看上传目录权限：

ls -ld /data/app/uploads
find /data/app/uploads -maxdepth 2 -type f | head

同时检查 Nginx、Apache、Tomcat 等配置，确认上传目录不会被解释执行，也不会开启目录索引。

步骤四：检查下载鉴权

重点看下载接口是否只接收 fileId 或 path 参数后直接返回文件。典型风险代码如下：

@GetMapping("/download")
public void download(String path, HttpServletResponse response) throws IOException {
    File file = new File(baseDir + "/" + path);
    Files.copy(file.toPath(), response.getOutputStream());
}

这类代码的问题不只是路径穿越，还包括缺少业务权限校验。更好的方式是只接收文件 ID，并在服务端通过元数据表找到真实路径：

@GetMapping("/files/{id}")
public void download(@PathVariable Long id, CurrentUser user, HttpServletResponse response) {
    FileMeta meta = fileService.getFileMeta(id);
    permissionService.checkFileReadable(user, meta.getBizType(), meta.getBizId());
    fileService.writeFile(meta.getStorageKey(), response);
}

常用辅助规则

如果项目较大，可以用 Semgrep 或自定义脚本做初筛。下面是一个非常简单的示例，用于提醒直接拼接路径读取文件的位置，实际项目需要结合框架和编码规范调整。

rules:
  - id: java-file-path-from-request
    message: "Potential file path constructed from request parameter"
    severity: WARNING
    languages: [java]
    patterns:
      - pattern-either:
          - pattern: |
              new File($BASE + $PARAM)
          - pattern: |
              Paths.get($BASE, $PARAM)
      - metavariable-pattern:
          metavariable: $PARAM
          pattern-either:
            - pattern: request.getParameter(...)
            - pattern: $REQ.getParameter(...)

这类规则不能直接等同于漏洞结论，但可以帮助审计人员快速定位高风险代码片段。

加固建议清单

容易忽略的注意点

• 富文本编辑器自带上传接口经常被忽略，尤其是历史版本插件。
• 后台管理系统也要做严格校验，不能因为“只有管理员用”就放松。
• 图片压缩、PDF 预览、Office 转换等二次处理组件要关注安全更新。
• 多租户系统要特别注意对象存储路径隔离和下载鉴权。
• 前端限制 accept 属性只能改善体验，不能作为安全控制。
• CDN 缓存可能导致已删除或权限变更后的文件仍被访问，需要设计失效策略。

总结

文件上传安全的核心不是堆很多过滤规则，而是控制文件生命周期：谁能上传、上传什么、存在哪里、如何访问、何时删除、是否可追溯。

从审计经验看，最有效的防线通常是三点：服务端白名单校验、存储与执行环境隔离、下载侧强制鉴权。只要这三点做扎实，大部分上传类风险都会被限制在可控范围内。后续再结合日志、告警、组件更新和自动化规则，才能形成比较稳定的长期治理能力。