seanpesce/cve-2024-22243Example exploitable scenarios for CVE-2024-22243 affecting the Spring framework (open redirect & SSRF).
Author: Sean Pesce
This project contains an example web application that demonstrates exploitable scenarios for CVE-2024-22243, a URL-parsing vulnerability in the Java Spring Framework (official disclosure here).
Affected versions of Spring parse the "userinfo" segment of URLs in a unique way, potentially resulting in the extraction of a host name segment that differs from many other common libraries.
The abnormal behavior is due to the following regular expression ("regex") in the
UriComponentsBuilder
class (introduced by
this commit
in 2014):
private static final String USERINFO_PATTERN = "([^@\\[/?#]*)";
This regex does not permit the "left bracket" character ([) in the user info segment. However,
Spring appears to be an outlier with this behavior, so calling getHost() on a
UriComponents
object constructed using UriComponentsBuilder.fromUriString
or
UriComponentsBuilder.fromHttpUrl
can result in unexpected behavior. The
RestTemplate,
RestClient,
and WebClient
classes are also affected due to their internal use of UriComponentsBuilder; therefore,
implementations can be rendered vulnerable even without direct use of UriComponentsBuilder.
For specially-crafted inputs, Spring will return a host name value that differs from all of the following:
java.net.URI (reportedly only for specific Java versions; other versions raise a URISyntaxException)java.net.URLcurlandroid.net.Uriokhttp3.HttpUrlurllib.parse.urlparse(Note that this list is non-exhaustive.)
This behavior potentially renders Spring-based web applications vulnerable to open redirect and server-side request forgery (SSRF) if the dependent implementation uses trusted host names for authorization or other security-relevant mechanisms.
The example web application contains two vulnerable endpoints.
The first endpoint, /redirect, shows how Spring's abnormal URL parsing can result in an open
redirect. It can be exploited using a URL such as the following:
https://127.0.0.1[@evil.com
The second endpoint, /health-check, demonstrates how a mismatch in URL parsing between Spring and
the Java standard library URL class can result in server-side request forgery (SSRF). It can be
exploited using a URL such as the following:
https://evil.com[@127.0.0.1
To build this project with Maven, simply run the following command (tested with OpenJDK 17):
mvn clean package
Then, start the web app with a command such as the following:
java -jar seanpesce-cve-2024-22243.jar 9999
The web app will be accessible at http://127.0.0.1:9999/.
To build the docker image, run the following command:
docker build -t seanpesce-cve-2024-22243:latest .
Then, start the web app with a command such as the following:
docker run -i -e PORT=9999 -p 9999:9999 seanpesce-cve-2024-22243:latest
The web app will be accessible at http://127.0.0.1:9999/ on the Docker host.
This repository also contains semgrep rules to assist in scanning for
potentially-vulnerable code paths. spring-cve-2024-22243_loose.yaml
performs naive scans for any use of the vulnerable APIs; as such, it will often return a large
number of false positives. spring-cve-2024-22243_strict.yaml
attempts to use stricter logic and taint analysis; however, this has not been
thoroughly tested and has high potential to miss some vulnerable implementations (especially when not using
Semgrep Pro, which is required for cross-file analysis).