文件上传漏洞代码审计深度教学文档

1. 文件上传漏洞概述

1.1 漏洞定义

任意文件上传漏洞（Unrestricted File Upload Vulnerability）是指Web应用程序在提供文件上传功能时，由于后端服务器对用户上传的文件未进行充分、严格的安全校验，导致攻击者能够上传恶意文件（如Webshell、木马等）至服务器可执行目录，并最终通过访问该文件来执行任意代码，从而获取服务器控制权。

1.2 漏洞危害

该漏洞的危害性极高，通常被视为高危甚至严重漏洞，主要包括：

• 网站篡改： 上传恶意HTML/JS文件，篡改网页内容。
• 服务器沦陷： 上传JSP、PHP等Webshell，获取服务器命令行操作权限。
• 后门植入： 在服务器上植入持久化后门，方便长期控制。
• 内网渗透： 以被攻陷的服务器为跳板，进一步攻击内网其他系统。
• 资源滥用： 在服务器上运行挖矿程序、DDoS僵尸网络程序等，消耗服务器资源。

2. 代码审计核心关注点

在进行文件上传功能的代码审计时，应系统性地检查以下五个关键层面，任何一层的缺失或缺陷都可能导致漏洞。

2.1 文件后缀名校验

这是最基础也是最重要的防御措施。

• 无校验： 直接使用用户上传的文件名，风险极高。
• 黑名单策略： 禁止上传已知的危险后缀（如 .jsp, .php, .asp 等）。
  • 绕过风险：
    • 名单不全：遗漏了 .jspx, .jspf, .cer 等可执行后缀。
    • 大小写绕过：Windows系统对大小写不敏感，.Php 或 .JSP 可能被绕过。
    • 特殊字符绕过：利用Windows特性，如 file.jsp::$DATA、file.jsp.（末尾点）等。
    • 双写绕过：如 file.pphphp。
• 白名单策略（推荐）： 只允许上传业务必需的安全后缀（如 .jpg, .png, .pdf, .docx 等）。这是最佳实践，能极大降低风险。

2.2 文件类型（Content-Type）校验

检查HTTP请求头中的 Content-Type 字段。

• 风险： 该值由客户端控制，极易被篡改。例如，一个恶意JSP文件可被设置为 Content-Type: image/jpeg。
• 结论： 不能仅依赖此校验，必须与后缀名白名单等其他措施结合使用。

2.3 文件内容校验

• 文件头校验： 读取文件的前几个字节（魔数）来判断真实类型。例如，FF D8 FF E0 对应JPEG，89 50 4E 47 对应PNG。这可以有效防止攻击者将JSP文件改名为 .jpg 上传。
• 二次渲染： 对图片文件进行裁剪、缩放、水印等操作。如果上传的是Webshell，经过二次渲染后，恶意代码很可能被破坏，从而失效。这是非常有效的防御手段，但需要审计代码确认渲染过程是否彻底。

2.4 保存路径与文件名

• 路径不可控： 保存路径应由服务端硬编码或安全生成，防止路径遍历攻击（如 ../../../webapps/ROOT/shell.jsp）。
• 文件名随机化： 不使用用户原始文件名，而是使用随机生成的名字（如UUID）加上白名单内的后缀。这能有效防止攻击者直接访问到Webshell，增加利用难度。
• 目录不可执行： 将上传的文件保存在Web服务器无法直接解析的目录（如静态资源目录 /static/upload/ 仅能访问图片），并通过后端程序（如Servlet）代理访问。即使Webshell上传成功，也无法直接执行。

2.5 框架与服务器限制

• SpringBoot与JSP： 默认情况下，SpringBoot不支持JSP。需要额外添加 tomcat-embed-jasper 依赖。审计时需检查 pom.xml 或 build.gradle，确认是否存在此依赖。如果不存在，即使上传了JSP文件也无法执行，风险降低。
• 云存储（OSS）： 如果文件最终被上传到云存储服务（如阿里云OSS、七牛云），并且该存储桶配置为不可执行，那么Webshell同样无法运行。

3. 代码审计实战流程

3.1 定位上传功能点

在庞大的代码库中，快速定位文件上传功能是关键。

• 前端搜索： 查找带有 type="file" 的 <input> 标签。
• 后端搜索关键字：
  • MultipartFile
  • @RequestParam("file")
  • FileUpload
  • FileOutputStream
  • transferTo()
  • commons-fileupload 相关类（如 FileItem）
• API文档/路由： 查看Controller层的映射路径，如 @PostMapping("/upload")。

3.2 案例审计分析

以下是对原文中案例代码的逐行审计：

public String gok4(HttpServletRequest request, HttpServletResponse response,
                   @RequestParam(value = "uploadfile", required = true) MultipartFile uploadfile,
                   @RequestParam(value = "param", required = false) String param,
                   @RequestParam(value = "fileType", required = true) String fileType, // [!code focus]
                   @RequestParam(value = "pressText", required = false) String pressText) {
    try {
        long maxSize = 4096000L; // 检查1：文件大小限制（4MB），安全。
        if (uploadfile.getSize() > maxSize) {
            return this.responseErrorData(response, 1, "上传的图片大小不能超过4M。");
        } else {
            String[] type = fileType.split(",");
            this.setFileTypeList(type);
            String ext = FileUploadUtils.getSuffix(uploadfile.getOriginalFilename()); // 获取文件后缀
            // 检查2：后缀名校验 // [!code focus]
            if (fileType.contains(ext) && !"jsp".equals(ext)) { // [!code focus]
                String filePath = this.getPath(request, ext, param);
                File file = new File(this.getProjectRootDirPath(request) + filePath);
                if (!file.getParentFile().exists()) {
                    file.getParentFile().mkdirs();
                }
                uploadfile.transferTo(file); // 执行文件保存
                return this.responseData(filePath, 0, "上传成功", response);
            } else {
                return this.responseErrorData(response, 1, "文件格式错误，上传失败。");
            }
        }
    } catch (Exception var13) {
        logger.error("gok4()--error", var13);
        return this.responseErrorData(response, 2, "系统繁忙，上传失败");
    }
}

漏洞分析：

1. 致命的逻辑缺陷： 校验逻辑 if (fileType.contains(ext) && !"jsp".equals(ext)) 存在严重问题。fileType 是用户通过HTTP请求参数可控的！攻击者可以将其设置为 jpg,png,jspx,jsp。
2. 绕过验证：
   • 当攻击者上传 shell.jspx 时，ext = "jspx"。
   • 条件判断：fileType.contains("jspx") 为 true（因为用户可控的 fileType 包含了 jspx），且 !"jsp".equals("jspx") 也为 true。
   • 因此，校验通过，恶意文件被成功保存。
3. Windows特性绕过： 由于校验逻辑不可靠，攻击者同样可以利用 shell.jsp::$DATA 等方式绕过。

根本原因： 文件类型白名单绝对不应该由用户控制，而应在后端硬编码定义。

4. 安全修复方案

1. 使用硬编码的白名单：

   // 正确做法
   private static final Set<String> ALLOWED_EXTENSIONS = Set.of("jpg", "jpeg", "png", "gif", "pdf");
   // ...
   String ext = getFileExtension(filename);
   if (!ALLOWED_EXTENSIONS.contains(ext.toLowerCase())) {
       // 拒绝上传
   }
   

2. 重命名文件： 使用随机生成的文件名（如UUID）保存文件，避免使用用户原始文件名。

3. 校验文件内容： 结合文件头检查，确保文件真实类型与后缀名匹配。

4. 设置安全的存储路径：

   • 路径固定，防止路径遍历。
   • 存储在Web根目录之外，或配置为静态资源目录（无执行权限）。

5. 限制文件大小。

6. 处理图片时进行二次渲染。

7. 定期更新依赖库，避免使用存在已知漏洞的第三方文件上传组件。

5. 总结

文件上传漏洞的审计是一个系统工程，需要审计人员具备深度防御的思想。核心在于不信任任何用户输入。审计时应遵循以下流程：

• 定位： 快速找到所有文件上传功能点。
• 追踪： 跟踪整个上传处理流程。
• 校验： 逐一检查后缀名、内容类型、文件内容、存储路径与文件名这四道防线的完整性。
• 绕过： 思考在每一道防线可能存在的绕过方法。
• 定级： 根据漏洞的可利用性和潜在危害确定风险等级。

通过本文档的详细剖析，您应该能够系统性地对Java Web应用的文件上传功能进行全面的代码安全审计。