☰
CSRF 跨站请求伪造漏洞原理与实战测试
2026/10/7 16:23:07 网站建设 项目流程

CSRF 跨站请求伪造漏洞原理与实战测试

前言

在 Web 安全漏洞体系中,CSRF(跨站请求伪造 Cross-Site Request Forgery)是一类非常经典的业务型安全漏洞,同时也是企业渗透测试、SRC 漏洞挖掘、CTF Web 赛题、安全面试里的高频考点。

很多刚入门 Web 安全的同学,学习重心都放在 SQL 注入、XSS 跨站脚本、文件上传这类能够直接获取服务器权限的高危漏洞上,常常会轻视 CSRF。大家会觉得 CSRF 技术门槛低、利用方式简单,没有复杂的 Payload,不值得深入研究。但在真实的 SRC 挖洞和企业渗透项目中,CSRF 的出镜率非常高,很多开发人员在开发业务接口时,很容易忘记增加 CSRF 防护机制。

CSRF 的攻击逻辑和 XSS 有本质区别:XSS 是通过注入 JS 脚本,直接获取用户浏览器内的权限;而 CSRF 不需要拿到用户 Cookie,而是借用用户当前的登录身份,在用户不知情的情况下发起请求,执行业务操作。攻击者利用浏览器的 Cookie 自动携带机制,完成身份冒用。很多时候,普通用户完全感知不到任何异常,操作就已经被执行。

CSRF 漏洞覆盖场景极广:修改个人资料、修改登录密码、绑定手机号、新增后台管理员、发布评论、提交工单、转账下单等,只要是写操作接口,一旦缺少防护,就有可能存在 CSRF 漏洞。尤其是后台管理员接口,如果存在 CSRF,危害会直接升级为高危,甚至可以直接拿下整个网站后台权限。

本文会从底层原理、漏洞成立条件、攻击完整流程、GET/POST 两种类型的漏洞实战演示、Referer 校验绕过、Token 防护缺陷绕过、CSRF 和 XSS/SSRF 的区分、漏洞危害、多层防御方案、面试考点、漏洞报告模板一次性全部讲透。内容偏向实战,适合零基础入门学习、面试背诵、SRC 漏洞报告编写,看完就能上手测试业务接口。

⚠️ 免责声明
本文所有技术内容仅用于授权安全测试、网络安全学习、靶场实训。严禁在未授权网站、公网业务系统进行 CSRF 漏洞测试,违规操作造成的一切后果由本人自行承担。

一、CSRF 漏洞基础概念

1.1 什么是 CSRF

CSRF 全称跨站请求伪造(Cross-Site Request Forgery)。

通俗一句话总结:
用户登录目标网站之后,没有关闭浏览器、没有退出登录,浏览器保存了有效的身份凭证 Cookie/Session。攻击者诱导用户访问恶意页面,恶意页面会自动向目标网站发起请求,浏览器会自动带上目标网站的 Cookie,服务器认为是用户本人发起操作,从而执行对应的业务逻辑。

简单理解:攻击者借用户的身份办事,而不是偷用户的身份。

1.2 CSRF 漏洞成立的三大必要条件(缺一不可)

  1. 受害者保持登录状态:浏览器中保留目标网站有效的 Cookie 或者 Session 会话;一旦用户退出登录、Cookie 过期,攻击直接失效。
  2. 业务接口可以被跨域调用:修改、新增、删除这类写操作接口,可以通过跨站页面发起请求,不需要前端额外校验。
  3. 后端缺少防护校验机制:接口没有随机 CSRF Token,没有严格校验请求来源 Referer,没有短信验证码、密码二次确认等强校验手段。

1.3 CSRF 核心底层原理:浏览器 Cookie 携带机制

浏览器有一条基础规则:当访问某域名下的资源时,如果发起对该域名的请求,浏览器会自动附带该域名下存储的全部 Cookie,不管这个请求是本站页面发起,还是其他外部恶意页面跨站发起。

举个生活化例子:
你登录了网上后台管理系统,Cookie 保存在浏览器。你没有退出登录,接着点开攻击者发的恶意网页链接。这个恶意页面后台偷偷向网站后台发送新增管理员的请求,浏览器自动带上你的登录 Cookie。网站后端收到请求,看到 Cookie 有效,判定是你本人操作,直接新增管理员账号。整个过程你看不到任何弹窗提示。

关键点:攻击者看不到接口返回内容,只能发起请求执行操作。这是 CSRF 非常重要的特点。

二、CSRF 完整攻击流程(分步详解)

  1. 受害者登录目标网站,输入账号密码登录成功,网站下发 Cookie,保存在本地浏览器,会话保持有效;
  2. 攻击者分析业务接口:找到可以修改数据的接口,抓包获取请求地址、请求方式、请求参数;
  3. 攻击者构造恶意 HTML 页面,页面内置自动提交的请求(GET 链接 / POST 自动表单);
  4. 社工诱导受害者访问恶意页面:通过聊天、邮件、论坛帖子发送链接,诱导受害者点击打开页面;
  5. 恶意页面加载完成,自动发起跨站请求;
  6. 浏览器自动附加目标网站 Cookie,发送请求到目标服务器;
  7. 服务器校验 Cookie 有效,无 CSRF Token、无来源校验,执行业务操作;
  8. 用户在完全不知情的情况下,账号信息被篡改。

注意:整个攻击过程,攻击者无法获取 Cookie 明文,不需要窃取 Cookie,完全依靠浏览器自动携带机制。这点和 XSS 盗取 Cookie 有巨大区别。

三、CSRF 与 XSS 核心区别(面试高频考点)

很多新手在学习时很容易混淆 XSS 和 CSRF,两者虽然都属于前端相关漏洞,但是攻击思路、能力边界完全不一样。

对比项XSS(跨站脚本)CSRF(跨站请求伪造)
攻击目标用户浏览器Web 服务端业务接口
攻击原理注入 JS 代码,在浏览器执行脚本利用浏览器自动携带 Cookie,冒用身份发起请求
攻击者权限完全控制浏览器,可以读取页面返回、Cookie、本地存储仅能发起请求,无法读取接口返回数据
获取 Cookie可以直接窃取 Cookie不需要获取 Cookie
触发条件恶意代码输出页面并被浏览器解析用户保持登录状态,访问恶意页面
可控范围读取数据、篡改页面、发起请求、内网探测只能调用已存在业务接口执行写操作

极简记忆口诀

XSS:偷你的浏览器权限,能看、能拿、能操作;
CSRF:借你的登录身份,只能发起操作,看不到返回内容。

补充联动知识点:如果网站同时存在 XSS 漏洞,可直接获取 CSRF Token,绕过 CSRF 防护。所以 XSS 漏洞优先级更高,可以突破 CSRF 防御。

四、CSRF 漏洞分类与实战场景

根据接口请求方式,CSRF 分为GET 型 CSRF和POST 型 CSRF。GET 型利用最简单,POST 型在真实业务中更常见。

4.1 GET 型 CSRF

业务接口使用 GET 方式提交参数,参数拼接在 URL 链接中,访问链接就自动执行业务操作。

业务场景示例

网站修改个人昵称接口:

http://test.local/user/edit.php?nickname=hacktest

业务逻辑:访问这个地址,直接把当前登录用户昵称修改为 hacktest。

利用方式

攻击者直接构造恶意链接:

http://test.local/user/edit.php?nickname=账号已被篡改

社工诱导处于登录状态的用户点击链接,用户一点击,请求直接发出,昵称被修改。

风险点:很多开发图省事,修改类接口直接使用 GET 请求,极易产生 GET 型 CSRF。安全规范要求:所有修改、新增、删除等写操作,禁止使用 GET 请求。

4.2 POST 型 CSRF(实战中最多)

业务写操作接口采用 POST 表单提交,参数放在请求 Body 中,无法直接通过 URL 链接触发,需要构造 HTML 自动提交表单页面。

典型业务场景

修改登录密码、更换绑定手机号、新增后台管理员、发布文章评论、提交工单。

通用 POC(自动提交表单页面)
<html> <head> <title>loading</title> </head> <body> <form action="http://test.local/user/edit.php" method="POST" id="csrf_form"> <input type="hidden" name="nickname" value="CSRF测试篡改昵称" /> <input type="hidden" name="userid" value="10001" /> </form> <script> // 页面加载完成,自动提交表单 window.onload = function(){ document.getElementById("csrf_form").submit(); } </script> </body> </html>

将代码保存为csrf_poc.html。受害者在登录目标网站的状态下,打开这个 html 文件,页面会自动提交 POST 请求,完成操作。用户几乎看不到页面内容,操作静默执行。

扩展:除了 form 表单,还可以使用 JS 的 fetch、axios 发送跨站请求。但浏览器同源策略会限制读取响应,不影响请求发送,而 CSRF 只需要发送请求即可。

五、完整实战复现步骤(手把手测试)

5.1 测试靶场环境

靶场业务:用户中心个人资料修改模块
接口地址:http://test.local/user/edit.php
请求方式:POST
请求参数:nickname,作用修改用户昵称
漏洞成因:接口没有 CSRF Token、没有校验 Referer 来源、高危操作无原密码 / 验证码二次确认

5.2 正常业务流程

  1. 用户输入账号密码登录网站;
  2. 进入个人资料页面,输入新昵称;
  3. 点击提交,POST 请求发送到后端;
  4. 后端接收请求,更新数据库昵称字段,修改成功。

5.3 CSRF 漏洞完整测试流程

  1. 抓包分析请求数据包
    使用 Burp Suite 抓取正常修改昵称的数据包,观察请求头与请求体。
    重点观察:数据包内是否携带csrf_token、token、verify这类随机校验字段。
    本次抓包发现:只有 Cookie 和业务参数,不存在任何 Token 字段。
  2. 验证接口是否可跨站复用
    复制请求地址、请求方式、参数,脱离当前会话页面,单独构造请求。只要带上有效 Cookie,接口依然可以成功修改数据,说明接口没有绑定页面上下文。
  3. 构造自动提交 HTML 表单 POC
    按照前面示例编写 html 文件,填写目标接口地址与业务参数。
  4. 漏洞验证
    保持靶场账号处于登录状态,在同一个浏览器打开 POC 页面。页面加载后表单自动提交,刷新个人资料页面,昵称成功被篡改,CSRF 漏洞复现成功。

5.4 攻击特点总结

  1. 攻击者不需要窃取用户 Cookie;
  2. 不需要复杂的注入 Payload;
  3. 用户无弹窗、无确认提示,静默执行;
  4. 只要 Cookie 有效,一次访问即可完成操作。

六、CSRF 防护机制常见缺陷与绕过思路

很多业务会增加简单防护,但防护逻辑存在漏洞,可以轻松绕过。这部分是 SRC 实战挖洞的重点,很多低质量防护在这里翻车。

6.1 Referer 请求来源校验与绕过

Referer 请求头记录请求来源页面地址,很多网站简单校验 Referer,判断请求是否来自本站。
常见缺陷与绕过方式:

  1. 模糊包含匹配
    后端代码只判断 Referer 是否包含网站域名,而不是完全匹配。
    例:目标域名test.local,后端判断if(referer contain "test.local")。
    攻击者搭建域名test.local.attacker.com,Referer 里面包含目标字符串,直接绕过校验。
  2. 允许 Referer 为空
    后端逻辑:如果 Referer 为空,直接放行。
    利用方式:构造请求,删除 Referer 请求头,发送空 Referer 数据包。部分浏览器特定场景下跨站请求不会携带 Referer,以此绕过。
  3. Referer 头可被前端篡改
    前端可以通过 meta 标签控制 Referer 是否发送,实现清空 Referer。
<meta name="referrer" content="never">

总结:Referer 只能作为辅助防护手段,不能作为 CSRF 唯一防护方案。

6.2 CSRF Token 相关缺陷绕过

很多网站虽然写了 Token 字段,但是代码逻辑有问题,防护形同虚设。

  1. Token 前端生成,后端不校验
    前端页面生成 token,随请求提交,后端直接忽略,不做校验判断,随便填写任意值都能通过。
  2. Token 固定不变
    Token 写死为固定字符串,所有用户、每次请求 Token 完全一样。攻击者直接复用这个固定 Token 构造请求。
  3. Token 放在 Cookie 中校验
    后端从 Cookie 读取 Token 对比参数中的 Token,这种方式依然可以被 CSRF 绕过。跨站请求会自动带上 Cookie,Token 同步携带。
  4. Token 仅在 GET 请求校验,POST 不校验
    只对 GET 接口增加 Token,POST 写操作接口遗漏校验。

6.3 二次确认逻辑缺陷绕过

部分高危操作设计了弹窗确认,但是确认弹窗仅前端 JS 限制。攻击者抓包直接调用后端接口,绕过前端弹窗。

七、CSRF 漏洞真实危害

很多人误以为 CSRF 危害低,实际上,根据接口权限不同,危害差距巨大。

  1. 普通用户接口 CSRF
    篡改用户昵称、头像、个人简介;修改登录密码;更换绑定手机号,直接劫持用户账号;发布恶意评论、帖子;提交恶意工单。
  2. 管理员后台接口 CSRF(高危)
    新增后台管理员账号;修改管理员密码;删除网站数据;修改网站配置;上传文件。一旦管理员访问恶意页面,攻击者直接拿到后台管理权限。
  3. 业务资金类接口 CSRF(严重高危)
    发起转账、消费下单,造成用户资金损失。这类接口一般会增加短信验证码防护,相对少见。

重点区分:普通用户 CSRF 一般定级中危;管理员接口 CSRF 默认高危,SRC 平台分值很高。

八、多层防御方案(安全开发 / 渗透报告修复建议)

防御 CSRF 不能依靠单一手段,推荐多层防护叠加,优先采用 Token 方案,其余作为辅助加固。

8.1 核心方案:随机 CSRF Token(首选方案)

原理:后端在用户会话中生成一次性、随机、不可预测的 Token,下发到前端页面。用户发起写操作请求时,必须在请求参数中携带该 Token。后端校验 Token 是否存在、是否和当前会话匹配,校验失败直接拒绝请求。

攻击者跨站发起请求时,无法获取页面内的随机 Token,无法构造合法请求,从根源防御 CSRF。
开发注意要点:

  1. Token 绑定当前用户 Session;
  2. 每次表单请求重新生成 Token,或 Token 使用后失效;
  3. Token 放置在请求参数、请求头,不要只放在 Cookie 中。

8.2 严格校验 Referer 请求来源(辅助防护)

使用完全精准域名匹配,禁止模糊包含匹配。仅允许本站域名的请求,拒绝外部域名 Referer。
缺陷:Referer 可以被清除,仅作为辅助,不可单独依赖。

8.3 Cookie 设置 SameSite 属性(浏览器层面防护)

给身份 Cookie 增加 SameSite 属性,限制跨站场景下 Cookie 的自动携带。

  • SameSite=Strict:完全禁止跨站请求携带 Cookie;
  • SameSite=Lax:部分宽松跨站场景禁止携带 Cookie。
    配合 Secure、HttpOnly 一起配置。

注意:旧版浏览器不支持 SameSite,只能作为浏览器端辅助加固。

8.4 高危操作增加强二次校验

对于改密码、换绑手机、转账、注销账号等高风险操作,增加强校验:

  • 输入原密码;
  • 短信验证码、邮箱验证码;
  • 人脸验证。
    就算 CSRF 请求成功发起,没有验证码依然无法执行高危操作。

8.5 接口开发规范

  1. 所有新增、修改、删除的写操作接口,禁止使用 GET 请求,统一 POST;
  2. 接口增加同源策略控制,限制跨域访问;
  3. 后端不要信任前端传来的 Referer、自定义 header,不可单依靠前端字段做安全校验。

8.6 WAF 辅助防护

WAF 可以识别常见 CSRF 攻击特征,拦截恶意跨站表单请求,作为兜底防护。

九、新手学习常见误区

❌ 误区 1:接口需要登录 = 安全
Cookie 自动携带,登录凭证存在就有 CSRF 风险。登录验证只是身份校验,不是请求来源校验。

❌ 误区 2:POST 请求无法跨站伪造
POST 请求非常容易伪造,一段简单 HTML 表单就可以自动提交 POST 数据包。

❌ 误区 3:CSRF 只能篡改昵称这类无关紧要的内容
如果是管理员新增账号接口,CSRF 直接接管网站后台,属于高危漏洞。

❌ 误区 4:校验 Referer 就足够防御 CSRF
Referer 很容易被清空或者绕过,只能辅助,不能作为唯一防护手段。

❌ 误区 5:CSRF 可以读取接口返回数据
CSRF 只能发送请求,受浏览器同源策略限制,攻击者无法拿到接口返回内容。

十、SRC 漏洞报告标准模板

漏洞名称:跨站请求伪造漏洞(CSRF)
漏洞描述:网站用户资料修改接口未配置 CSRF Token,没有严格校验请求 Referer 来源,存在 CSRF 跨站请求伪造漏洞。攻击者可构造恶意 HTML 页面,诱导处于登录状态的用户访问页面,在用户无感知的情况下自动发起请求,篡改用户昵称等账号信息。
复现步骤:

  1. 使用账号登录目标网站,进入个人资料修改页面;
  2. 使用 Burp Suite 抓包正常修改资料请求,观察数据包,请求内不存在 CSRF Token 等校验字段;
  3. 根据接口地址、请求方式与参数,构造自动提交表单的 HTML POC 页面;
  4. 保持浏览器登录状态,打开 POC 页面,表单自动提交;
  5. 刷新个人资料页面,用户昵称被成功篡改,漏洞验证成功。
    漏洞危害:攻击者可诱导用户访问恶意页面,在用户不知情的情况下篡改个人资料;若该接口为管理员后台接口,攻击者可新增管理员账号,直接接管网站后台,控制全站业务数据。
    修复建议:
  6. 所有写操作接口增加随机 CSRF Token 校验,Token 绑定用户会话;
  7. 后端严格校验 Referer 来源域名,采用完整域名匹配,不使用模糊匹配;
  8. 修改密码、更换手机号等高风险操作,增加原密码或者短信验证码二次确认;
  9. 登录 Cookie 配置 SameSite 属性,从浏览器层面限制跨站携带 Cookie;
  10. 高危写操作接口禁用 GET 请求,统一使用 POST 提交。

结尾

CSRF 属于业务逻辑类漏洞,它没有复杂的注入 Payload,也不需要解析特殊语法,原理理解起来比较简单。但正是因为看起来简单,开发在业务开发的时候经常遗漏防护,在 SRC 挖洞和渗透测试中属于很容易挖到的漏洞。

CSRF 漏洞的核心测试思路就是:抓包观察写操作接口,查看有没有 Token、来源校验,无防护就构造 POC 页面验证。同时要区分普通用户接口和管理员接口,管理员接口的 CSRF 漏洞风险等级会大幅提升。

Web 安全漏洞系列持续更新中,下一篇将更新SSRF
服务端请求伪造漏洞全方位详解
,后续还会继续讲解文件包含、命令执行、业务逻辑漏洞等全套 Web 安全干货。

喜欢本文可以点赞、收藏、关注,持续跟进全网详细 Web 安全教程,一起学习漏洞挖掘、SRC 实战!


如何系统学习网络安全?

网络安全作为数字时代的核心技术基石,已成为保障各行业安全稳定运行的坚实屏障。筑牢网络安全的防线,掌握先进的防护策略和技能正上升为国家与企业发展的战略优先级。

构建稳固的网络安全能力是一个体系的工程,需要从夯实基础理论出发,持续深化到攻防对抗与应急响应的实战层面。

如果你是准备学习网络安全(黑客)或者正在学习,我可以把我自用的360独家内部资料分享给你,包含以下内容你应该能用得上:

①网络安全学习路线
②20份渗透测试电子书
③安全攻防357页笔记
④50份安全攻防面试指南
⑤安全红队渗透工具包
⑥网络安全必备书籍
⑦100个漏洞实战案例
⑧安全大厂内部视频资源
⑨历年CTF夺旗赛题解析

一、网络安全(黑客)学习路线

网络安全(黑客)学习路线,形成网络安全领域所有的知识点汇总,它的用处就在于,你可以按照上面的知识点去找对应的学习资源,保证自己学得较为全面。

二、网络安全教程视频

我们在看视频学习的时候,不能光动眼动脑不动手,比较科学的学习方法是在理解之后运用它们,这时候练手项目就很适合了。

三、网络安全CTF实战案例

光学理论是没用的,要学会跟着一起敲,要动手实操,才能将自己的所学运用到实际当中去,这里带来的是CTF&SRC资料&HW资料,毕竟实战是检验真理的唯一标准嘛~

四、网络安全面试题

最后,我们所有的作为都是为就业服务的,所以关键的临门一脚就是咱们的面试题内容,所以面试题板块是咱们不可或缺的部分,这里我给大家准备的就是我在面试期间准备的资料。

网安其实不难,难的是坚持和相信自己,我的经验是既然已经选定网安你就要相信它,相信它能成为你日后进阶的高效渠道,这样自己才会更有信念去学习,才能在碰到困难的时候坚持下去。

机会属于有准备的人,这是一个实力的时代。人和人之间的差距不在于智商,而在于如何利用业余时间,只要你想学习,什么时候开始都不晚,不要担心这担心那,你只需努力,剩下的交给时间!

这份完整版的网络安全学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询