Insecure URL Redirect

What Is Insecure URL Redirect?

An insecure URL redirect (open redirect) is what happens when a handler takes a destination URL from a request parameter and redirects to it without checking that the destination belongs to the application. The redirecting application gains nothing, but the attacker borrows its hostname to anchor a phishing flow: the victim signs in successfully on the real domain, the application returns a 302 to a lookalike URL, and the spoofed page asks the victim to log in again or hand over a 2FA code at the exact moment they trust the application most. This exercise puts you on both sides. As Bob, a phishing-kit operator, you find a login route on Westmark Industrial's procurement portal that respects a next query parameter. You replay the login with next=https://procurement-westmark.support/login-help and the server returns a 302 with the attacker URL in the Location header. As Alice, on the receiving end of an abuse-channel forward, you open the login handler, see res.redirect(req.query.next) with no validation, and apply the fix: a guard that rejects anything that is not a relative path. The exercise closes with quiz questions on why open redirects are dangerous despite not granting privilege on the redirecting application, why protocol-relative URLs need their own check, and what the victim sees on retry.

What You'll Learn in Insecure URL Redirect

• Recognize an open redirect as a phishing accelerator: the attacker borrows the legitimate hostname for trust anchoring
• Understand that protocol-relative URLs (<code>//host</code>) pass naive <code>startsWith("/")</code> checks and must be blocked separately
• Apply the relative-only validation (or hostname allow-list if external redirects are a real requirement)
• Distinguish open redirect from SSRF: the attacker is steering the browser, not the server, and the impact is phishing accuracy not internal-network access
• Audit every <code>res.redirect</code>, <code>location.href</code>, and <code>302 Location</code> response whose target is derived from request input

Insecure URL Redirect — Training Steps

1. Sizing up the target

   Today Bob is going after Fernloft accounts. It is a personal cloud service, so one account holds someone's whole life: photos, tax records, ID scans, backups. He has no one's password, so he plans to study how sign-in works from the inside. Fernloft lets anyone sign up, so he starts at the sign-up page.

2. Create a throwaway account

   First he needs an account of his own to test with, one that leads nowhere back to him. He fills in a throwaway address and password and creates it.

3. Read the login address

   Account made, Bob lands on the sign-in page. Before signing in, he reads the address bar. The login link carries a redirect_to value, right now /home , that decides where the app sends the browser after a successful sign-in.

4. Sign in and watch where it sends you

   Now Bob signs in with his throwaway account and watches where the app sends the browser once the password is accepted.

5. Craft the malicious link

   Bob rebuilds the same login link, but changes the redirect_to value to point at a page he owns instead of /home . He edits just that one value in the address bar to see whether the app will obey an off-site target the same way it obeyed /home .

6. Open redirect confirmed

   Bob signs in on the real Fernloft page with his throwaway account. The credentials are real, so the login succeeds, and then the app reads his crafted redirect_to value to decide where to send the browser.

7. Weaponize the link

   Bob wraps the crafted login link in a message anyone would act on: a session-expired warning. He pulls Fernloft addresses from a breach dump and blasts the same link to all of them. We follow one recipient, Alice.

8. A warning about your account

   Off the clock, Alice checks her personal inbox. There is a message from Fernloft: her session has expired and she needs to verify to keep her files. She uses Fernloft for everything, so losing access would be a real headache.

9. Click the link

   The link points at account.fernloft.com, Fernloft's real address, so Alice clicks it the way anyone would.

10. The real login page

    The link opens Fernloft's genuine login page. The address bar shows the real domain over https, everything looks right, and this is the moment Alice decides to trust the page.