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 什么是 CSRFCSRF 全称跨站请求伪造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?nicknamehacktest业务逻辑访问这个地址直接把当前登录用户昵称修改为 hacktest。利用方式攻击者直接构造恶意链接http://test.local/user/edit.php?nickname账号已被篡改社工诱导处于登录状态的用户点击链接用户一点击请求直接发出昵称被修改。风险点很多开发图省事修改类接口直接使用 GET 请求极易产生 GET 型 CSRF。安全规范要求所有修改、新增、删除等写操作禁止使用 GET 请求。4.2 POST 型 CSRF实战中最多业务写操作接口采用 POST 表单提交参数放在请求 Body 中无法直接通过 URL 链接触发需要构造 HTML 自动提交表单页面。典型业务场景修改登录密码、更换绑定手机号、新增后台管理员、发布文章评论、提交工单。通用 POC自动提交表单页面html head titleloading/title /head body form actionhttp://test.local/user/edit.php methodPOST idcsrf_form input typehidden namenickname valueCSRF测试篡改昵称 / input typehidden nameuserid value10001 / /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.comReferer 里面包含目标字符串直接绕过校验。允许 Referer 为空后端逻辑如果 Referer 为空直接放行。利用方式构造请求删除 Referer 请求头发送空 Referer 数据包。部分浏览器特定场景下跨站请求不会携带 Referer以此绕过。Referer 头可被前端篡改前端可以通过 meta 标签控制 Referer 是否发送实现清空 Referer。meta namereferrer contentnever总结Referer 只能作为辅助防护手段不能作为 CSRF 唯一防护方案。6.2 CSRF Token 相关缺陷绕过很多网站虽然写了 Token 字段但是代码逻辑有问题防护形同虚设。Token 前端生成后端不校验前端页面生成 token随请求提交后端直接忽略不做校验判断随便填写任意值都能通过。Token 固定不变Token 写死为固定字符串所有用户、每次请求 Token 完全一样。攻击者直接复用这个固定 Token 构造请求。Token 放在 Cookie 中校验后端从 Cookie 读取 Token 对比参数中的 Token这种方式依然可以被 CSRF 绕过。跨站请求会自动带上 CookieToken 同步携带。Token 仅在 GET 请求校验POST 不校验只对 GET 接口增加 TokenPOST 写操作接口遗漏校验。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 的自动携带。SameSiteStrict完全禁止跨站请求携带 CookieSameSiteLax部分宽松跨站场景禁止携带 Cookie。配合 Secure、HttpOnly 一起配置。注意旧版浏览器不支持 SameSite只能作为浏览器端辅助加固。8.4 高危操作增加强二次校验对于改密码、换绑手机、转账、注销账号等高风险操作增加强校验输入原密码短信验证码、邮箱验证码人脸验证。就算 CSRF 请求成功发起没有验证码依然无法执行高危操作。8.5 接口开发规范所有新增、修改、删除的写操作接口禁止使用 GET 请求统一 POST接口增加同源策略控制限制跨域访问后端不要信任前端传来的 Referer、自定义 header不可单依靠前端字段做安全校验。8.6 WAF 辅助防护WAF 可以识别常见 CSRF 攻击特征拦截恶意跨站表单请求作为兜底防护。九、新手学习常见误区❌ 误区 1接口需要登录 安全Cookie 自动携带登录凭证存在就有 CSRF 风险。登录验证只是身份校验不是请求来源校验。❌ 误区 2POST 请求无法跨站伪造POST 请求非常容易伪造一段简单 HTML 表单就可以自动提交 POST 数据包。❌ 误区 3CSRF 只能篡改昵称这类无关紧要的内容如果是管理员新增账号接口CSRF 直接接管网站后台属于高危漏洞。❌ 误区 4校验 Referer 就足够防御 CSRFReferer 很容易被清空或者绕过只能辅助不能作为唯一防护手段。❌ 误区 5CSRF 可以读取接口返回数据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实战案例光学理论是没用的要学会跟着一起敲要动手实操才能将自己的所学运用到实际当中去这里带来的是CTFSRC资料HW资料毕竟实战是检验真理的唯一标准嘛~四、网络安全面试题最后我们所有的作为都是为就业服务的所以关键的临门一脚就是咱们的面试题内容所以面试题板块是咱们不可或缺的部分这里我给大家准备的就是我在面试期间准备的资料。网安其实不难难的是坚持和相信自己我的经验是既然已经选定网安你就要相信它相信它能成为你日后进阶的高效渠道这样自己才会更有信念去学习才能在碰到困难的时候坚持下去。机会属于有准备的人这是一个实力的时代。人和人之间的差距不在于智商而在于如何利用业余时间只要你想学习什么时候开始都不晚不要担心这担心那你只需努力剩下的交给时间这份完整版的网络安全学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】