JeecgBoot Stored Cross-Site Scripting Vulnerability in SVG File Handler

A stored cross-site scripting vulnerability has been identified in JeecgBoot versions prior to 3.9.1. The issue arises in the SVG file handler, specifically within a function of the CommonController.java file. This vulnerability allows authenticated users to upload SVG files containing JavaScript, which is then executed in the context of the user's browser when the file is accessed. The Spring resource handler serves the files with the correct MIME type, enabling the execution of the embedded scripts.

Impact

Exploitation of this vulnerability allows for stored cross-site scripting, where uploaded SVG files execute embedded JavaScript in the browser of any user who accesses the file. This could lead to session hijacking by stealing JWT tokens from localStorage or cookies, and could also be used for phishing attacks by rendering arbitrary HTML content within the application's origin.

Reproduction

To reproduce this vulnerability, first create a malicious SVG file named 'xss.svg' without the XML declaration to bypass the file type filter. This file should contain a script tag with JavaScript code, such as an alert. After creating the file, authenticate with the application to obtain a token. Then, upload the SVG file through the '/sys/common/upload' endpoint, using the token in the request headers. Once uploaded, the file can be accessed via the Spring resource handler, which serves it inline with the 'image/svg+xml' content type. This will trigger the execution of the JavaScript in the file, demonstrating the cross-site scripting vulnerability.

Remediation

To address this vulnerability, JeecgBoot should implement several measures: First, add a 'Content-Disposition: attachment' header for all user-uploaded files served via the Spring resource handler to prevent inline execution of scripts. Second, introduce a 'Content-Security-Policy' header to block inline scripts. Third, sanitize SVG files on upload by removing script tags and event handlers. Fourth, correct the file type filter to accurately detect dangerous file signatures, especially for XML-based formats. Finally, consider serving uploaded files from a separate domain or subdomain to mitigate the impact of any potential cross-site scripting.