Overview
Spring Framework is a comprehensive Java framework for building enterprise-level applications. It provides a powerful, flexible programming model that simplifies the development of web applications by allowing you to use Java as your primary language while offering a variety of tools to manage application configuration, data access, and security.
An Open Redirect vulnerability (CVE-2024-22243) has been identified in Spring, which allows attackers to bypass URL validation and lead to an Open Redirect or SSRF attack. This vulnerability arises when using UriComponentsBuilder to parse externally provided URLs in order to validate their host.
Per CWE: An open redirect vulnerability is when a redirect (which is a common and useful function) sends the user to a malicious site. At this site, user credentials may be stolen, which can aid in a phishing scam. Additionally, systems may be compromised when a redirect is combined with a Cross Site-Scripting (XSS) exploit.
This issue affects multiple versions of Spring Framework.
Details
Module Info
- Product: Spring Framework
- Affected packages: spring-web
- Affected versions: >=4.3.0 <=4.3.30, >=5.3.0 <5.3.32, >=6.0.0 <6.0.17, >=6.1.0 <6.1.4
- GitHub repository:
https://github.com/spring-projects/spring-framework/tree/main/spring-web - Published package: https://mvnrepository.com/artifact/org.springframework/spring-web
- Package manager: Maven
- Fixed in: NES for Spring Framework v4.3.32 and v5.3.44
Vulnerability Info
This high-severity vulnerability is found in the spring-web.jar module of the Spring Framework. It has a low attack complexity and requires no privileges to exploit but does require user interaction, such as clicking a crafted URL.
When the UriComponentsBuilder class is used to parse externally provided URLs, an HTTP parameter may contain a URL value that redirects the user to an unexpected site.
Moreover, developers using UriComponentsBuilder do not often validate the result given by the class. If host validation does occur but is too lenient or doesn't account for edge cases, malicious inputs can exploit this gap. Thus, the vulnerability is due to a combination of a flaw in the class and the lack of rigorous validation at the application level.
Steps To Reproduce
To reproduce this vulnerability in a controlled environment, you would need a Spring application running an affected version and an available end point.
- Set up a vulnerable Spring application:some text
- Create a simple Spring Boot application using a vulnerable Spring Framework version, such as 6.1.3
- Add additional files to fill out the project. Launch the app.
- The core of the exploit would involve crafting a URL that, when parsed by UriComponentsBuilder, results in an open redirect. Something like:
http://your-vulnerable-app.com/redirect?url=https://attacker.com
Here, your-vulnerable-app.com would be your Spring application and attacker.com would be where you want to redirect users.
Create a class that establishes an end-point in the application, such as the one defined below:
import org.springframework.web.util.UriComponentsBuilder;
@RestController
public class RedirectController {
private final static List<String> ALLOWED_HOSTS = List.of("trusted.com");
@GetMapping("/redirect")
public String redirect(@RequestParam String url) {
// Vulnerable code:
UriComponents uriComponents = UriComponentsBuilder.fromUriString(uri).build();
String host = uriComponents.getHost();
if (!ALLOWED_HOSTS.contains(host)) {
return "Denied: " + targetUrl;
}
// This would typically be where you might redirect or use this URL
return "Redirecting to: " + targetUrl;
}
}
4. Send the following request to the end-point in the application using a tool:
http://localhost/redirect?url=https://trusted.com%5B%40google.com
5. If the application is vulnerable, then it will display “Redirecting to: google.com”.
Credits
- Sean Pesce
Mitigation
Spring Framework 4.3.x is no longer community-supported. The community support version will not receive any updates to address this issue. For more information, see here.
Users of the affected components should apply one of the following mitigations:
- Upgrade to a corrected version.
- Leverage a commercial support partner like HeroDevs for post-EOL security support.