CVE-2024-22243

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).

Vulnerability

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:

• Modern web browsers, including:
  • Chrome (and other Chromium-based browsers)
  • Firefox
  • Safari
• java.net.URI (reportedly only for specific Java versions; other versions raise a URISyntaxException)
• java.net.URL
• curl
• android.net.Uri
• okhttp3.HttpUrl
• (Python 3) urllib.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.

Examples

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

Usage

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/.

Docker

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.

Semgrep

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).

Other Resources

• NIST database entry
• Git commit that fixed the vulnerability
• Vulnerable implementation demo: Vulnerable OAuth flow with open redirect by threedr3am of SecCoder Security Lab
• CVE-2024-22259, a second URL-parsing vulnerability that was discovered in the fallout of CVE-2024-22243
• CVE-2024-22262, a third URL-parsing vulnerability that was discovered in the fallout of the first two findings