Lion Cipher Lab
Take over an account through OAuth flaws: steal the code with a loose redirect_uri, then forge a login with no state — and fix both
- AppSec / DevSecOps
- Advanced
- ~90 min
- Free · no account required
Why it matters
"Log in with Google/GitHub/Apple" is now the front door to a huge share of the web, and OAuth 2.0 is the protocol behind it. It is also one of the easiest things to wire up WRONG, because the security lives in two small, boring details that a working demo does not need: the authorization server must validate the redirect_uri EXACTLY, and the client must tie the round-trip to the user's own browser with an unguessable, single-use `state`. Miss the first and an attacker can make your authorization server hand a victim's authorization code to a URL the attacker controls — one code exchange…
What you'll learn
- reading an OAuth 2.0 authorization-code flow end to end (authorize -> code -> token)
- exploiting flawed redirect_uri validation to exfiltrate an authorization code
- exploiting a missing/unbound state parameter to forge an OAuth login (CSRF)
- fixing both with exact-match redirect URIs, a one-time bound state, and PKCE
- reasoning about which OAuth party owns which control (client vs. authorization server)
Steps in this lab
- The two details that hold OAuth together
- Build the lab: a tiny authorization server and a client, deliberately flawed
- Sanity check: the honest flow works
- Attack 1 — steal the code with a prefix-matched redirect_uri
- Attack 2 — forge a login with no state (login CSRF)
- Fix both — exact match, a bound one-time state, and PKCE
- When to reach for this — and who owns which control