一次 Java Web 代码审计中的文件上传风险梳理与修复建议

背景文件上传是 Java Web 项目里很常见的功能，但也是代码审计中反复出现问题的入口。很多项目表面上做了后缀校验、大小限制，实际落到代码细节时，仍然会出现路径可控、类型判断不可靠、文件可被直接访问、临时文件未清理等风险。这篇文章整理的是一次偏通用的审计思路，不针对特定业务系统展开攻击利用，重点放在如何识别风险点、如何做安全修复，以及如何建立更稳定的上传处理流程。适合在做 Java Web 代码审计、整改上传模块或制定安全规范时参考。典型场景审计中遇到的上传逻辑大致如下：前端提交 multipart/form-data，请求进入 Controller 后，后端读取 MultipartFile，检查文件名后缀和大小，然后把文件保存到服务器目录，最后返回一个可访问 URL。POST /api/file/upload
Content-Type: multipart/form-data

[email protected]从业务角度看，这个流程没有问题。但从安全角度看，需要重点确认以下几个问题：上传目录是否在 Web 可直接访问路径下。服务端是否信任了原始文件名。是否仅通过后缀判断文件类型。是否允许用户控制保存路径或文件名。是否对文件内容、大小、数量、频率做了限制。是否存在上传后自动解压、自动解析、自动转换等后续处理。问题一：信任原始文件名很多代码会直接使用 file.getOriginalFilename() 作为保存文件名。这个值来自客户端，不应该被信任。即使框架会做一部分处理，业务代码仍然需要主动规整。风险点主要有两个：一是文件名中可能携带路径分隔符，导致路径拼接异常；二是文件名中可能包含特殊字符，影响后续展示、日志记录或对象存储路径处理。String originalName = file.getOriginalFilename();
String savePath = uploadDir + File.separator + originalName;
file.transferTo(new File(savePath));更稳妥的做法是忽略用户提交的文件名，只保留必要的扩展名，然后由服务端生成随机文件名。String originalName = file.getOriginalFilename();
String ext = getSafeExtension(originalName);

String newName = UUID.randomUUID().toString().replace(