Insecure URL Redirect

What Is Insecure URL Redirect?

An open redirect sends the browser to a destination taken from the request without asking whether the destination is yours. The application gains nothing from the bug; the attacker gains your hostname, at the moment the user trusts it most. You'll replay a login that honours a next parameter and watch a 302 carry the victim to a lookalike sign-in page. Then you fix res.redirect(req.query.next) with relative paths only or a hostname allow-list, and see why startsWith('/') lets a protocol-relative //host straight past.

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.