The Pitfalls of Login Functionality: How an HTTP Redirection Attack Almost Cost My Company (with Solutions)

Follow our public account for Java insightsTimely delivery

Last week, I made a blunder at the company—my own login module almost became an accomplice to a phishing site. Today, I want to share this thrilling process and how to avoid the “invisible bomb” of HTTP redirection attacks.

The Morning That Drove the Tester Crazy

It happened on a sunny Monday when our tester, Xiao Mei, suddenly burst into our development team: “Your login interface has been hijacked! Users are redirected to a gambling site right after logging in!”

My immediate reaction was: “Absolutely impossible! I clearly implemented URL whitelist validation…”

1.1 Reproducing the Problem: User Login Redirects to Gambling

We reproduced the problem scenario:

1. User accesses <span>www.our-app.com/login?redirect=/profile</span>
2. Enters correct username and password
3. Page redirects to… the first online casino in Macau (!)

I stared at the browser’s Network panel and found a 302 status code in the request:

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

Key Issue Analysis: Initially, we thought the user was accessing the normal path<span>/profile</span>, but the actual attack occurred when the redirect parameter was cleverly disguised:

How Did the Attacker Operate?

1. Construct a phishing link:<span>www.our-app.com/login?redirect=%2F%2Fmalicious-site.com</span> (%2F is the URL encoding for “/”)

2. When the server receives the parameter:

   // Not decoded, directly concatenated
   String redirect = request.getParameter("redirect"); // gets "//malicious-site.com"
   response.sendRedirect("https://our-app.com" + redirect);
   

   The actual redirect address becomes:<span>https://our-app.com//malicious-site.com</span> which the browser automatically resolves to:<span>https://malicious-site.com</span>

Why Wasn’t It Detected During Testing?

In our testing environment, we used simple paths like<span>/profile</span> and never anticipated these sneaky operations:

• <span>// External site</span> path concatenation attack
• <span>@malicious domain</span> special resolution
• <span>% encoding</span> bypass techniques

Dissecting the “Redirection Cockroach”

2.1 How Redirection Works

It’s like a delivery person delivering the wrong package:

1. User says: “Deliver this to address A” (with redirect parameter)
2. Server says: “Okay, the next package goes to address B” (returns 302+Location)
3. The delivery person (browser) blindly follows the instructions

2.2 What Does the Vulnerable Code Look Like?

This is the dangerous code I initially wrote (Java example):

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

How I Filled the Pit

3.1 First Layer of Defense: Whitelist Validation

List<String> allowedPaths = Arrays.asList("/profile", "/dashboard");

if(!allowedPaths.contains(redirectParam)){
    redirectParam = "/default"; // Redirect to a safe page
}

3.2 Second Layer of Defense: Signature Verification

Add a “security code” to the redirect parameter:

# Generate signature
sign = hashlib.sha256(redirect_path + SECRET_KEY).hexdigest()
safe_url = f"{redirect_path}?sign={sign}"

# During 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 of Defense: Relative Path Conversion

Convert absolute URLs to relative paths:

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

Four Key Points to Prevent Redirection Attacks

1. Never trust client parameters: Treat the redirect parameter as a suspect
2. Disable open redirection: Just like not giving strangers a key to your home
3. Set redirect delays: Add a second confirmation before important operations
4. Log suspicious activities: Monitor abnormal redirects
5. Conduct regular security scans: Use automated tools to check for vulnerabilities

Lessons Learned

This incident made me realize: Security is not a feature, but a baseline. Now, every time I handle redirection, I recite three times:

“User parameters are more ferocious than tigers, unverified is gambling, whitelist plus signature lock, the security red line cannot be crossed.”

Finally, here’s a self-check checklist for everyone:

• [ ] Are all redirect parameters strictly validated?

• [ ] Are there any bare redirects (direct URL concatenation)?

• [ ] Is a CSP security policy configured?

• [ ] Are unnecessary HTTP methods disabled?

• [ ] Are penetration tests conducted regularly?

I hope this article helps everyone! If you encounter similar issues, feel free to discuss in the comments section.

Previous Recommendations



1. Spring 6.0+Boot 3.0: New development techniques for second-level startup and ten-thousand-level concurrency
2. A comprehensive guide to mastering MyBatis-Plus advanced features
3. MyBatis-Plus development accelerator: mybatis-plus-generator-ui
4. Meituan's first interview: Why use HTTP for remote calls in Spring Cloud instead of RPC?
5. Why do Java and C progress slowly at the tool level compared to popular Rust and Go?
6. Major companies ban! MyBatis standard logging output has significant flaws? A hands-on guide to customizing high-performance logging solutions!



Share

Collect

Like

View