一、学习CSRF 漏洞
（一）CSRF 是什么
全称：Cross-Site Request Forgery，跨站请求伪造。
核心：
用户已经登录目标网站（Cookie 有效、未过期）；
目标网站没有校验请求来源 / 身份凭证；
存在能执行敏感操作的无 Token GET/POST 请求；
用户点开攻击者构造的恶意链接 / 页面。
（二）漏洞原理拆解
浏览器机制：访问任意网站时，会自动带上该域名下所有有效 Cookie。流程：
用户登录 bank.com，浏览器保存登录 Cookie；
攻击者制作恶意页面 hack.html，内含自动转账请求；
用户点开恶意页面；
浏览器发起请求 bank.com/transfer?to=攻击者&money=1000，自动带上银行登录 Cookie；
银行服务端只校验 Cookie，判断是合法用户，执行转账。
CSRF 只能发请求，不能获取响应内容，所以无法窃取页面数据。
（三）两种攻击 payload
1. GET 型 CSRF（最简单）
http://bank.com/transfer?account=attacker&amount=1000
恶意构造：
<a href="http://bank.com/transfer?account=attacker&amount=1000">免费领红包</a>
<img src="http://bank.com/transfer?account=attacker&amount=1000" width="0" height="0">
用户打开页面，图片自动加载，请求自动发送。
2. POST 型 CSRF（表单自动提交）
后台敏感操作是 POST 提交，不能用 img，用隐藏表单 + 自动 JS 提交：
<!DOCTYPE html>
<html>
<body>
<form action="http://bank.com/transfer" method="POST" id="csrf_form">
<input type="hidden" name="account" value="attacker">
<input type="hidden" name="amount" value="1000">
</form>
<script>
// 页面加载自动提交表单
document.getElementById("csrf_form").submit();
</script>
</body>
</html>
用户访问页面无需点击，表单自动 POST 发包。
（四）CSRF 漏洞挖掘思路（实战找漏洞）
1. 优先寻找敏感操作接口
- 转账、充值、修改密码、修改手机号、绑定邮箱、删除账号、发布文章、管理员后台操作
2. 判断是否存在 CSRF
测试步骤
登录目标站点，抓敏感操作请求（Burp Suite）；
删除请求里的 Token / 校验字段（csrf_token、token、_token 等）；
重放请求，看是否仍能成功执行；
若删除 Token 依然生效 → 存在 CSRF；
再校验 Referer / Origin 头：修改 Referer 为其他域名，请求成功则双重漏洞。
两种常见校验绕过场景
无任何校验：直接存在 CSRF；
仅校验 Referer 头，可绕过
-
后端判断逻辑：if(referer contains "xxx.com")
-
绕过方式：攻击者域名包含目标域名，如 xxx.com.hack.com
空 Referer 放行：页面用 img、iframe 发送请求时 Referer 为空，后台不拦截即可利用。
（五）工具实操：Burp Suite CSRF 测试
（六）靶场练习推荐（由浅入深）
- 安全级别 Low/Medium/High 逐层学习绕过方式
- CSRF 完整交互实验
- CSRF 全系列靶机：基础、Token 绕过、Referer 绕过、JSON CSRF、SameSite Cookie 漏洞
- GET/POST 两种 CSRF 实例
DVWA CSRF 简单解析
- Low：无任何防护，直接 payload 利用；
- Medium：校验 Referer，检测是否包含主机名；
- High：使用 CSRF Token，每次请求随机，无法简单构造 payload；
- Impossible：增加旧密码二次验证，彻底杜绝。
（七）高级拓展：JSON CSRF / CORS 配合 CSRF
1. JSON 表单无 Token
接口接收 Content-Type: application/json POST 数据，无 CSRF Token，可通过表单提交 json 触发。
2. CORS 配置不当辅助危害
服务端配置 Access-Control-Allow-Origin: *，配合 CSRF 可读取接口响应，扩大危害。
（八）完整防御方案
方案 1：CSRF Token（最主流、最安全）
方案 2：SameSite Cookie 属性（浏览器层防护）
Set-Cookie 增加参数：
Set-Cookie: sessionid=xxx; SameSite=Strict; Secure; HttpOnly
- SameSite=Strict：跨站请求完全不携带 Cookie；
- SameSite=Lax：GET 跨站不带 Cookie，基础防御；配合 HTTPS + Secure，只有 HTTPS 才会发送 Cookie。
方案 3：校验 Origin / Referer 请求头
后端校验请求来源域名，只信任本站域名；缺点：可被部分场景绕过，不能单独作为唯一防御，需搭配 Token。
方案 4：敏感操作增加二次验证
修改密码、转账、绑定手机必须输入短信验证码、原密码，就算 CSRF 发起请求，无验证码无法执行。
禁止使用的无效防御
仅使用 Referer 校验、仅前端 JS 校验 Token（前端校验可被绕过）。
