# Vulnerability Summary: Direct SSRF Vulnerability in JeecgBoot ## Vulnerability Overview A direct Server-Side Request Forgery (SSRF) vulnerability exists in the `/sys/common/uploadImgByHttp` interface of `jeecgboot_jeecgBoot`. This vulnerability allows attackers to craft malicious requests that cause the server to initiate HTTP requests to arbitrary external or internal resources, thereby enabling the retrieval of sensitive information or the probing of internal network services. ## Impact Scope - **Affected Versions**: <= 3.9.1 - **Affected Components**: - `CommonController.java` (Lines 321-344) - `HttpFileToMultipartFileUtil.java` (Lines 28-66) - **Affected Functions/Methods**: - `CommonController.uploadImgByHttp()` - `HttpFileToMultipartFileUtil.HttpFileToMultipartFile()` - `HttpFileToMultipartFileUtil.downloadImageData()` - **Entry Point**: `POST /sys/common/uploadImgByHttp` ## Remediation 1. **Implement URL Validation**: Perform strict whitelist validation on the `fileUrl` parameter before initiating HTTP requests, prohibiting access to internal IP addresses and special protocols. 2. **Advance File Type Checking**: Move the file type checking logic to before the download process, ensuring that only legitimate URLs are processed. 3. **Restrict Request Scope**: Add IP restrictions, protocol validation, and DNS rebinding protection within the `downloadImageData` function. ## POC Code ```json { "fileUrl": "http://169.254.169.254/latest/meta-data/iam/security-credentials/", "filename": "test.jpg" } ``` ## Exploitation Steps 1. Obtain an authenticated session with file upload permissions. 2. Send a POST request to `/sys/common/uploadImgByHttp` with a JSON payload containing a malicious internal URL. 3. The server immediately fetches the target URL. Before security verification is complete, the response (such as sensitive internal data) is written to an accessible upload file, or the availability of internal services is revealed through response behavior. ## Technical Details - **Direct Execution (Non-persistent)**: `CommonController.java:321-344` - The endpoint extracts `fileUrl` and passes it directly to the download utility. The file type check (`SsrFileTypeFilter.checkUploadFileType`) is executed too late to prevent SSRF. - **Tool Forwarding**: `HttpFileToMultipartFileUtil.java:28-31` - The `downloadImageData` function executes HTTP requests without any boundary checks, lacking IP restrictions, whitelists, or protocol validation. ## Verification Notes - **Stage 1: User Input** - Line 323: Extracts `fileUrl` from user JSON input. - No URL validation is performed before initiating the HTTP request. - **Stage 2: Immediate Execution** - Line 330: Immediately calls `HttpFileToMultipartFileUtil.HttpFileToMultipartFile()`. - Line 330: `SsrFileTypeFilter.checkUploadFileType()` is called afterwards (too late). - **Stage 3: Sink** - Lines 37-38: Creates a URL and opens `HttpURLConnection` with zero SSRF protection. - No IP blocking, no URL whitelist, and no DNS rebinding protection.