CSRF(跨站请求伪造)漏洞详解

什么是 CSRF?

CSRF(Cross-Site Request Forgery,跨站请求伪造)利用浏览器自动携带目标站点 Cookie 的特性,诱使用户在已登录状态下访问恶意页面,从而在用户不知情的情况下执行非本意的操作,例如:

  • 删除账户
  • 修改绑定邮箱
  • 更改个人资料(姓名、昵称等)
  • 修改接收通知的偏好设置
  • 更换或删除头像

Referer 头的发送规则

请求方向行为
HTTPS → HTTP安全降级,浏览器会直接删掉 Referer 头
HTTP → HTTPS安全升级,Referer 头正常发送

四种典型场景

场景1:无 Token,无 Referer 校验(最脆弱)

本地 localhost 构造表单,直接向目标域名提交 POST 请求。服务端未校验 Referer 和 CSRF‑Token,导致攻击成功。
防护措施:增加 Cookie/Session 校验,并生成 Token 验证来源。

场景1.png场景1.png

场景1.png场景1.png


场景2:仅校验 Referer,且可被绕过

服务端只依赖 Referer 头进行来源验证。攻击者可在请求包中手动修改 Referer 字段,伪造合法来源,从而绕过限制。

场景2.png场景2.png

场景2.png场景2.png


场景3:仅 CSRF‑Token 校验(主流标准防护)

服务端校验请求中携带的随机 CSRF‑Token,且不依赖 Referer。Token 与用户会话绑定,攻击者无法获取受害者页面内的合法 Token,因此无法构造有效请求,CSRF 攻击失败。


场景4:Referer 校验 + CSRF‑Token 双重防护(加强型)

同时校验 Referer 和 CSRF‑Token。即使 Referer 被伪造,由于缺少合法 Token,攻击依然无法成功,安全性最高。


CSRF 常见绕过手法

  • 删除 Token 参数或发送空白 Token
  • 将请求方法从 POST 改为 GET
  • 修改请求体的编码格式
  • 将 Token 替换为随机值或另一个用户的 Token
  • 在恶意页面中添加 <meta name="referrer" content="no-referrer"> 以禁用 Referer 发送
  • 修改 Token 中的单个字符,利用内容长度校验漏洞

DVWA 靶场实战测试

Low 模式 —— 无 Referer 校验

  1. 抓包观察,删除 Referer 头后重放请求,仍返回“修改成功”,说明不存在 Referer 校验。
  2. 使用 BurpSuite 的 Engagement tools -> Generate CSRF Poc 生成攻击 HTML。
  3. 将生成的 HTML 放置于恶意网站,诱导用户点击。由于同浏览器 Cookie 自动携带,密码被成功更改。
    DVWA-LOW.pngDVWA-LOW.png

    DVWA-LOW.pngDVWA-LOW.png

    DVWA-LOW-BURP.pngDVWA-LOW-BURP.png

    DVWA-LOW-BURP.pngDVWA-LOW-BURP.png

核心原理:浏览器会自动将目标网站的 Cookie 附加到任何发往该网站的请求中,无论请求源自哪个页面。

攻击者视角

  • 受害者在浏览器中登录网站 A(如 DVWA),Cookie 被保存。
  • 攻击者构造恶意网页 B,诱使受害者访问。
  • 网页 B 中的表单或 <img> 标签自动向网站 A 发起请求。
  • 请求携带网站 A 的合法 Cookie,服务器无法区分该操作是用户在 A 页面主动触发,还是被 B 网页诱导,从而执行恶意操作(改密、转账等)。

Medium 模式 —— Referer 校验(可被绕过)

抓包删除 Referer 后重放,未出现“修改成功”提示,说明服务端校验了 Referer。

DVWA-Medium.pngDVWA-Medium.png

DVWA-Medium.pngDVWA-Medium.png

查看服务端核心代码发现,仅判断 Referer 中是否包含指定主机名(如 192.168.1.1)。因此,攻击者可将恶意页面文件名改为 靶机IP:8080.html 来绕过。

注:Windows 系统不支持以 :8080 命名文件,因此实际测试时通过 Burp 修改 Host 或文件名模拟效果。
访问 http://localhost:90/csrf2.html 并改包为 http://47.243.128.242:8080.html 可成功。

实际攻击中,攻击者会使用 Linux 主机部署恶意页面,并通过诱导受害者访问触发。

DVWA-Medium.pngDVWA-Medium.png


High 模式 —— Token 校验(需同源 XSS 配合)

在 High 模式下,代码加入了 CSRF‑Token 验证,普通 Referer 伪造失效。

DVWA-HIGH.pngDVWA-HIGH.png

DVWA-HIGH.pngDVWA-HIGH.png

由于 Token 是在页面加载时生成的,攻击者必须借助同源 XSS 漏洞,在 DVWA 的 CSRF 页面中注入恶意脚本,诱导受害者点击,才能成功利用。

演示构造 payload 并注入到 dvwa_csrf 页面,可成功执行攻击。

DVWA-HIGH.pngDVWA-HIGH.png


总结

防护强度措施安全性
极弱无校验极易被攻击
仅 Referer可被伪造绕过
仅 CSRF‑Token主流有效,需保证 Token 随机且绑定会话
Referer + Token 双重校验最安全,但仍需防范 XSS 泄露 Token

核心防御建议:始终使用 CSRF‑Token,并绑定用户会话;避免仅依赖 Referer;敏感操作采用二次验证(如验证码、重新认证)。