Lion Cipher Lab

Exploit and fix an open redirect (in your own lab)

• AppSec / DevSecOps
• Intermediate
• ~45 min
• Free · no account required

Why it matters

An open redirect is one of the most underestimated web bugs, because on its own it looks harmless: the app just sends the browser somewhere else. The danger is WHERE. Many sites carry a 'come back here after you finish' value in the URL — a ?next=, ?url=, ?returnTo=, or ?redirect= parameter used after login, logout, or a payment. If the server copies that value into the redirect without checking it, an ATTACKER gets to choose the destination. Now they craft a link that begins with your real, trusted domain — the part a cautious user actually checks — but whose parameter points at a site they…

What you'll learn

• defining an OPEN REDIRECT (CWE-601, 'Unvalidated Redirects and Forwards'): a server takes a user-controlled value and uses it as the target of an HTTP redirect without checking it, so an attacker picks where the victim lands
• reading the mechanics of a redirect: a 3xx status (e.g. 302 Found) plus a Location response header naming the URL the browser should go to next
• building a tiny vulnerable Node app whose /login?next=... endpoint copies the 'next' query parameter verbatim into the Location header
• crafting an exploit link whose visible host is your trusted site but which bounces the victim to an attacker-controlled destination — a phishing / credential-harvest lure
• explaining how an open redirect is CHAINED into OAuth/OIDC redirect_uri code-or-token theft when the authorization server trusts a host that also hosts a redirector
• seeing WHY naive fixes fail: a blocklist misses hosts you did not enumerate; a prefix check like startsWith('http://localhost') passes http://localhost.evil.example; and a 'must start with /' check passes //evil.example and the backslash variant browsers normalise to it
• fixing it three ways and comparing them: an exact ALLOWLIST of permitted destinations, a strict RELATIVE-PATH-ONLY validator, and (best) INDIRECTION — never accept a URL from the user; map a short server-side key to a known path
• internalising the rule of thumb: if you can avoid redirecting to user input at all, do; otherwise validate against an allowlist of full values, never against a pattern you hope covers every bad string

Steps in this lab

1. The vocabulary: a redirect, the Location header, and what 'open' means
2. Set up: confirm Node, make a folder
3. Build the VULNERABLE app (it redirects to whatever 'next' says)
4. Exploit it (1): the phishing bounce — a trusted-looking link that lands on evil.example
5. Exploit it (2): the OAuth redirect_uri chain — how a redirect becomes token theft
6. Why the tempting fixes fail — feel the bypasses yourself
7. Fix it three ways — allowlist, relative-only, and (best) indirection
8. What you did — and the reflex to keep

Open the full interactive lab →