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 漏洞成立的三大必要条件(缺一不可)
- 受害者保持登录状态:浏览器中保留目标网站有效的 Cookie 或者 Session 会话;一旦用户退出登录、Cookie 过期,攻击直接失效。
- 业务接口可以被跨域调用:修改、新增、删除这类写操作接口,可以通过跨站页面发起请求,不需要前端额外校验。
- 后端缺少防护校验机制:接口没有随机 CSRF Token,没有严格校验请求来源 Referer,没有短信验证码、密码二次确认等强校验手段。
1.3 CSRF 核心底层原理:浏览器 Cookie 携带机制
浏览器有一条基础规则:当访问某域名下的资源时,如果发起对该域名的请求,浏览器会自动附带该域名下存储的全部 Cookie,不管这个请求是本站页面发起,还是其他外部恶意页面跨站发起。
举个生活化例子:
你登录了网上后台管理系统,Cookie 保存在浏览器。你没有退出登录,接着点开攻击者发的恶意网页链接。这个恶意页面后台偷偷向网站后台发送新增管理员的请求,浏览器自动带上你的登录 Cookie。网站后端收到请求,看到 Cookie 有效,判定是你本人操作,直接新增管理员账号。整个过程你看不到任何弹窗提示。
关键点:攻击者看不到接口返回内容,只能发起请求执行操作。这是 CSRF 非常重要的特点。
二、CSRF 完整攻击流程(分步详解)
- 受害者登录目标网站,输入账号密码登录成功,网站下发 Cookie,保存在本地浏览器,会话保持有效;
- 攻击者分析业务接口:找到可以修改数据的接口,抓包获取请求地址、请求方式、请求参数;
- 攻击者构造恶意 HTML 页面,页面内置自动提交的请求(GET 链接 / POST 自动表单);
- 社工诱导受害者访问恶意页面:通过聊天、邮件、论坛帖子发送链接,诱导受害者点击打开页面;
- 恶意页面加载完成,自动发起跨站请求;
- 浏览器自动附加目标网站 Cookie,发送请求到目标服务器;
- 服务器校验 Cookie 有效,无 CSRF Token、无来源校验,执行业务操作;
- 用户在完全不知情的情况下,账号信息被篡改。
注意:整个攻击过程,攻击者无法获取 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 正常业务流程
- 用户输入账号密码登录网站;
- 进入个人资料页面,输入新昵称;
- 点击提交,POST 请求发送到后端;
- 后端接收请求,更新数据库昵称字段,修改成功。
5.3 CSRF 漏洞完整测试流程
- 抓包分析请求数据包
使用 Burp Suite 抓取正常修改昵称的数据包,观察请求头与请求体。
重点观察:数据包内是否携带csrf_token、token、verify这类随机校验字段。
本次抓包发现:只有 Cookie 和业务参数,不存在任何 Token 字段。 - 验证接口是否可跨站复用
复制请求地址、请求方式、参数,脱离当前会话页面,单独构造请求。只要带上有效 Cookie,接口依然可以成功修改数据,说明接口没有绑定页面上下文。 - 构造自动提交 HTML 表单 POC
按照前面示例编写 html 文件,填写目标接口地址与业务参数。 - 漏洞验证
保持靶场账号处于登录状态,在同一个浏览器打开 POC 页面。页面加载后表单自动提交,刷新个人资料页面,昵称成功被篡改,CSRF 漏洞复现成功。
5.4 攻击特点总结
- 攻击者不需要窃取用户 Cookie;
- 不需要复杂的注入 Payload;
- 用户无弹窗、无确认提示,静默执行;
- 只要 Cookie 有效,一次访问即可完成操作。
六、CSRF 防护机制常见缺陷与绕过思路
很多业务会增加简单防护,但防护逻辑存在漏洞,可以轻松绕过。这部分是 SRC 实战挖洞的重点,很多低质量防护在这里翻车。
6.1 Referer 请求来源校验与绕过
Referer 请求头记录请求来源页面地址,很多网站简单校验 Referer,判断请求是否来自本站。
常见缺陷与绕过方式:
- 模糊包含匹配
后端代码只判断 Referer 是否包含网站域名,而不是完全匹配。
例:目标域名test.local,后端判断if(referer contain "test.local")。
攻击者搭建域名test.local.attacker.com,Referer 里面包含目标字符串,直接绕过校验。 - 允许 Referer 为空
后端逻辑:如果 Referer 为空,直接放行。
利用方式:构造请求,删除 Referer 请求头,发送空 Referer 数据包。部分浏览器特定场景下跨站请求不会携带 Referer,以此绕过。 - Referer 头可被前端篡改
前端可以通过 meta 标签控制 Referer 是否发送,实现清空 Referer。
<meta name="referrer" content="never">总结:Referer 只能作为辅助防护手段,不能作为 CSRF 唯一防护方案。
6.2 CSRF Token 相关缺陷绕过
很多网站虽然写了 Token 字段,但是代码逻辑有问题,防护形同虚设。
- Token 前端生成,后端不校验
前端页面生成 token,随请求提交,后端直接忽略,不做校验判断,随便填写任意值都能通过。 - Token 固定不变
Token 写死为固定字符串,所有用户、每次请求 Token 完全一样。攻击者直接复用这个固定 Token 构造请求。 - Token 放在 Cookie 中校验
后端从 Cookie 读取 Token 对比参数中的 Token,这种方式依然可以被 CSRF 绕过。跨站请求会自动带上 Cookie,Token 同步携带。 - Token 仅在 GET 请求校验,POST 不校验
只对 GET 接口增加 Token,POST 写操作接口遗漏校验。
6.3 二次确认逻辑缺陷绕过
部分高危操作设计了弹窗确认,但是确认弹窗仅前端 JS 限制。攻击者抓包直接调用后端接口,绕过前端弹窗。
七、CSRF 漏洞真实危害
很多人误以为 CSRF 危害低,实际上,根据接口权限不同,危害差距巨大。
- 普通用户接口 CSRF
篡改用户昵称、头像、个人简介;修改登录密码;更换绑定手机号,直接劫持用户账号;发布恶意评论、帖子;提交恶意工单。 - 管理员后台接口 CSRF(高危)
新增后台管理员账号;修改管理员密码;删除网站数据;修改网站配置;上传文件。一旦管理员访问恶意页面,攻击者直接拿到后台管理权限。 - 业务资金类接口 CSRF(严重高危)
发起转账、消费下单,造成用户资金损失。这类接口一般会增加短信验证码防护,相对少见。
重点区分:普通用户 CSRF 一般定级中危;管理员接口 CSRF 默认高危,SRC 平台分值很高。
八、多层防御方案(安全开发 / 渗透报告修复建议)
防御 CSRF 不能依靠单一手段,推荐多层防护叠加,优先采用 Token 方案,其余作为辅助加固。
8.1 核心方案:随机 CSRF Token(首选方案)
原理:后端在用户会话中生成一次性、随机、不可预测的 Token,下发到前端页面。用户发起写操作请求时,必须在请求参数中携带该 Token。后端校验 Token 是否存在、是否和当前会话匹配,校验失败直接拒绝请求。
攻击者跨站发起请求时,无法获取页面内的随机 Token,无法构造合法请求,从根源防御 CSRF。
开发注意要点:
- Token 绑定当前用户 Session;
- 每次表单请求重新生成 Token,或 Token 使用后失效;
- 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 接口开发规范
- 所有新增、修改、删除的写操作接口,禁止使用 GET 请求,统一 POST;
- 接口增加同源策略控制,限制跨域访问;
- 后端不要信任前端传来的 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 页面,诱导处于登录状态的用户访问页面,在用户无感知的情况下自动发起请求,篡改用户昵称等账号信息。
复现步骤:
- 使用账号登录目标网站,进入个人资料修改页面;
- 使用 Burp Suite 抓包正常修改资料请求,观察数据包,请求内不存在 CSRF Token 等校验字段;
- 根据接口地址、请求方式与参数,构造自动提交表单的 HTML POC 页面;
- 保持浏览器登录状态,打开 POC 页面,表单自动提交;
- 刷新个人资料页面,用户昵称被成功篡改,漏洞验证成功。
漏洞危害:攻击者可诱导用户访问恶意页面,在用户不知情的情况下篡改个人资料;若该接口为管理员后台接口,攻击者可新增管理员账号,直接接管网站后台,控制全站业务数据。
修复建议:- 所有写操作接口增加随机 CSRF Token 校验,Token 绑定用户会话;
- 后端严格校验 Referer 来源域名,采用完整域名匹配,不使用模糊匹配;
- 修改密码、更换手机号等高风险操作,增加原密码或者短信验证码二次确认;
- 登录 Cookie 配置 SameSite 属性,从浏览器层面限制跨站携带 Cookie;
- 高危写操作接口禁用 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%免费】