CSRF安全攻防：Referer 校验与 Token 防护详解

本文系作者在网络安全渗透测试领域的学习与实践总结，仅作为技术参考资料，文中观点难免存在局限，恳请读者批评指正。

漏洞测试须在合法授权环境进行，可使用自己搭建的靶场或获书面授权的目标系统，否则将担法律责任。

阅读文章请遵守本文《法律与责任声明》

介绍：

csrf跨站请求伪造和xss跨站是有一定的区别的

一、核心区别一句话总结

• XSS ：攻击者往网页里注入恶意 JS 代码，让用户浏览器执行，从而窃取 Cookie、模拟用户操作。
• CSRF ：攻击者利用用户已登录的身份，诱导用户在不知情的情况下，向目标网站发送请求。

xss是需要在有xss注入漏洞的情况下，而csrf不需要xss注入。

二、详细对比

1. 攻击原理

• XSS

  • 漏洞点：前端输入过滤不严 ，攻击者插入 <sc..pt> 等代码。
  • 本质：代码注入，让浏览器执行攻击者的脚本。

• CSRF

  • 漏洞点：后端未校验请求来源，只依赖 Cookie 自动携带。
  • 本质：身份冒用，借用户已登录的状态发起恶意请求。

2. 攻击过程

• XSS

  1. 攻击者在评论 / 发帖处插入恶意 JS
  2. 其他用户访问页面，脚本自动执行
  3. 脚本偷 Cookie / 发请求 / 弹钓鱼

• CSRF

  1. 用户先登录目标网站 A，Cookie 存在浏览器
  2. 用户访问攻击者网站 B
  3. B 自动向 A 发请求（转账、删帖等）
  4. 浏览器自动带上 A 的 Cookie，请求成功

3. 依赖条件

• XSS ：需要能注入并执行脚本，不需要用户登录也能发生。
• CSRF ：可以注入脚本也可以不注入脚本，但必须是用户已登录目标网站。

4. 典型危害

• XSS

  • 窃取 Cookie、Session
  • 劫持账号、钓鱼、键盘记录
  • 页面篡改

• CSRF

  • 恶意转账
  • 修改密码、绑定手机号
  • 删帖、发垃圾内容

5. 核心防御方式

• XSS

  • 输入转义、过滤特殊字符
  • CSP（内容安全策略）
  • HttpOnly Cookie（防止 JS 读取）

• CSRF

  • 验证码
  • Referer / Origin 校验
  • Token 校验（最常用）
  • SameSite Cookie

CSRF 功能点:

删除帐户、更改电子邮件、更改密码、添加新管理员、更改正常信息等等情况

案例-CSRF利用-无防护

首先我们先演示一个无防护的

检测：黑盒手工利用测试，白盒看代码检验（有无token，来源检验等）

生成：BurpSuite->Engagement tools->Generate CSRF Poc

利用：将文件放在自己的站点下，诱使受害者访问（或配合XSS触发访问）

此处可以创建管理员，我们任意创建一个然后抓包看数据包，发送到csrf poc构造数据包

拓展：

Engagement tools 直译是「交互工具 / 协作工具」，在 Burp Suite 里，它是 「渗透测试全流程辅助工具集」 的统称，相当于给你做测试的「工具箱」，里面的功能都是帮你更高效地完成渗透测试的。

用Generate CSRF poc这个功能，中文意思是生成 CSRF（跨站请求伪造）攻击的测试代码（PoC），用来验证目标网站有没有 CSRF 漏洞。

1. 🔎 Find references（查找参考 / 关联请求）

• 作用 ：在当前请求的前后，自动搜索并展示有依赖关系的其他请求。
• 例子 ：你登录后台时，先访问了 login.php，然后访问了 admin.php。这个功能会帮你把这两个相关的请求串起来，让你看清整个操作链，方便分析漏洞的上下文。

2. 🔍 Discover content（发现内容）

• 作用 ：自动爬取 / 扫描目标网站，尝试发现隐藏的文件、目录、接口或页面。
• 例子 ：网站 robots.txt 里藏了后台地址，或者某个隐藏的 api.php，这个功能可以帮你自动找出来，扩大测试范围。

3. 📅 Schedule task（计划任务）

• 作用 ：把当前的扫描任务，设置为定时执行。
• 例子：你想晚上让 Burp 自动跑一个爬虫，或者第二天再继续扫描，用这个功能设定时间，到点自动执行，不用一直盯着。

一句话总结

• Find references：找相关请求，理清业务流程。
• Discover content：扫隐藏内容，找更多测试点。
• Schedule task：定时扫描，解放双手。

------------------------------------------------------------------------------------------------------------------------------------

然后我们来到poc构造页面

此处右侧有几个选项我们可以去详细看一下

1. 🟢 Auto-select based on request features（默认推荐）

• 含义 ：自动选择。Burp 会自动检测你刚才抓到的请求是什么类型（比如是表单提交还是 Ajax 请求），然后自动选最合适的生成方式。
• 适用场景 ：90% 的情况都选这个，最省心，直接生成最标准的 PoC。

2. 🔤 URL-encoded form（URL 编码表单）

• 含义 ：生成标准的 HTML 表单。
• 特点 ：表单数据会按照 URL 编码规则（key=value&...）提交。
• 适用场景 ：针对普通网页表单（POST 方式提交数据）。这是最常见的 CSRF 攻击形式。

3. 📝 Multipart form（多部分表单）

• 含义 ：生成支持文件上传的表单。
• 特点：编码格式更复杂，用于传输二进制文件或大量数据。
• 适用场景 ：只有当目标请求涉及上传文件功能时，才需要选这个，否则直接用上面两个。

4. 📄 Plain text form（纯文本表单）

• 含义 ：生成最简单的 HTML 表单，不进行复杂的编码处理。
• 特点：数据会以纯文本形式原样发送。
• 适用场景：比较少见。主要用于一些后端解析非常不标准（比如只吃原始字符串）的老旧系统。

5. 🌐 Cross-domain XHR（跨域 XHR）

• 含义 ：使用 JavaScript 的 Ajax 技术发起请求。
• 特点：利用浏览器的 CORS（跨域资源共享）机制发送请求。
• 适用场景 ：仅限现代浏览器。用来测试目标网站是否存在 CORS 配置错误导致的 CSRF 风险（通常难度较大，一般只在特定测试环境下用）。

🔥 关键选项：Include auto-submit script

• 含义 ：包含自动提交脚本。
• 作用 ：Burp 会在生成的 HTML 代码里自动加上一段 JavaScript 代码 （document.forms[0].submit();）。
• 效果 ：用户只要打开你的恶意网页，不需要点击提交按钮 ，浏览器就会自动执行转账 / 改密码操作。
• 建议 ：必须勾选。因为你要演示攻击，自动提交才是真正的 CSRF 危害，手动点击按钮不具备伪造意义。

然后把poc构造中下方生成的html复制，创建一个html进行伪造

然后把这个html文件放到网络中

这个漏洞的条件就是要让目标用户访问我门的html文件，并且需要是最高管理员有创建用户的权限

我们可以看到创建成功

所以网站肯定会搞一些csrf防护

CSRF利用-同源策略防护

会验证referer源，当目标访问请求头中的源地址是指定地址时就会做某事如果不是就会做另外一件事

我们可以访问目标网站抓包查看

必须是正确的referer才能够成功创建用户

这是我们就必须知道目标referer限制的到底是什么，但一般黑盒来说我们是不知道的，白盒来说我们可以获取到

当我们获取到时我们就可以通过在伪造的html中加入referer来通过验证

目前只使用referer的网站很少，并且如果某网站直接指定了只有某个地址才可以这对那个网站的功能也会受限

那么此处就会有新的技术，一般网站会使用匹配规则

什么是 "Referer 匹配规则"？

因为如果网站只允许一个固定的 Referer（比如 https://example.com/admin），会有明显的缺陷，限制太死，会影响用户正常使用（比如分享链接跳转、第三方嵌入，...各种影响）。

所以，大部分网站不会做完全相等的校验，而是用更灵活的匹配规则，常见的有这几种：

1. 域名后缀匹配（最常见）

规则：只要 Referer 的域名属于网站自身的主域名，就放行。

2. 路径前缀匹配

规则：只校验 Referer 的路径是否在指定前缀下，不管子域名。

3. 白名单列表匹配

规则：后端维护一个白名单列表，只要 Referer 出现在列表里，就放行。

4. 部分匹配（弱校验）

规则：只校验 Referer 里是否包含关键字符串，不做完整校验。

那么在做匹配的情况下我们如何绕过？

此处讲三种绕过方法

绕过1：规则匹配绕过问题（代码逻辑不严谨）

第一种置空来源

<meta name="referrer" content="no-referrer">

写入构造的html中，当用户访问时会将referer置空，从而有可能绕过

此时就会发现数据包中没有了referer

如何再次模拟受害者访问html

添加成功

还有一种绕过方式，我们先把那个置空referer删掉

把刚刚创建的用户也删掉，然后重新访问html并抓包

此时我们要做的是把目标host加到referer后面

然后放行，就会成功

绕过2：配合文件上传绕过（严谨使用同源绕过）

就是我们之前讲的那样，使用同源的话假设网站有文件上传我们就可以上传恶意网页到网站，那么当目标访问时就会是本地referer

绕过3：配合存储XSS绕过（严谨使用同源绕过）

这个xss也是，我们上传xss恶意脚本后会也是自己的站点触发数据包也就相当于是自己的referer就能够绕过了

CSRF利用-Token校验防护

token是一个数据包的生成编号，token出现就更加对csrf防护严格，一般数据包中都可见csrf_token就是专门用来防护csrf的，现在大部分都使用这个，并且会和刚刚的同源一起使用，因为同源本身有绕过，但再加上这个已经算的上比较安全了

我们可以抓包看一下

里面多了一个csrf_token的值

然后此时我生成一个scrf poc，然后浏览器访问

是没问题的

但我换个浏览器时

这是为什么，明明也伪造了token啊？

这是因为token技术就是某一次操作就绑定了一个编号，第一次成功是因为我们前面已经成功在浏览器中执行或者打开，你换个浏览器后token是已经改动的，就是另外一个身份了，这就有效的防护了csrf，就算伪造了网站也会进行token验证

每个数据包都有唯一的token，并且这个token是不能够伪造的是你不可预知的，是由代码自动决定生成的

此处就有三种绕过方式，不过缪按一般来说都很少能绕过了

绕过1：将Token参数值复用

就是代码瑞逻辑不严谨，我再次复用这个token还是能够使用

绕过2：将Token参数删除

绕过3：将Token参数值置空

此处讲完token后我们需要返回头去看一下一开始讲的内容其实在实战中可能是不成立的

推翻！

其实我们刚刚的csrf同源绕过在实战中是不成功的

我们可以做演示

攻击者在实战中需要准备有两个

1.创建一个受害者访问的页面，让受害者去访问触发

2.搞下受害者目标网站的源码供我们使用构造数据包 我们前面演示是直接在网站中搞得，而我们实战中是需要通过目标源码来获取数据包进行构造

过程：

此处我先搞下目标网站源码，然后模拟管理员创建用户进行抓包，构造poc

然后我们需要把里面的地址改为目标网站的地址

然后把恶意html放到网上去等待受害者连接

此时我们模拟受害者访问恶意网站后显示

显示非法访问，然后去受害者的网站看也并没有成功创建用户

然后我们知道是referer影响，尝试将同源策略置空，按我们上面讲的这一步就会成功

但我们访问后还是错误

原因就是多做了一步

搞下受害者目标网站的源码供我们使用构造数据包 我们前面演示是直接在网站中搞得，而我们实战中是需要通过目标源码来获取数据包进行构造

这一步

因为我们刚刚直接用的管理员受害者创建用户的数据包，里面带了正确的token，而此处token是不同导致错误

此时当我们有条件将token改为正确的后就会成功

补充知识：

讲到这里可能还没明白的一点就是，这个token到底是怎么样的，是每一个数据包中都不一样嘛（不管是同一个浏览器还是不同浏览器，是同一个浏览器中的不同网页或者是相同页面，或者比如说同一个页面刷新两次token会变嘛？）

一句话核心结论

CSRF Token = 一次性防伪暗号

每一次请求、每一个用户、每一个页面、每一次刷新，都可以不一样！

攻击者永远拿不到，所以伪造不了请求。

1. Token 到底是什么？

就是后端给前端的一个随机字符串，比如：

csrf_token=8a7b6c5d4e3f2a1

必须跟着表单 / 数据包一起提交，后端校验：

• 你有这个 token → 通过
• 没有 / 错了 / 用过了 → 拦截

这就是 CSRF 防御的终极方案。

2. 最重要的问题：Token 什么时候会变？

① 同一个页面 刷新一次

✅ 绝大多数网站：Token 会变！

（刷新 = 后端重新生成新 token）

② 同一个页面 不刷新，多次提交

✅ 有的会变（一次性 token）

✅ 有的不变（同页面有效）

看后端怎么设计。

③ 同一个浏览器 → 不同页面

✅ Token 一定不一样！

每个页面独立生成。

④ 同一个浏览器 → 相同页面（新开标签）

✅ Token 不一样！

⑤ 不同浏览器 / 不同用户

✅ Token 完全不一样！

互相不通用。

⑥ 同一个用户 → 退出再登录

✅ Token 全部重新生成！

3. 最关键的规律

Token 和 3 个东西绑定：

1. 用户会话（Session）

   → 每个用户的 token 不一样

2. 页面 / 表单

   → 每个表单的 token 不一样

3. 时间 / 次数

   → 一次性使用，用过就废

Token 绝对不会

• 不同用户共用同一个 token
• 不同页面共用同一个 token
• 永远不变

token总结

有些情况是一定变得，有些情况也得看后端是怎么样写的逻辑

本篇完 | 实践出真知，交流共进步

每一篇文章都是一次沉淀，感谢你的阅读。技术没有捷径，唯有不断积累、不断输出。期待下次继续与你分享更多实战经验，一起前行。

《法律与责任声明》

本内容仅用于网络安全漏洞的技术研究、学习与交流。

一、合法性要求

• 严格遵守《中华人民共和国网络安全法》及相关法律法规，严禁将所学技术用于非法活动，如未经授权的攻击、窃取信息等。例如，不得对未授权的真实生产环境网站做漏洞测试。
• 漏洞测试须在合法授权环境进行，可使用自己搭建的靶场或获书面授权的目标系统，否则将担法律责任。

二、风险与责任

• 若因参考本内容对第三方造成损失，本人不承担法律责任，使用者自行担责。

三、传播限制

• 禁止将本内容用于恶意传播，如制作恶意教程、培训非法黑客组织，应维护良好网络安全环境。
• 发现有人利用本内容非法活动，应及时举报。

四、版权声明

本文为本人独立创作，有完整知识产权。未经书面许可，任何单位或个人不得转载、复制或以其他方式使用，违者依法追责。

阅读并使用本文章内容即表示同意声明条款