Understanding and Preventing HTTP Redirect Attacks in Java Applications

Last week the author discovered that a login module they wrote almost became an accomplice to a phishing site. The article recounts the incident and explains how to avoid HTTP redirect attacks, which act as an "invisible bomb".

1. The Morning That Made the Tester Furious

A tester reported that the login interface was hijacked: after users clicked login they were redirected to a gambling website.

The author initially believed the URL was safe, but the redirect parameter was maliciously crafted.

1.1 Problem Reproduction: User Login Leads to Gambling Site

User accesses www.our-app.com/login?redirect=/profile

Enters correct credentials

Page redirects to a Macau online casino

The browser’s Network panel showed a 302 response:

HTTP/1.1 302 Found
Location: https://malicious-site.com?steal_cookie=123abc

Key Issue Analysis : The server assumed the user was requesting /profile , but the redirect parameter was disguised to point to an external domain.

How the Attacker Operates

Construct a phishing link: www.our-app.com/login?redirect=%2F%2Fmalicious-site.com (where %2F is “/”)

The server receives the parameter and concatenates it directly:

// Undecoded concatenation
String redirect = request.getParameter("redirect"); // gets "//malicious-site.com"
response.sendRedirect("https://our-app.com" + redirect);

The resulting URL becomes https://our-app.com//malicious-site.com , which the browser normalizes to https://malicious-site.com .

2. Dissecting the "Redirect Cockroach"

2.1 How Redirect Works

It is analogous to a courier delivering a wrong package:

User says “send to address A” (provides redirect parameter)

Server replies “okay, I’ll send to address B” (returns 302 + Location)

Browser (the courier) follows blindly.

2.2 Vulnerable Code Example (Java)

// Dangerous demo! Do not copy!
String redirectUrl = request.getParameter("redirect");
response.sendRedirect(redirectUrl);

3. How the Author Fixed the Issue

3.1 First Layer: Whitelist Validation

List<String> allowedPaths = Arrays.asList("/profile", "/dashboard");
if (!allowedPaths.contains(redirectParam)) {
    redirectParam = "/default"; // redirect to a safe page
}

3.2 Second Layer: Signature Verification

# Generate signature
sign = hashlib.sha256(redirect_path + SECRET_KEY).hexdigest()
safe_url = f"{redirect_path}?sign={sign}"
# Verification
client_sign = request.GET.get('sign')
server_sign = hashlib.sha256(redirect_path + SECRET_KEY).hexdigest()
if client_sign != server_sign:
    abort(403)

3.3 Third Layer: Relative Path Conversion

// Convert https://www.our-app.com/profile to /profile
function sanitizeRedirect(url) {
    return new URL(url).pathname;
}

4. Five Key Points to Prevent Redirect Attacks

Never trust client‑side parameters : treat redirect as suspicious.

Disable open redirects : do not expose unrestricted redirect endpoints.

Introduce redirect delay or confirmation : require user consent for critical navigation.

Log suspicious redirects : monitor and alert on abnormal redirect patterns.

Regular security scanning : use automated tools to detect open‑redirect vulnerabilities.

5. Lessons Learned

Security is a baseline, not an optional feature. The author now checks every redirect three times and follows a checklist:

All redirect parameters are validated?

No raw URL concatenations?

CSP policies configured?

Unnecessary HTTP methods disabled?

Periodic penetration testing performed?

Hope this article helps others avoid similar pitfalls.