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

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

1. The Morning That Drove the Tester Crazy

It happened on a sunny Monday when our tester, Xiaomei, 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 Problem Reproduction: User Login Redirects to Gambling

We reproduced the problem scenario:

1. User visits <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. After 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

2. 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);

3. 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;
}

4. Five 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

5. 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 fiercer 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 regular penetration tests conducted?

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

Bonus: How to Prepare for Interviews

My interview skills column has been updated with 38 articles, each classic, mainly teaching how to answer comprehensively. Job seekers can purchase it for a one-time fee of 29.9 (scan the QR code below to buy, and you can view it later in the new program).

My code pitfalls column is quite good. I usually summarize code pitfalls after work and on weekends, putting in a lot of effort, all from my work experiences or advice from seniors. It’s very practical. It has been updated to 93 articles, and I just updated one about the pitfall of setting database fields to text, which many may have encountered~~