CVE-2024-22259 - UriComponentsBuilder in Spring Framework - Open Redirect & SSRF Vulnerability Explained

On May 15, 2024, a new security vulnerability was published, affecting applications using the popular Spring Framework: CVE-2024-22259. This vulnerability can expose your applications to open redirect and Server-Side Request Forgery (SSRF) attacks if you are using UriComponentsBuilder to parse and validate externally provided URLs.

If you build or maintain Java web applications with Spring and handle input URLs, this issue concerns you.

Let’s dig in to understand what’s going on, look at example code, see how the attack works, and learn how to fix your applications.

1. What’s CVE-2024-22259?

CVE-2024-22259 is a security vulnerability where applications that use Spring Framework's UriComponentsBuilder to parse incoming URLs from users (query parameters, HTTP bodies, etc.) and perform validation on the parsed host can be tricked. This means you can accidentally approve a malicious URL, leading to serious security problems. CWEs 601 (Open Redirect) and SSRF (Server-Side Request Forgery) can both happen.

This bug is similar to CVE-2024-22243, but it affects different types of input.

2. How Does the Attack Work?

Some developers accept a URL from the user, parse it, check “does the host match something safe?”, and then use it for a redirect or proxy request.

But: the way UriComponentsBuilder parses URLs lets attackers "confuse" your code, so validation passes, but the real URL used is dangerous.

User supplies a URL in a query or POST field:

/example?url=https://trusted.com%40evil.com/path

Application parses the URL and checks if the host is trusted.com.

(But due to URL syntax quirks, https://trusted.com@evil.com/path's actual host is evil.com.)

3. Application accepts the malicious URL, thinking it’s safe, and does a redirect or SSRF as a result.

Broken Example (Vulnerable Code)

import org.springframework.web.util.UriComponentsBuilder;
import org.springframework.web.bind.annotation.*;

@RestController
public class RedirectController {
    @GetMapping("/go")
    public String redirect(@RequestParam String url) {
        // PARSE THE USER URL
        var uri = UriComponentsBuilder.fromUriString(url).build().toUri();

        // VALIDATE HOST
        if (!"trusted.com".equals(uri.getHost())) {
            throw new IllegalArgumentException("Not allowed");
        }

        // PERFORM REDIRECT
        return "redirect:" + uri.toString();
    }
}

A user submits

/go?url=https://trusted.com%40evil.com/path

4. Why Is This Dangerous?

- Open Redirect: Attackers can craft links that look legitimate (trusted.com) but send users elsewhere (phishing, malware).
- SSRF: If you use the user's input to make server-side requests, attackers can trick your server into accessing internal services, cloud metadata, etc.

> Tip: This is especially critical for applications running on cloud services! SSRF often damages critical systems.

5. Original References

- MITRE CWE-601: Open Redirect
- Spring CVE-2024-22243 (similar issue)
- Spring CVE Page for CVE-2024-22259

Option 1: Don’t Trust fromUriString() Host Value

Don’t parse and validate user input URLs with UriComponentsBuilder and then trust the host field. Instead:

Before using the URL, ensure it cannot include usernames or other tricky parts

public boolean isSafeUrl(String inputUrl, String allowedHost) {
    try {
        URI uri = new URI(inputUrl);
        // Reject if user-info is present (don't allow username/password)
        if (uri.getUserInfo() != null) {
            return false;
        }
        // Check host
        String host = uri.getHost();
        if (host == null || !host.equals(allowedHost)) {
            return false;
        }
        return true;
    } catch (URISyntaxException e) {
        return false;
    }
}

Update Spring Framework as patches are released:

Spring Framework Releases

Follow Official Guidance:

- See Spring's CVE-2024-22259 Advisory for more remediation strategies.

8. Conclusion

CVE-2024-22259 is another reminder that parsing, validating, and using user-provided URLs is trickier than it seems. Don’t assume libraries always do what you expect!
Carefully validate all parts of a URL, especially if your app makes redirects or server-side requests on users’ behalf.

Timeline

Published on: 03/16/2024 05:15:20 UTC
Last modified on: 03/17/2024 22:38:29 UTC