CVE-2024-22243 - How Insecure Use of `UriComponentsBuilder` Opens Your App to Open Redirects and SSRF Attacks

A new threat has emerged for developers using Spring Web. This vulnerability, tracked as CVE-2024-22243, relates to how applications use UriComponentsBuilder to parse external URLs—often supplied by users via query parameters. If your app checks only the parsed *host* value to prevent malicious redirections or Server Side Request Forgery (SSRF), you could be vulnerable. This post explains how, shows real-life code examples, and offers links to original references and mitigations.

What’s the Problem with UriComponentsBuilder?

Applications often need to take a user-supplied URL and do something with it. Maybe you want to redirect the user, or fetch content from another server. Smart developers know this is risky, so they parse the URL and check its *host* against an allow-list before using it.

A popular way to parse URLs in Java/Spring apps is with UriComponentsBuilder

UriComponents uri = UriComponentsBuilder.fromUriString(userSuppliedUrl).build();
String host = uri.getHost();
// Perform allow-list checks on host...

It seems secure, right? You only check allowed hosts before redirecting or fetching. But there’s a hidden danger.

The Vulnerability: Insufficient Host Validation

Here’s the issue: UriComponentsBuilder is not always strict about how it parses URLs. Clever attackers can craft URLs that bypass your host check but actually redirect or SSRF to somewhere else when the URL is used.

For example, if your code only checks uri.getHost() and then uses userSuppliedUrl directly in a redirect or HTTP request, you could be tricked.

Links

- CVE-2024-22243 NVD Entry
- CWE-601: Open Redirect
- Spring Framework Issue

Suppose this code

@RestController
public class RedirectController {
    @GetMapping("/redirect")
    public ResponseEntity<Void> redirect(@RequestParam String url) {
        UriComponents components = UriComponentsBuilder.fromUriString(url).build();
        if (!"trusted.com".equals(components.getHost())) {
            throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "Untrusted redirect host");
        }
        // Redirect to user-supplied URL
        return ResponseEntity.status(HttpStatus.FOUND).location(URI.create(url)).build();
    }
}

Looks safe; it checks the host against "trusted.com". But attackers can smuggle URLs with embedded credentials (user info):

https://trusted.com@evil.com/

host = evil.com

- However, in older versions or if using the raw URL without building, the redirect might go to evil.com, not trusted.com.

Here's a proof-of-concept URL an attacker might use

https://trusted.com@attacker.com/

Most browsers and HTTP clients interpret this as "connect to attacker.com, with a username of trusted.com". But if your code only looks at the host in a naive way, it might see only "trusted.com" (from certain APIs or parsing routines), even though the real destination is "attacker.com". This is a classic open redirect or SSRF scenario.

Suppose there's a server-side fetch

String url = request.getParameter("target");
UriComponents uri = UriComponentsBuilder.fromUriString(url).build();
if (!SAFE_HOSTS.contains(uri.getHost())) {
    throw new SecurityException("Disallowed host!");
}
InputStream s = new URL(url).openStream();

If an attacker sends

http://safe.com@evil-internal-service.local/

The actual connection is made to evil-internal-service.local.

This could let the attacker poke at internal services or exfiltrate data—classic SSRF.

Why Is This Happening?

- UriComponentsBuilder does not normalize user info or reject tricky URLs the way you might expect.
- Validation must happen on the *exact* host that will be used by your HTTP client or redirection, after full URL parsing.

Always build/reconstruct the URL from parsed/safe components, not the original string

Double-check with your HTTP client:

Some low-level libraries interpret URLs differently. Always confirm you’re blocking abusive inputs.

More Info and References

- CVE-2024-22243 advisory from VMware
- Spring Framework Issue Tracker
- Mitre: CWE-601 - URL Redirection to Untrusted Site
- Mitre: CWE-918 - Server-Side Request Forgery (SSRF)

Conclusion

CVE-2024-22243 is a reminder: don’t trust URLs parsed just by host checks. Always reconstruct URLs from sanitized components, reject anything with embedded userinfo, and be suspicious of every piece of user input.

Keep your applications secure by staying up-to-date on vulnerabilities and carefully validating all externally supplied data!

Timeline

Published on: 02/23/2024 05:15:08 UTC
Last modified on: 02/23/2024 16:14:43 UTC