从代码审计到验证：一次文件上传漏洞的排查与加固思路

背景

文件上传功能在业务系统里很常见，比如头像、附件、工单截图、富文本图片等。它看起来只是一个普通入口，但在实际代码审计中，上传点往往是高风险区域：一旦校验不严，可能导致任意文件写入、脚本文件落地、路径穿越、存储型 XSS，甚至进一步扩大影响面。

这篇文章整理一套偏实战的排查思路，重点放在安全审计、复现验证和加固方案上。内容不讨论未授权入侵或恶意利用，只以授权测试环境为前提，帮助开发和安全同学定位问题、降低风险。

常见场景与风险点

文件上传漏洞通常不是单点失误，而是多个环节叠加导致的。比较常见的问题包括：

• 只校验前端限制，后端没有做类型判断。
• 仅根据文件后缀判断类型，未校验真实内容。
• 允许用户控制文件名或保存路径，导致路径穿越或覆盖文件。
• 上传目录位于 Web 可访问路径下，且服务端会解析其中的脚本文件。
• 未限制文件大小、数量和压缩包解压行为，导致资源消耗风险。
• 图片、SVG、HTML 等类型处理不当，引发存储型 XSS。

实际审计时，不建议只盯着“能不能上传脚本文件”这一种结果。很多上传点即便不能执行服务端脚本，也可能通过 HTML、SVG、PDF、Office 宏、压缩包、文件名污染等方式带来风险。

代码审计入口

审计上传功能时，我通常先从路由和控制器入口开始，确认上传请求最终流向哪里。常见关键字包括：

upload
multipart
MultipartFile
move_uploaded_file
Request.Files
FileUpload
saveAs
store
attachment
avatar
import
parseZip

以 Java/Spring 项目为例，常见入口可能类似：

@PostMapping("/upload")
public String upload(@RequestParam("file") MultipartFile file) throws IOException {
    String filename = file.getOriginalFilename();
    File dest = new File("/data/upload/" + filename);
    file.transferTo(dest);
    return "/upload/" + filename;
}

这段代码问题比较典型：原始文件名直接参与路径拼接，没有处理路径穿越；没有限制文件大小；没有校验扩展名和 MIME；没有做内容识别；返回了可访问路径。如果上传目录被 Web 服务直接暴露，风险会更高。

技术分析：不要只相信 Content-Type

很多系统会通过请求头里的 Content-Type 或 Multipart 中的 MIME 来判断文件类型，例如 image/png、image/jpeg。这类字段由客户端提供，不应作为唯一依据。

更稳妥的方式是多层校验：

• 扩展名白名单：只允许业务确实需要的类型。
• 服务端 MIME 检测：结合文件头特征识别，不依赖客户端传入值。
• 文件魔数校验：检查文件头是否符合预期格式。
• 安全解码验证：图片类文件可尝试解码重编码，避免伪装文件。
• 存储隔离：上传文件不放在可执行目录下。

例如图片上传场景，后端不应仅判断后缀为 jpg/png。可以读取文件头并使用图片库尝试解析，再重新编码保存。这样可以过滤一部分伪造内容和异常结构文件。

关键步骤：授权环境下的验证方法

在授权测试环境中，可以按以下顺序验证上传点的安全性。这里重点是确认防护是否生效，而不是追求破坏性结果。

1. 确认上传目录和访问方式

先判断上传后的文件是否能通过 URL 直接访问。如果上传目录与应用静态资源目录混在一起，就需要格外关注。

# 示例：检查响应中返回的访问路径
POST /api/upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----test

------test
Content-Disposition: form-data; name="file"; filename="test.png"
Content-Type: image/png

...file content...
------test--

关注响应中是否返回类似 /upload/test.png、/static/upload/test.png 这样的路径。如果返回的是对象存储临时地址，也要确认是否设置了正确的 Content-Type 和下载策略。

2. 测试扩展名白名单

上传功能应采用白名单策略，而不是黑名单。黑名单容易漏掉大小写、双后缀、特殊解析规则等情况。

允许示例：jpg、jpeg、png、gif、pdf
拒绝示例：php、jsp、jspx、asp、aspx、html、svg、shtml、exe、sh、bat

需要注意，svg 虽然是图片格式，但其本质是 XML，可能包含脚本或外部引用。如果业务没有强需求，不建议允许直接上传 svg；如果必须支持，应进行严格清洗并设置下载而非内联展示。

3. 检查文件名处理

用户上传的原始文件名不应直接落盘。常见风险包括路径穿越、覆盖已有文件、特殊字符污染日志或响应头。

// 不推荐
String filename = file.getOriginalFilename();
Path dest = Paths.get(uploadDir, filename);

// 推荐思路
String ext = getSafeExtension(file);
String filename = UUID.randomUUID().toString().replace("-", "") + "." + ext;
Path dest = Paths.get(uploadDir).resolve(filename).normalize();
if (!dest.startsWith(Paths.get(uploadDir).normalize())) {
    throw new SecurityException("invalid path");
}

实际项目中，建议将原始文件名只作为元数据保存，并在展示时做 HTML 转义，不参与真实存储路径。

4. 检查大小、数量和解压逻辑

上传接口如果没有限制大小和频率，容易被用来消耗磁盘和带宽。压缩包上传则要关注 Zip Slip 和解压炸弹风险。

# Nginx 限制请求体大小示例
server {
    client_max_body_size 10m;
}

# Spring Boot 配置示例
spring.servlet.multipart.max-file-size=10MB
spring.servlet.multipart.max-request-size=20MB

如果业务支持压缩包导入，解压时必须检查每个条目的规范化路径，确保不会写出目标目录。

Path targetDir = Paths.get("/data/import").normalize();
Path output = targetDir.resolve(entry.getName()).normalize();
if (!output.startsWith(targetDir)) {
    throw new SecurityException("zip entry path traversal detected");
}

5. 检查响应头与展示方式

上传后的文件如果可以在线预览，需要关注浏览器解析行为。对于不需要内联展示的文件，建议使用附件下载，并设置合适的响应头。

Content-Disposition: attachment; filename="download.pdf"
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'none'; img-src 'self'; style-src 'self'

尤其是用户可控内容，如果被浏览器当作 HTML/SVG 解析，就可能引入存储型 XSS。对象存储场景也一样，不能只把文件丢到桶里，还要检查元数据里的 Content-Type。

加固建议

文件上传防护建议分层做，不要依赖单一校验点。

• 使用白名单：只允许业务明确需要的后缀和类型。
• 服务端强校验：后端根据文件内容识别类型，不信任前端参数。
• 随机文件名：使用 UUID、雪花 ID 等生成存储名，避免用户控制路径。
• 目录隔离：上传目录与应用代码目录分离，禁止脚本执行。
• 权限最小化：上传目录只授予必要读写权限，不给执行权限。
• 大小限制：限制单文件大小、总请求大小、上传频率。
• 内容处理：图片类文件可重编码；文档类文件可转存为安全格式或走下载。
• 安全响应头：设置 nosniff、Content-Disposition、CSP 等。
• 日志审计：记录上传用户、文件哈希、大小、类型、来源 IP、处理结果。
• 异步扫描：对高风险文件接入杀毒或内容安全扫描，但不要把扫描当作唯一防线。

参考的安全实现流程

一个相对稳妥的上传处理流程可以这样设计：

1. 验证登录态和业务权限
2. 检查请求大小和文件数量
3. 获取原始文件名，仅用于展示元数据
4. 解析扩展名，匹配白名单
5. 读取文件头，做内容类型识别
6. 对图片等格式进行解码与重编码
7. 生成随机文件名，保存到非 Web 可执行目录
8. 保存文件元数据与哈希
9. 返回文件 ID，不直接暴露真实路径
10. 下载时通过鉴权接口读取文件并设置安全响应头

如果业务允许公开访问文件，也建议通过独立域名或对象存储隔离，避免与主站共享 Cookie 和执行上下文。

审计时容易忽略的点

注意点

上传漏洞的验证应始终在授权范围内进行。测试重点应放在确认校验链路是否可靠、是否能隔离风险，而不是尝试造成破坏性影响。

另外，安全扫描工具可以辅助发现问题，但不适合完全替代人工审计。上传逻辑经常与业务强相关，例如“普通用户只能上传图片，管理员可以上传模板文件”，这种差异需要结合权限模型一起看。

总结

文件上传安全的核心不是某一个判断条件，而是完整链路的风险控制：类型校验、路径处理、存储隔离、访问控制、响应头、日志审计都要覆盖。比较理想的状态是，即便某一层校验出现遗漏，文件也不会进入可执行环境，用户也无法通过上传内容影响主站上下文。

在代码审计中，建议把上传点作为高优先级入口处理。只要发现“原始文件名直接保存”“上传目录可直接访问”“只依赖 Content-Type”“压缩包未检查路径”这几类问题，就值得进一步复核并推动修复。