# 漏洞总结：jeecgboot 直接 SSRF 漏洞 ## 漏洞概述 在 `jeecgboot_jeecgBoot` 的 `/sys/common/uploadImgByHttp` 接口中存在直接服务端请求伪造（SSRF）漏洞。该漏洞允许攻击者通过构造恶意请求，使服务器向任意外部或内部资源发起 HTTP 请求，从而获取敏感信息或探测内网服务。 ## 影响范围 - **受影响版本**：<= 3.9.1 - **受影响组件**： - `CommonController.java` (L321-344) - `HttpFileToMultipartFileUtil.java` (L28-66) - **受影响函数/方法**： - `CommonController.uploadImgByHttp()` - `HttpFileToMultipartFileUtil.HttpFileToMultipartFile()` - `HttpFileToMultipartFileUtil.downloadImageData()` - **入口点**：`POST /sys/common/uploadImgByHttp` ## 修复方案 1. **增加 URL 验证**：在发起 HTTP 请求前，对 `fileUrl` 参数进行严格的白名单校验，禁止访问内网 IP 和特殊协议。 2. **延迟文件类型检查**：将文件类型检查逻辑提前到下载之前，确保只有合法的 URL 才会被处理。 3. **限制请求范围**：在 `downloadImageData` 函数中增加 IP 限制、协议校验和 DNS 重绑定保护。 ## POC 代码 ```json { "fileUrl": "http://169.254.169.254/latest/meta-data/iam/security-credentials/", "filename": "test.jpg" } ``` ## 利用步骤 1. 获取一个具有上传文件权限的认证会话。 2. 发送 POST 请求到 `/sys/common/uploadImgByHttp`，携带包含恶意内部 URL 的 JSON 负载。 3. 服务器立即获取目标 URL，在安全验证之前，将响应（如敏感内部数据）写入可访问的上传文件，或通过响应行为揭示内部服务可用性。 ## 技术细节 - **直接执行（无存储）**：`CommonController.java:321-344` - 端点提取 `fileUrl` 并直接传递给下载工具。文件类型检查（`SsrFileTypeFilter.checkUploadFileType`）执行太晚，无法防止 SSRF。 - **工具转发**：`HttpFileToMultipartFileUtil.java:28-31` - `downloadImageData` 函数完全无边界地执行 HTTP 请求，没有 IP 限制、白名单或协议验证。 ## 验证笔记 - **阶段 1：用户输入** - 第 323 行：从用户 JSON 输入中提取 `fileUrl` - 在发起 HTTP 请求前没有 URL 验证 - **阶段 2：立即执行** - 第 330 行：立即调用 `HttpFileToMultipartFileUtil.HttpFileToMultipartFile()` - 第 330 行：`SsrFileTypeFilter.checkUploadFileType()` 在调用之后（太晚） - **阶段 3：Sink** - 第 37-38 行：创建 URL 并打开 `HttpURLConnection`，零 SSRF 保护 - 无 IP 阻止，无 URL 白名单，无 DNS 重绑定保护