从代码审计角度梳理文件上传风险：常见缺陷、验证思路与加固实践

背景

文件上传是 Web 系统里非常常见的功能，头像、附件、工单截图、导入模板都会用到。它看起来只是一个业务功能，但在安全审计里经常能看到问题：后端只校验前端参数、扩展名判断不严谨、上传目录可执行、对象存储权限配置过宽、文件解析链路存在差异等。

这篇文章不讨论利用细节，也不提供攻击性操作步骤，主要从代码审计和防守视角整理一套相对通用的检查方法。适合做内部安全评审、研发自查、上线前验收，也适合复盘历史文件上传类问题时使用。

典型场景与风险边界

常见上传入口大致可以分为几类：

• 用户资料类：头像、实名认证图片、个人附件。
• 业务流转类：工单附件、审批附件、合同扫描件。
• 数据导入类：Excel、CSV、压缩包、批量素材。
• 后台管理类：模板上传、主题资源、插件资源。
• 开放接口类：通过 API 上传图片、视频、日志文件。

从风险看，文件上传问题不只等于“上传脚本”。更常见的风险包括：

• 上传恶意内容后被业务系统解析，引发服务端处理异常。
• 上传超大文件或压缩炸弹，造成磁盘、内存、CPU 资源耗尽。
• 文件名未规范化，引发路径穿越、覆盖文件、日志污染。
• 上传后可被公网直接访问，导致敏感附件泄露。
• 对象存储 Bucket 权限错误，扩大数据暴露面。
• 图片、Office、PDF 等文件被下游组件处理时触发解析漏洞。

审计时先看数据流

做文件上传审计，不建议只盯着某一个 Controller。更稳妥的方式是把完整数据流串起来：

• 入口：哪个接口接收文件，是否需要登录、鉴权、权限校验。
• 校验：校验文件名、扩展名、MIME、文件头、大小、数量、内容结构。
• 存储：保存到本地磁盘、NFS、对象存储，目录是否隔离。
• 访问：上传后是否生成可访问 URL，是否需要鉴权，是否长期有效。
• 处理：是否进入图片压缩、文档预览、解压、转码、OCR、杀毒等链路。
• 清理：上传失败、业务取消、过期附件是否清理。

很多漏洞不是出在“上传”这一行，而是出在后续处理。例如上传接口本身限制了图片，但后续预览服务按文件扩展名调用不同解析器；或者存储服务给了公开读权限，导致本来只应在工单内访问的附件变成了公网静态资源。

常见缺陷一：只相信前端校验

这是最基础但仍然常见的问题。前端限制文件类型、大小、数量只能改善用户体验，不能作为安全边界。后端必须重新校验。

审计时可以搜索以下关键词定位入口：

MultipartFile
@RequestParam("file")
getOriginalFilename()
transferTo(
CommonsMultipartFile
ServletFileUpload
Part getSubmittedFileName

如果只在前端写了类似 accept="image/*"，后端没有任何校验，基本可以直接判定为高风险实现。

常见缺陷二：扩展名黑名单不可靠

很多系统采用黑名单方式，例如禁止某些脚本扩展名。这种做法维护成本高，也容易遗漏大小写、双后缀、空格、特殊字符、解析差异等情况。

更推荐使用白名单：业务只允许什么，就只放行什么。例如头像只允许 jpg、jpeg、png、webp；合同扫描件只允许 pdf；数据导入只允许 xlsx 或 csv。

白名单判断时要注意几点：

• 先取最后一个扩展名，并统一转小写。
• 对文件名做规范化，去除不可见字符和路径分隔符。
• 不要直接使用用户原始文件名作为存储文件名。
• 扩展名校验不能替代内容校验。

一个相对稳妥的命名方式是：服务端生成随机文件名，扩展名只从白名单映射中取。

String ext = getSafeExtension(originalFilename);
if (!allowedExt.contains(ext)) {
    throw new IllegalArgumentException("unsupported file type");
}

String objectName = UUID.randomUUID().toString().replace("-", "") + "." + ext;
Path target = uploadBase.resolve(objectName).normalize();

常见缺陷三：MIME 与文件头校验缺失

Content-Type 由客户端提交，不能直接信任。后端可以用它做参考，但不能作为唯一判断依据。对于图片类文件，建议结合扩展名、MIME 探测和文件头检查。

Java 项目里常见的做法是使用 Apache Tika 或 ImageIO 做基础识别。注意：识别库本身也可能成为解析入口，因此不要对不可信文件做过度复杂的解析，尤其是历史版本组件。

// 示例：基础 MIME 探测，仅作为防守校验思路
Tika tika = new Tika();
String detected = tika.detect(inputStream);

if (!Set.of("image/jpeg", "image/png", "image/webp").contains(detected)) {
    throw new IllegalArgumentException("invalid file content");
}

图片业务还可以做一次安全重编码：读取原图后重新编码为标准格式，丢弃原始元数据和异常结构。这样可以降低部分“伪装图片”或携带异常段数据的风险。重编码失败则拒绝上传。

常见缺陷四：上传目录可执行或与应用目录混放

上传目录不要放在 Web 应用可执行路径下，也不要与模板、插件、静态资源构建目录混在一起。推荐做法：

• 上传文件存储在应用目录之外。
• 通过独立文件服务读取，不直接暴露真实路径。
• 静态服务禁用脚本执行能力。
• 本地存储目录设置最小权限，只给应用进程必要读写权限。

Nginx 场景下，如果只是提供静态附件访问，应明确禁止脚本解析，并限制目录访问行为：

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

# 不在 uploads 下配置任何 PHP、JSP、CGI 等执行解析规则

如果附件包含隐私或业务敏感内容，不建议直接使用静态目录公开访问。应通过业务接口鉴权后再返回文件流，或者使用对象存储的短期签名 URL。

常见缺陷五：路径穿越与文件覆盖

用户上传的原始文件名不能直接拼接到服务端路径中。例如 originalFilename 里可能包含路径分隔符、编码后的特殊字符，甚至与系统已有文件重名。

安全实现的关键点：

• 服务端生成存储名，不使用原始文件名落盘。
• 保存路径使用固定根目录。
• resolve 后执行 normalize，并确认最终路径仍在根目录下。
• 业务展示名与存储名分离，展示名只作为数据库字段保存，并做长度与字符限制。

Path base = Paths.get("/data/app/uploads").toAbsolutePath().normalize();
Path target = base.resolve(objectName).normalize();

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

常见缺陷六：大小、数量与压缩包处理不受控

上传功能必须限制大小和数量。很多资源消耗型问题不是单个文件导致，而是批量上传、并发上传、压缩包解压后体积膨胀导致。

建议至少设置这些限制：

• 单文件大小限制。
• 单次请求文件数量限制。
• 用户或业务对象维度的总容量限制。
• 上传接口限流。
• 临时文件目录容量监控。
• 压缩包解压后的总大小、文件数量、目录层级限制。

Spring Boot 可以先在框架层做基础限制：

spring.servlet.multipart.max-file-size=10MB
spring.servlet.multipart.max-request-size=20MB
spring.servlet.multipart.location=/data/app/tmp-upload

但框架限制不等于业务限制。业务层仍然要根据用户角色、业务类型做细粒度控制。

压缩包解压的审计重点

如果系统支持 zip、tar 等压缩包上传，审计要格外谨慎。常见问题包括目录穿越、覆盖文件、符号链接、解压炸弹、文件数量过多。

解压时需要对每个 entry 做校验：

• 拒绝绝对路径。
• 拒绝包含 .. 的路径。
• normalize 后确认仍在目标目录内。
• 限制总解压大小和文件数量。
• 谨慎处理符号链接。

Path destDir = Paths.get("/data/app/imports/job-123").toAbsolutePath().normalize();
Path out = destDir.resolve(entry.getName()).normalize();

if (!out.startsWith(destDir)) {
    throw new SecurityException("zip entry path traversal detected");
}

对象存储场景的注意点

现在很多系统把文件直接上传到对象存储，例如 S3、OSS、COS、MinIO。对象存储能减少本地磁盘风险，但也引入了新的配置风险。

重点检查：

• Bucket 是否误配置为公开读或公开写。
• 前端直传使用的临时凭证是否权限过大。
• 上传路径是否绑定用户和业务范围。
• 签名 URL 有效期是否过长。
• 是否允许覆盖其他用户对象。
• 对象元数据中的 Content-Type 是否可信。

前端直传常见安全模型是：后端鉴权后签发短期、最小权限上传凭证，只允许写入指定前缀和限定大小的对象；上传完成后，前端回调业务接口，由后端再次校验对象信息并绑定业务记录。

下载与预览同样需要鉴权

不少系统上传时做了登录校验，但下载链接是固定 URL，任何拿到链接的人都能访问。对于头像、公开素材这类资源问题不大，但工单附件、合同、身份证明、内部日志等必须鉴权。

建议下载接口至少校验：

• 当前用户是否登录。
• 用户是否有该业务对象的访问权限。
• 文件记录是否属于该业务对象。
• 文件状态是否有效，是否已删除或过期。
• 响应头是否避免浏览器误解析。

Content-Disposition: attachment; filename="safe-name.pdf"
X-Content-Type-Options: nosniff
Cache-Control: private, no-store

对于用户上传的 HTML、SVG、PDF 等可能被浏览器主动解析的内容，建议谨慎开放在线预览。若必须预览，最好使用隔离域名、沙箱策略和严格响应头。

日志与告警

上传功能也应该进入安全日志范围。日志不是为了记录用户隐私内容，而是为了在异常发生时能够定位。

建议记录：

• 用户 ID、业务 ID、上传接口。
• 文件大小、扩展名、检测出的 MIME。
• 存储对象名或文件 ID。
• 校验失败原因。
• 同一用户短时间内失败次数。
• 异常上传频率、超大文件、异常类型分布。

注意不要在日志中记录完整敏感文件内容，也不要把用户提交的原始文件名未经处理直接写入结构化日志，避免日志污染。

代码审计检查清单

一个相对安全的上传处理流程

可以把上传流程设计成以下步骤：

• 第一步：接口层校验登录状态和业务权限。
• 第二步：检查文件是否为空、大小是否超过限制。
• 第三步：规范化原始文件名，只保留展示用途。
• 第四步：根据白名单校验扩展名。
• 第五步：探测文件 MIME 或做必要的结构校验。
• 第六步：生成随机存储名，保存到隔离目录或对象存储指定前缀。
• 第七步：必要时执行图片重编码、病毒扫描或异步审核。
• 第八步：写入数据库文件记录，绑定业务对象。
• 第九步：下载和预览统一走鉴权接口。
• 第十步：记录安全日志并对异常行为告警。

文件上传的安全目标不是“过滤掉所有坏文件”，而是让不可信文件始终处在受控环境中：不能执行、不能越权访问、不能覆盖系统文件、不能拖垮服务、不能绕过业务授权。

研发落地建议

从实际项目经验看，文件上传安全最好不要让每个业务各写一套。更稳妥的方式是封装统一上传服务或组件，业务侧只声明允许的文件类型、大小、是否公开、绑定对象类型。

例如可以定义几类策略：

• PUBLIC_IMAGE：公开图片，允许 jpg/png/webp，上传后重编码，可公开读。
• PRIVATE_ATTACHMENT：私有附件，允许 pdf/docx/xlsx/png/jpg，必须鉴权下载。
• DATA_IMPORT：数据导入文件，允许 xlsx/csv，上传后进入异步解析队列。
• ARCHIVE_IMPORT：压缩包导入，开启解压安全限制和异步扫描。

这样做的好处是规则集中、审计成本低、后续加固也容易。如果每个 Controller 都手写上传逻辑，随着业务增长很容易出现策略不一致。

总结

文件上传问题的根因通常不是某个单点判断缺失，而是系统没有把“不可信文件”作为完整生命周期来管理。审计时要从入口、校验、存储、访问、处理、清理六个环节看数据流。

实际加固时，优先处理几类高风险问题：上传目录可执行、下载无鉴权、对象存储公开写、路径穿越、压缩包不受控、只做前端校验。把这些基础问题解决掉，整体风险会下降很多。

最后建议把上传安全做成统一能力，而不是依赖每个业务开发各自实现。规则集中之后，代码审计、应急排查和后续治理都会轻很多。