2026/9/14 18:47:18
FEATURED · 精选文章 
1. CSRF到底是个什么东西一份不请自来的“外卖订单”“安全提示疑似跨站请求伪造访问已被禁止。错误编号【ese0102001】。”如果你在某个网站后台操作时突然撞见这句提示大概率会和我第一次见到时一样懵系统没什么异常网络也没断怎么就被拦了后来我排查了半天才弄明白这是企业安全网关检测到当前请求缺少合法的 CSRF 令牌、Referer 异常或者请求来源可疑把它当成了一次潜在的跨站请求伪造拦截掉了。而这个细节恰好把 CSRFCross-Site Request Forgery跨站请求伪造的核心问题暴露得明明白白服务端根本分不清“用户本人发起的请求”和“恶意页面伪造的请求”它只能靠额外的信任凭证来判断。用生活里的场景解释更容易。你去一家餐厅办了会员卡进门时出示过身份服务员就认下“你本人已验证过”。这时候有个陌生人趁你坐在位子上偷偷用你的名义加了一道最贵的招牌菜服务员一看会员卡有效菜就下了单。浏览器里的 Cookie、Session 就是这张“会员卡”——HTTP 协议天生无状态服务端靠它们记住你登录过但浏览器在携带这些凭证时根本不会区分请求是你亲手点的还是某个不相关的页面里自动生成的。跨站请求伪造的名字很绕但拆开就清楚“跨站”指攻击者把恶意请求放在另一个站点上“请求伪造”指请求本身不是用户真实意图而是攻击者构造出来的。而整个攻击成立只需要满足三个前提目标网站使用 Cookie、Session 这类隐式凭证做登录态管理用户的浏览器在访问任何域名时都会自动带上目标域下的 Cookie目标操作接口没有对请求来源做额外的校验比如 Token、Referer 或者二次验证。这三个条件在大量传统 Web 应用里一直存在。很多开发者默认“请求只要带上了正确的 Session就一定是用户本人发的”这是 CSRF 能横行这么多年的根本原因。1.1 浏览器为什么这么“听话”同源策略管得住响应管不住请求初学者最容易卡在同一个问题上浏览器不是有同源策略吗为什么还允许恶意页面把请求发到目标站点这里有一个很关键的区别浏览器的同源策略主要约束的是“读取”——比如 evil.com 上的 JavaScript 默认读不到 baidu.com 的接口响应内容因为跨域响应被隔离了。但它基本不拦截“发送”——只要你发的是简单请求比如 form 表单提交、img 标签加载、a 标签跳转浏览器不仅允许跨站发起还会自动把目标域名下的 Cookie 一并带上。也就是说浏览器对“发出去”和“读回来”执行的是两套标准。举个例子攻击者在自己的网站上放了一行代码img srchttps://bank.example.com/transfer?toattackeramount10000 /当已经登录银行系统的用户访问这个恶意页面时浏览器会向 bank.example.com 发起 GET 请求并且自动附上该域名下的 Cookie。银行接口如果刚好用 GET 接收转账参数这笔钱就在用户完全不知情的情况下转走了。问题在于浏览器“帮”用户做了这件事而用户和服务端都毫无察觉。POST 请求其实也一样攻击者可以用一个隐藏表单form actionhttps://bank.example.com/transfer methodPOST input typehidden nameto valueattacker / input typehidden nameamount value10000 / /form scriptdocument.forms[0].submit();/script用户加载页面的一瞬间表单被 JavaScript 自动提交Cookie 同样被自动携带。这才是 CSRF 最让人头疼的地方——攻击者不需要拿到用户的任何敏感信息只需要诱导用户“访问一个页面”。密码、手机号、验证码什么都不用知道。1.2 和 XSS、SSRF 的区别一个利用信任一个滥用信任我在漏洞挖掘的交流群里经常看到有人把 CSRF、XSS、SSRF 混着说其实三者是三个维度的问题定位完全不同。XSS 是攻击者往正常页面里注入了恶意脚本用户在“可信页面”上执行了不可信的代码本质是破坏页面本身的可信边界。CSRF 则是攻击者利用目标网站对用户浏览器的信任让目标网站在收到请求时误以为这是用户自愿发起的本质是滥用身份凭证。SSRF 又不一样它发生在服务端攻击者诱导服务器去访问内网或者本机资源把服务器当成跳板。用一个表格快速区分漏洞攻击者控制的位置信任对象典型危害XSS页面内的 JavaScript用户在正常页面执行的代码窃取 Cookie、篡改页面、钓鱼CSRF恶意站点上的请求构造服务端对用户 Cookie 的信任改密码、转账、执行敏感操作SSRF服务端发起的请求服务端对内部网络资源的信任读取内网数据、打内网资产实际挖掘中CSRF 经常被当成“低危”漏洞上报这其实是个误区。如果目标接口是修改账号绑定手机号、找回密码、关闭二次验证这类高权限操作CSRF 一旦组合上逻辑缺陷完全可以做到直接接管账号杀伤力一点都不比 XSS 小。后面我会结合具体的挖掘案例详细说。2. 攻击链路拆解从受害者点击到“转账成功”的完整九步很多人理解 CSRF 只知道“构造请求、诱导点击、攻击成功”但真的自己在 SRC 测试或者写 PoC 时经常发现复现不了原因就是对整个链路的前置条件理解不透。我们把一个典型的攻击过程完整拆开按顺序理一遍。攻击者想要让受害者把自己的钱转入指定账户整个链路是这样的受害者正常登录了银行系统 bank.example.com浏览器持有有效的登录 Cookie攻击者在自己的站点 evil.com 上构造了恶意页面页面里包含自动提交的转账表单攻击者通过各种渠道诱导受害者访问 evil.com比如聊天消息里发链接、论坛签名、二维码受害者浏览器加载恶意页面浏览器解析 HTML触发表单自动提交向 bank.example.com 发起 POST 请求浏览器在请求中自动携带受害者名下 bank.example.com 的 Cookie银行服务端检查 Session发现是“已登录用户”发来的请求直接执行转账逻辑转账成功攻击者拿到钱受害者全程没有任何感知事后收到余额提醒才发现钱没了。关键在第 5 到第 7 步。浏览器、用户、服务端三方各认为自己做得没错浏览器只是执行了页面的预期行为用户只是“打开了一个网页”服务端只看到“一个合法登录用户正在转账”。没有一方意识到请求是伪造的。这里有一个从业者必须清楚的事实CSRF 攻击不需要获取 Cookie也完全无法获取 Cookie。攻击者只是“借用”了 Cookie浏览器把凭证自动带上这件事是整个攻击成立的前提。理解了这一层你就明白为什么 https-only Cookie、HttpOnly Cookie 这类安全属性对 CSRF 毫无防御作用。2.1 GET 型 CSRF最省力的攻击姿势GET 型 CSRF 是攻击成本最低的一种因为攻击者连 JavaScript 都不用写一个普通的 img 标签、iframe 或者 a 链接就能触发。但 GET 型 CSRF 能成立有一个隐藏前提目标接口本身设计得“不 RESTful”也就是用 GET 请求处理了有状态变更的操作。我在挖洞时碰到过一个很典型的案例。某企业的后台“导出报表”功能链接长这样https://admin.example.com/export?typefinancedate2024-01-01但如果往后面拼接一个跨站脚本的 demo会发现这个接口不仅会导出数据还会把“用户最后登录时间”更新掉属于典型的“GET 请求干 POST 的活儿”。这种情况下攻击者只需要构造一个链接发给运维人员https://admin.example.com/export?typefinancedate2024-01-01%3BUPDATEadminSETrole%3D%27attacker%27当然这已经属于 CSRF SQL 注入的复合攻击了。更常见的是把“修改个人资料”做成 GET 接口https://www.example.com/user/update?phone138xxxx攻击者只需要让管理员点一下这个带参数的链接管理员手机号就被改成了攻击者的号码后续找回密码、接受验证码全都会发到攻击者手里。这种接口在做漏洞挖掘时优先级非常高因为它一旦存在就是一条完整的账号接管链条。2.2 POST 型 CSRF 与 JSON CSRF不同 Content-Type 下的“免杀”策略POST 型 CSRF 比 GET 型要复杂一点但也有现成的套路。最常见的触发载体就是自动提交的隐藏表单前面已经演示过。不过 POST 型 CSRF 在实战中有一个容易被忽略的点如果服务端校验了 Content-Type比如只接受application/json攻击者的普通表单项就得换个姿势。JSON CSRF 的核心是利用某些旧版本浏览器或者特定场景下可以被跨域发送的请求类型。早期有一种历史悠久的攻击手法script fetch(https://api.example.com/user/changePwd, { method: POST, credentials: include, headers: { Content-Type: application/json }, body: JSON.stringify({ password: hacked123 }) }); /script这里的关键是credentials: include它让 fetch 请求携带目标域名的 Cookie。在现代浏览器里这种跨域 fetch 会触发 CORS 预检预检不通过就无法提交。但要注意CORS 预检挡不住所有的请求如果浏览器自己发的是“简单请求”比如使用text/plain的 POST就完全没有预检环节请求照样能发出去。所以有些服务端为了简单微信支付之类的回调接口用的是text/plain或者application/x-www-form-urlencoded这时候攻击者就可以直接用表单构造同类型的请求。防御这个坑的唯一稳妥手段就是彻底抛开 Content-Type 的侥幸心理老老实实做 Token 校验。2.3 为什么防 CSRF 不能只靠“隐藏接口”我在和开发沟通时经常听到一句话“这个接口的路径很隐蔽攻击者不可能知道。”这句话在安全圈早就被反驳了无数次。接口路径再隐蔽也挡不住以下这些泄露途径JavaScript 文件里一定有接口路径前端代码在前端就是公开的移动端 App 抓包可以直接看到所有接口Web 应用的所有请求都会经过浏览器开发者工具偶尔还会在百度快照、公众号文章、第三方测试报告里出现。就算攻击者不知道具体路径也可以通过字典爆破或者 JS 源码分析把接口找出来。隐藏接口只能提高挖洞门槛不能作为安全控制手段。真正有效的防御方案我放到第 4 章详细说。3. 漏洞挖掘实战从手工验证 Burp Suite 到自动化批量探测讲完理论进入实操环节。CSRF 的漏洞挖掘在很多情况下比 XSS、SQL 注入更“无聊”——它不需要复杂的 payload也不需要绕过过滤核心就是判断服务端到底校验了什么、没校验什么。但就是这么个“无聊”的漏洞在 SRC 平台上依然常年有人提交因为很多企业的新项目、新接口都会出现相似的疏漏。3.1 手工验证的四个关键动作我在挖洞时遇到一个修改收货地址的接口第一步永远是先抓包把请求完整地看一遍POST /api/user/address/update HTTP/1.1 Host: www.example.com Cookie: sessionidabc123... Content-Type: application/x-www-form-urlencoded address_id1024receivertestphone13800138000接下来我通常会做四件事第一步检查请求里有没有 CSRF Token 字段。如果表单里有csrfmiddlewaretoken、token、_token这类参数并且服务端做了校验基本可以判定为安全如果没有 Token进入第二步。第二步把请求扔到 Burp Suite 的 CSRF PoC 生成器里让 Burp 自动生成一个恶意 HTML 页面。这里有个关键操作把生成的 PoC 里的 Cookie、Referer、Origin 等可能暴露攻击者身份的字段全部去掉模拟一个第三方站点发起的请求。很多人复现失败就是因为 PoC 里带了 Burp 自己加的字段导致服务端虽然没校验 Token却校验了 Origin。第三步用一个与目标站点无关的域名做 Referer 测试。我在本地起一个简单的 HTTP 服务把恶意页面部署上去然后打开浏览器访问这个页面在 Burp 的 History 里观察请求是否到达了目标接口、Cookie 是否被携带。如果请求正常到达且服务端返回成功漏洞确认。第四步测试 Token 的随机性和完整校验逻辑。有些系统虽然返回了 Token但服务端只校验“Token 是否存在”不校验“Token 是否和会话绑定”也就是所谓的“会话无关 Token”这种情况下攻击者可以直接把自己的 Token 填进去照样能打。3.2 DVWA 和 Pikachu 靶场入门练手的两块跳板如果你是第一次接触 CSRF不建议直接去 SRC 实战先在靶场里把“判断是否存在 CSRF”的手感练出来会更稳妥。DVWADamn Vulnerable Web Application里的 CSRF 模块是经典入门项目。在 Low 等级下修改密码的请求长这样http://127.0.0.1/dvwa/vulnerabilities/csrf/?password_new123456password_conf123456ChangeChange整个请求没有 Token没有任何校验直接改 GET 参数就能改密码。你把等级调到 Medium 后会发现服务端加了 Referer 校验必须从 DVWA 自己的域名访问才能通过。这个升级过程本身就是一次很好的学习体验先体会“没有任何防御”的原始漏洞再理解“Referer 校验被绕过”的防御缺陷。Pikachu 靶场的 CSRF 模块则更接近真实业务场景它模拟的是“用户修改个人信息”的接口配合逻辑漏洞练习“如何利用 CSRF 完成账号信息篡改”。我在带新人时给的路径很明确DVWA 的低中高三级全部还原一遍然后在 Pikachu 里试着自己不看教程完成一次完整攻击再回到 DVWA 挑战 Impossible 等级看看防御端是怎么做 Token 校验的。3.3 SRC 实战的三个高价值目标靶场练完回到真实业务。SRC 挖 CSRF 时我一般优先盯三类接口第一类是“高价值敏感操作”接口包括修改密码、修改绑定手机号、关闭登录保护、新增 API Key、提现转账。这类接口一旦存在 CSRF漏洞危害直接从“中危”拉到“高危”。你想想如果攻击者能让管理员在不知情的情况下关闭掉风控开关后续的攻击链条会非常顺畅。第二类是“新上线业务”的接口。很多企业会定期发更新日志日志里提到的新功能往往是新代码安全建设的成熟度经常跟不上。比如某企业新推出的“一键同步通讯录”功能接口如果没做 CSRF 防护攻击者可以让受害者把内部通讯录同步给攻击者控制的第三方服务这种数据泄露的价值都高。第三类是“低频率使用”的接口。比如“修改默认收货地址”“设置发票抬头”开发者觉得不重要往往没有套用统一的 CSRF 防护框架。这类接口一旦被组合利用比如配合 XSS 或者钓鱼页面也可以实现长期潜伏的绑定关系篡改。3.4 AI 辅助自动挖掘工具与它的边界最近圈子里“AI 自动挖掘漏洞”的话题很热GitHub 上也确实出现了一些半自动化的 CSRF 扫描工具。这类工具的使用逻辑通常是用爬虫抓取站点的所有接口批量发送不带 Token、修改 Referer 的请求然后观察响应是否出现业务异常。但我不建议在 SRC 实战里完全依赖这类工具原因有三个误报率非常高。很多接口虽然不校验 Token但有频率限制、IP 风控或者短信验证码二次校验工具看到“返回成功”就报漏洞实际上攻击者根本无法在真实场景里复现。CSRF 的“可利用性”完全取决于业务逻辑上下文。同样一个无 Token 的修改昵称接口放在试用账号和支付密码设置上危害完全不同自动化工具很难判断这个上下文。很多 AI 工具本质上就是调一下 nuclei 模板参数配置不合理时反而会给目标站点的系统带来多余的请求负担容易把账号搞风控。我的建议是工具拿来“批量发现候选接口”但最终的验证、危害定级、PoC 构造必须人工完成。AI 目前是加速器不是替代品。4. 防御方案落地从写对代码到守住架构层层设防漏洞挖掘讲完必须讲防御。因为一个真正的安全从业者不能只会找问题还得能给出可落地的解决方案。CSRF 的防御方案已经非常成熟难点从来不是“没有方案”而是“方案没落地到位”或者“方案被错误实现”。4.1 CSRF Token让每个请求都带上服务端发的“暗号”CSRF Token 是应用最广、也是最基础的防御手段。原理很简单服务端每次渲染页面表单时生成一个随机 Token 并存储到 Session 中同时塞进表单的隐藏字段里。用户提交请求时服务端比对请求里的 Token 和 Session 里的 Token 是否一致一致才放行。为什么这个方法能有效防 CSRF因为 Token 是随机的、和会话绑定的、攻击者猜不到的。攻击者可以伪造请求但没法在自己的恶意页面里预先拿到受害者的 Token 值——浏览器同源策略阻止了跨域读取响应内容。代码层面的实现以 Django 为例from django.shortcuts import render from django.views.decorators.csrf import csrf_protect from django.middleware.csrf import get_token csrf_protect def update_profile(request): if request.method POST: # 框架自动校验 CSRF Token # 业务处理逻辑 return render(request, success.html) return render(request, update_profile.html, {csrf_token: get_token(request)})使用成熟的框架时我强烈建议直接启用框架自带的 CSRF 中间件不要自己手写 Token 生成逻辑。自己实现的朴素随机数往往存在熵不足、重复、不绑定 Session 等问题反而引入新的漏洞。Java 生态里 Spring Security 默认就对需要登录的 POST/PUT/DELETE 请求做了 CSRF 防护除非你的服务是纯 API 且不接受浏览器 Cookie 认证否则保持默认开启就好。4.2 SameSite Cookie浏览器层面的第一道防线CSRF 攻击成立的前提是浏览器自动携带 Cookie。如果 Cookie 本身声明了“跨站请求不要带上我”那么攻击链在第一步就被切断了。这就是SameSite属性的价值所在。Set-Cookie: sessionidabc123; SameSiteLax; Secure; HttpOnlySameSite有三个取值取值行为适用场景Strict任何跨站请求都不发送 Cookie内部管理后台、网银等高安全场景Lax跨站顶层导航时发送跨站子请求不发送大多数 Web 应用的默认推荐值None所有跨站请求都发送必须配合 Secure第三方嵌入、SSO 等必须跨站携带的场景Chrome 从 84 版本开始把没有声明SameSite的 Cookie 默认当作Lax处理这是整个行业的安全进步。但只依赖浏览器默认值还不够因为不是所有用户都用新版浏览器也不是所有场景都不允许跨站发送。我见过不少系统用的是SameSiteNone配合第三方登录跳转这种情况下 CSRF Token 就是最后的防线绝对不能省略。4.3 Referer 和 Origin 校验没有 Token 时的退路有些接口因为历史原因或者纯 API 场景不方便做 Token 校验这时可以退而求其次校验请求的来源。从原理上讲如果一个请求是攻击者在 evil.com 上伪造的那么请求头里的Origin或Referer大概率会露出马脚。Origin 校验的推荐写法是ALLOWED_ORIGINS {https://www.example.com, https://m.example.com} def check_origin(request): origin request.headers.get(Origin) if origin and origin not in ALLOWED_ORIGINS: return False return True但这里有一个必须注意的点Origin头不是所有请求都会携带。同源请求时有些浏览器带了 Origin有些浏览器比如部分旧版 Safari 不带。服务端如果发现没有 Origin 就直接拒绝会影响正常用户如果发现没有 Origin 就放行攻击者又能通过强制去掉 Origin 头的 curl 请求打进来。实际项目中我会建议Origin为空时继续看Referer两者都为空则直接拒绝敏感操作宁肯误杀也不要漏防。Referer 校验有一个天然缺陷Referer头可以被浏览器扩展、代理工具、部分旧版本浏览器提前移除而且攻击者在自己的恶意页面里可以用meta namereferrer contentno-referrer强制不发送 Referer。所以 Referer 只能作为辅助不能作为唯一的防护。4.4 双重提交 Cookie 与架构层面的兜底思路除了 Token 和 SameSite常用的还有双重提交 Cookie 方案。它的思路是服务端生成一个随机 Token同时放到 Cookie 和请求参数或请求头里服务端校验两者是否一致。因为攻击者没法在受害者的浏览器里同时写入目标域的 Cookie所以即使能拿到请求参数里的 Token也过不了比对。这种方案的优点是无状态不需要 Session 存储适合分布式架构。但也有使用前提Cookie 不能被攻击方写入也就是要求目标域没有子域类的 Cookie 投递漏洞。架构层面的兜底思路是“默认不给敏感操作放行”。我在不少大型企业里看到更稳妥的做法凡是修改密码、绑定手机号、转账这类高危操作不管 Token 校验结果如何一律要求用户输入原密码或者输入短信验证码。这已经是“人机核验”的概念能直接阻断绝大多数自动化 CSRF 攻击。验证码也能起到类似作用因为攻击者没法在自己的页面里提前获取验证码也没法让用户在一个陌生页面上自动输入。5. 绕过套路与踩坑实录防御和漏洞挖掘都在持续博弈讲过攻、讲过防最后分享一些我在实际测试和企业安全建设中踩过的坑。这部分内容在官方文档里基本看不到但对真正动手做的人非常有价值。5.1 Token 绕过从“删 Token”到“对称可预测”CSRF Token 绕过的第一个经典思路就是“既然服务端校验 Token那我就把请求里的 Token 删掉试试”。不少实现有缺陷的框架在预检请求时发现没有 Token会跳过校验直接进入业务逻辑。我见过一个 Java 老项目用了自定义的拦截器做 CSRF 校验拦截器只处理包含csrf_token参数的请求如果不带参数直接放行。这种错误在“先校验后放行”和“无 Token 直接放行”的边界上只要写错一行防护就形同虚设。第二个经典思路是利用跨站点响应读取之外的途径获取 Token。CSRF Token 通常放在 HTML 表单里同源策略会保护它不被恶意脚本读取但 Token 同样可能出现在 URL 参数、Referer 头、日志系统中。如果某个页面把带 Token 的完整 URL 打印到了日志里或者通过错误信息返回给前端攻击者就有机会通过日志链路侧信道拿到 Token。第三个思路是绕过“会话绑定”。有些系统的 Token 不是存在 Session 里的而是存在单独的 Cookie 里和会话没有任何绑定关系。这种 Token 对所有登录用户是通用的攻击者在自己的账号里申请一个 Token在受害者请求里替换成自己的 Token校验照样能过。还记得我们前面说的“伪造请求时把 Token 换成攻击者自己的”吗这招在实战里复现率极高。5.2 我在企业里见过的五种“看上去防了实际上没防”的部署把这个名单列出来基本上覆盖了企业 CSRF 防护的大部分翻车现场。第一种前端把 Token 放在 Cookie 里却要求前端从 Cookie 里取出来放到请求头里。因为一旦 Token 放在 Cookie 里双重提交反而可能被子域投递绕过。第二种Referer 校验判断的是字符串包含。比如写的是if example.com in referer攻击者在 evil.com 里随便构造一个包含example.com的 Referer就能绕过。我在测试时直接在恶意页面里加了一行meta namereferrer content...就把校验打穿了。第三种只对特定请求头校验 Content-Type 是 JSON 的接口却没有校验 Origin。攻击者用text/plain的请求体照样能触发业务逻辑这种坑在微服务网关层特别常见。第四种Token 校验放在 SPA 前端的路由拦截器里而不是放在后端。我见过某项目把 CSRF Token 校验写进 Vue 路由钩子里等于把安全控制完全交给了客户端随便一个引用静态资源的攻击都能绕过。第五种同一个 Token 不在用户操作后轮换。Token 长期有效、不失效等于攻击者只要有一次拿到 Token后面就可以一直用。正确做法是在每次敏感操作成功后立即把 Session 里的 Token 重新生成一遍。5.3 误报“ESE0102001”这类拦截提示背后的排查思路回到文章开头提到的那个错误提示。如果你在自己的环境中真的遇到“疑似跨站请求伪造访问已被禁止”先别急着怀疑系统被攻击绝大多数场景是误报。我的排查顺序是这样的先看请求头。打开浏览器开发者工具对比“正常操作”和“触发拦截”两个请求的差异重点看Referer、Origin、Cookie三个字段。很多网关的逻辑是请求没有带 Referer但目标接口是敏感操作就直接拦截。再看是否依赖了第三方链接。有些服务端逻辑是通过 URL 参数里的回调地址做跳转跳转过程丢失了 Session 里的 Token导致请求被网关判定为 CSRF。去年的一个案例里用户从企业微信点开内部 OA 链接经过一次重定向后 Token 丢失结果被自己的安全网关拦了。最后确认网关策略的松紧度。在配置安全网关时我建议对内部系统采用“宽松模式 重点接口强校验”的组合对所有写操作统一启用 CSRF 校验对外部用户系统则要仔细评估 Origin 白名单避免把移动端 App 的请求也误判成跨站请求。防御 CSRF 不是写一段代码那么简单它要求你真正理解 HTTP 的状态管理机制、浏览器的跨域行为以及业务系统的信任边界。每次评估一个接口时我脑子里都会过一遍这个问题如果我是攻击者站在 evil.com 上怎么用尽可能少的条件让这个接口替我做一件不被用户知道的事这个思路不管是做漏洞挖掘还是做安全建设都比背任何一份清单都管用。
CSRF跨站请求伪造从原理到防御：Token、SameSite与漏洞挖掘实战
1. CSRF到底是个什么东西一份不请自来的“外卖订单”“安全提示疑似跨站请求伪造访问已被禁止。错误编号【ese0102001】。”如果你在某个网站后台操作时突然撞见这句提示大概率会和我第一次见到时一样懵系统没什么异常网络也没断怎么就被拦了后来我排查了半天才弄明白这是企业安全网关检测到当前请求缺少合法的 CSRF 令牌、Referer 异常或者请求来源可疑把它当成了一次潜在的跨站请求伪造拦截掉了。而这个细节恰好把 CSRFCross-Site Request Forgery跨站请求伪造的核心问题暴露得明明白白服务端根本分不清“用户本人发起的请求”和“恶意页面伪造的请求”它只能靠额外的信任凭证来判断。用生活里的场景解释更容易。你去一家餐厅办了会员卡进门时出示过身份服务员就认下“你本人已验证过”。这时候有个陌生人趁你坐在位子上偷偷用你的名义加了一道最贵的招牌菜服务员一看会员卡有效菜就下了单。浏览器里的 Cookie、Session 就是这张“会员卡”——HTTP 协议天生无状态服务端靠它们记住你登录过但浏览器在携带这些凭证时根本不会区分请求是你亲手点的还是某个不相关的页面里自动生成的。跨站请求伪造的名字很绕但拆开就清楚“跨站”指攻击者把恶意请求放在另一个站点上“请求伪造”指请求本身不是用户真实意图而是攻击者构造出来的。而整个攻击成立只需要满足三个前提目标网站使用 Cookie、Session 这类隐式凭证做登录态管理用户的浏览器在访问任何域名时都会自动带上目标域下的 Cookie目标操作接口没有对请求来源做额外的校验比如 Token、Referer 或者二次验证。这三个条件在大量传统 Web 应用里一直存在。很多开发者默认“请求只要带上了正确的 Session就一定是用户本人发的”这是 CSRF 能横行这么多年的根本原因。1.1 浏览器为什么这么“听话”同源策略管得住响应管不住请求初学者最容易卡在同一个问题上浏览器不是有同源策略吗为什么还允许恶意页面把请求发到目标站点这里有一个很关键的区别浏览器的同源策略主要约束的是“读取”——比如 evil.com 上的 JavaScript 默认读不到 baidu.com 的接口响应内容因为跨域响应被隔离了。但它基本不拦截“发送”——只要你发的是简单请求比如 form 表单提交、img 标签加载、a 标签跳转浏览器不仅允许跨站发起还会自动把目标域名下的 Cookie 一并带上。也就是说浏览器对“发出去”和“读回来”执行的是两套标准。举个例子攻击者在自己的网站上放了一行代码img srchttps://bank.example.com/transfer?toattackeramount10000 /当已经登录银行系统的用户访问这个恶意页面时浏览器会向 bank.example.com 发起 GET 请求并且自动附上该域名下的 Cookie。银行接口如果刚好用 GET 接收转账参数这笔钱就在用户完全不知情的情况下转走了。问题在于浏览器“帮”用户做了这件事而用户和服务端都毫无察觉。POST 请求其实也一样攻击者可以用一个隐藏表单form actionhttps://bank.example.com/transfer methodPOST input typehidden nameto valueattacker / input typehidden nameamount value10000 / /form scriptdocument.forms[0].submit();/script用户加载页面的一瞬间表单被 JavaScript 自动提交Cookie 同样被自动携带。这才是 CSRF 最让人头疼的地方——攻击者不需要拿到用户的任何敏感信息只需要诱导用户“访问一个页面”。密码、手机号、验证码什么都不用知道。1.2 和 XSS、SSRF 的区别一个利用信任一个滥用信任我在漏洞挖掘的交流群里经常看到有人把 CSRF、XSS、SSRF 混着说其实三者是三个维度的问题定位完全不同。XSS 是攻击者往正常页面里注入了恶意脚本用户在“可信页面”上执行了不可信的代码本质是破坏页面本身的可信边界。CSRF 则是攻击者利用目标网站对用户浏览器的信任让目标网站在收到请求时误以为这是用户自愿发起的本质是滥用身份凭证。SSRF 又不一样它发生在服务端攻击者诱导服务器去访问内网或者本机资源把服务器当成跳板。用一个表格快速区分漏洞攻击者控制的位置信任对象典型危害XSS页面内的 JavaScript用户在正常页面执行的代码窃取 Cookie、篡改页面、钓鱼CSRF恶意站点上的请求构造服务端对用户 Cookie 的信任改密码、转账、执行敏感操作SSRF服务端发起的请求服务端对内部网络资源的信任读取内网数据、打内网资产实际挖掘中CSRF 经常被当成“低危”漏洞上报这其实是个误区。如果目标接口是修改账号绑定手机号、找回密码、关闭二次验证这类高权限操作CSRF 一旦组合上逻辑缺陷完全可以做到直接接管账号杀伤力一点都不比 XSS 小。后面我会结合具体的挖掘案例详细说。2. 攻击链路拆解从受害者点击到“转账成功”的完整九步很多人理解 CSRF 只知道“构造请求、诱导点击、攻击成功”但真的自己在 SRC 测试或者写 PoC 时经常发现复现不了原因就是对整个链路的前置条件理解不透。我们把一个典型的攻击过程完整拆开按顺序理一遍。攻击者想要让受害者把自己的钱转入指定账户整个链路是这样的受害者正常登录了银行系统 bank.example.com浏览器持有有效的登录 Cookie攻击者在自己的站点 evil.com 上构造了恶意页面页面里包含自动提交的转账表单攻击者通过各种渠道诱导受害者访问 evil.com比如聊天消息里发链接、论坛签名、二维码受害者浏览器加载恶意页面浏览器解析 HTML触发表单自动提交向 bank.example.com 发起 POST 请求浏览器在请求中自动携带受害者名下 bank.example.com 的 Cookie银行服务端检查 Session发现是“已登录用户”发来的请求直接执行转账逻辑转账成功攻击者拿到钱受害者全程没有任何感知事后收到余额提醒才发现钱没了。关键在第 5 到第 7 步。浏览器、用户、服务端三方各认为自己做得没错浏览器只是执行了页面的预期行为用户只是“打开了一个网页”服务端只看到“一个合法登录用户正在转账”。没有一方意识到请求是伪造的。这里有一个从业者必须清楚的事实CSRF 攻击不需要获取 Cookie也完全无法获取 Cookie。攻击者只是“借用”了 Cookie浏览器把凭证自动带上这件事是整个攻击成立的前提。理解了这一层你就明白为什么 https-only Cookie、HttpOnly Cookie 这类安全属性对 CSRF 毫无防御作用。2.1 GET 型 CSRF最省力的攻击姿势GET 型 CSRF 是攻击成本最低的一种因为攻击者连 JavaScript 都不用写一个普通的 img 标签、iframe 或者 a 链接就能触发。但 GET 型 CSRF 能成立有一个隐藏前提目标接口本身设计得“不 RESTful”也就是用 GET 请求处理了有状态变更的操作。我在挖洞时碰到过一个很典型的案例。某企业的后台“导出报表”功能链接长这样https://admin.example.com/export?typefinancedate2024-01-01但如果往后面拼接一个跨站脚本的 demo会发现这个接口不仅会导出数据还会把“用户最后登录时间”更新掉属于典型的“GET 请求干 POST 的活儿”。这种情况下攻击者只需要构造一个链接发给运维人员https://admin.example.com/export?typefinancedate2024-01-01%3BUPDATEadminSETrole%3D%27attacker%27当然这已经属于 CSRF SQL 注入的复合攻击了。更常见的是把“修改个人资料”做成 GET 接口https://www.example.com/user/update?phone138xxxx攻击者只需要让管理员点一下这个带参数的链接管理员手机号就被改成了攻击者的号码后续找回密码、接受验证码全都会发到攻击者手里。这种接口在做漏洞挖掘时优先级非常高因为它一旦存在就是一条完整的账号接管链条。2.2 POST 型 CSRF 与 JSON CSRF不同 Content-Type 下的“免杀”策略POST 型 CSRF 比 GET 型要复杂一点但也有现成的套路。最常见的触发载体就是自动提交的隐藏表单前面已经演示过。不过 POST 型 CSRF 在实战中有一个容易被忽略的点如果服务端校验了 Content-Type比如只接受application/json攻击者的普通表单项就得换个姿势。JSON CSRF 的核心是利用某些旧版本浏览器或者特定场景下可以被跨域发送的请求类型。早期有一种历史悠久的攻击手法script fetch(https://api.example.com/user/changePwd, { method: POST, credentials: include, headers: { Content-Type: application/json }, body: JSON.stringify({ password: hacked123 }) }); /script这里的关键是credentials: include它让 fetch 请求携带目标域名的 Cookie。在现代浏览器里这种跨域 fetch 会触发 CORS 预检预检不通过就无法提交。但要注意CORS 预检挡不住所有的请求如果浏览器自己发的是“简单请求”比如使用text/plain的 POST就完全没有预检环节请求照样能发出去。所以有些服务端为了简单微信支付之类的回调接口用的是text/plain或者application/x-www-form-urlencoded这时候攻击者就可以直接用表单构造同类型的请求。防御这个坑的唯一稳妥手段就是彻底抛开 Content-Type 的侥幸心理老老实实做 Token 校验。2.3 为什么防 CSRF 不能只靠“隐藏接口”我在和开发沟通时经常听到一句话“这个接口的路径很隐蔽攻击者不可能知道。”这句话在安全圈早就被反驳了无数次。接口路径再隐蔽也挡不住以下这些泄露途径JavaScript 文件里一定有接口路径前端代码在前端就是公开的移动端 App 抓包可以直接看到所有接口Web 应用的所有请求都会经过浏览器开发者工具偶尔还会在百度快照、公众号文章、第三方测试报告里出现。就算攻击者不知道具体路径也可以通过字典爆破或者 JS 源码分析把接口找出来。隐藏接口只能提高挖洞门槛不能作为安全控制手段。真正有效的防御方案我放到第 4 章详细说。3. 漏洞挖掘实战从手工验证 Burp Suite 到自动化批量探测讲完理论进入实操环节。CSRF 的漏洞挖掘在很多情况下比 XSS、SQL 注入更“无聊”——它不需要复杂的 payload也不需要绕过过滤核心就是判断服务端到底校验了什么、没校验什么。但就是这么个“无聊”的漏洞在 SRC 平台上依然常年有人提交因为很多企业的新项目、新接口都会出现相似的疏漏。3.1 手工验证的四个关键动作我在挖洞时遇到一个修改收货地址的接口第一步永远是先抓包把请求完整地看一遍POST /api/user/address/update HTTP/1.1 Host: www.example.com Cookie: sessionidabc123... Content-Type: application/x-www-form-urlencoded address_id1024receivertestphone13800138000接下来我通常会做四件事第一步检查请求里有没有 CSRF Token 字段。如果表单里有csrfmiddlewaretoken、token、_token这类参数并且服务端做了校验基本可以判定为安全如果没有 Token进入第二步。第二步把请求扔到 Burp Suite 的 CSRF PoC 生成器里让 Burp 自动生成一个恶意 HTML 页面。这里有个关键操作把生成的 PoC 里的 Cookie、Referer、Origin 等可能暴露攻击者身份的字段全部去掉模拟一个第三方站点发起的请求。很多人复现失败就是因为 PoC 里带了 Burp 自己加的字段导致服务端虽然没校验 Token却校验了 Origin。第三步用一个与目标站点无关的域名做 Referer 测试。我在本地起一个简单的 HTTP 服务把恶意页面部署上去然后打开浏览器访问这个页面在 Burp 的 History 里观察请求是否到达了目标接口、Cookie 是否被携带。如果请求正常到达且服务端返回成功漏洞确认。第四步测试 Token 的随机性和完整校验逻辑。有些系统虽然返回了 Token但服务端只校验“Token 是否存在”不校验“Token 是否和会话绑定”也就是所谓的“会话无关 Token”这种情况下攻击者可以直接把自己的 Token 填进去照样能打。3.2 DVWA 和 Pikachu 靶场入门练手的两块跳板如果你是第一次接触 CSRF不建议直接去 SRC 实战先在靶场里把“判断是否存在 CSRF”的手感练出来会更稳妥。DVWADamn Vulnerable Web Application里的 CSRF 模块是经典入门项目。在 Low 等级下修改密码的请求长这样http://127.0.0.1/dvwa/vulnerabilities/csrf/?password_new123456password_conf123456ChangeChange整个请求没有 Token没有任何校验直接改 GET 参数就能改密码。你把等级调到 Medium 后会发现服务端加了 Referer 校验必须从 DVWA 自己的域名访问才能通过。这个升级过程本身就是一次很好的学习体验先体会“没有任何防御”的原始漏洞再理解“Referer 校验被绕过”的防御缺陷。Pikachu 靶场的 CSRF 模块则更接近真实业务场景它模拟的是“用户修改个人信息”的接口配合逻辑漏洞练习“如何利用 CSRF 完成账号信息篡改”。我在带新人时给的路径很明确DVWA 的低中高三级全部还原一遍然后在 Pikachu 里试着自己不看教程完成一次完整攻击再回到 DVWA 挑战 Impossible 等级看看防御端是怎么做 Token 校验的。3.3 SRC 实战的三个高价值目标靶场练完回到真实业务。SRC 挖 CSRF 时我一般优先盯三类接口第一类是“高价值敏感操作”接口包括修改密码、修改绑定手机号、关闭登录保护、新增 API Key、提现转账。这类接口一旦存在 CSRF漏洞危害直接从“中危”拉到“高危”。你想想如果攻击者能让管理员在不知情的情况下关闭掉风控开关后续的攻击链条会非常顺畅。第二类是“新上线业务”的接口。很多企业会定期发更新日志日志里提到的新功能往往是新代码安全建设的成熟度经常跟不上。比如某企业新推出的“一键同步通讯录”功能接口如果没做 CSRF 防护攻击者可以让受害者把内部通讯录同步给攻击者控制的第三方服务这种数据泄露的价值都高。第三类是“低频率使用”的接口。比如“修改默认收货地址”“设置发票抬头”开发者觉得不重要往往没有套用统一的 CSRF 防护框架。这类接口一旦被组合利用比如配合 XSS 或者钓鱼页面也可以实现长期潜伏的绑定关系篡改。3.4 AI 辅助自动挖掘工具与它的边界最近圈子里“AI 自动挖掘漏洞”的话题很热GitHub 上也确实出现了一些半自动化的 CSRF 扫描工具。这类工具的使用逻辑通常是用爬虫抓取站点的所有接口批量发送不带 Token、修改 Referer 的请求然后观察响应是否出现业务异常。但我不建议在 SRC 实战里完全依赖这类工具原因有三个误报率非常高。很多接口虽然不校验 Token但有频率限制、IP 风控或者短信验证码二次校验工具看到“返回成功”就报漏洞实际上攻击者根本无法在真实场景里复现。CSRF 的“可利用性”完全取决于业务逻辑上下文。同样一个无 Token 的修改昵称接口放在试用账号和支付密码设置上危害完全不同自动化工具很难判断这个上下文。很多 AI 工具本质上就是调一下 nuclei 模板参数配置不合理时反而会给目标站点的系统带来多余的请求负担容易把账号搞风控。我的建议是工具拿来“批量发现候选接口”但最终的验证、危害定级、PoC 构造必须人工完成。AI 目前是加速器不是替代品。4. 防御方案落地从写对代码到守住架构层层设防漏洞挖掘讲完必须讲防御。因为一个真正的安全从业者不能只会找问题还得能给出可落地的解决方案。CSRF 的防御方案已经非常成熟难点从来不是“没有方案”而是“方案没落地到位”或者“方案被错误实现”。4.1 CSRF Token让每个请求都带上服务端发的“暗号”CSRF Token 是应用最广、也是最基础的防御手段。原理很简单服务端每次渲染页面表单时生成一个随机 Token 并存储到 Session 中同时塞进表单的隐藏字段里。用户提交请求时服务端比对请求里的 Token 和 Session 里的 Token 是否一致一致才放行。为什么这个方法能有效防 CSRF因为 Token 是随机的、和会话绑定的、攻击者猜不到的。攻击者可以伪造请求但没法在自己的恶意页面里预先拿到受害者的 Token 值——浏览器同源策略阻止了跨域读取响应内容。代码层面的实现以 Django 为例from django.shortcuts import render from django.views.decorators.csrf import csrf_protect from django.middleware.csrf import get_token csrf_protect def update_profile(request): if request.method POST: # 框架自动校验 CSRF Token # 业务处理逻辑 return render(request, success.html) return render(request, update_profile.html, {csrf_token: get_token(request)})使用成熟的框架时我强烈建议直接启用框架自带的 CSRF 中间件不要自己手写 Token 生成逻辑。自己实现的朴素随机数往往存在熵不足、重复、不绑定 Session 等问题反而引入新的漏洞。Java 生态里 Spring Security 默认就对需要登录的 POST/PUT/DELETE 请求做了 CSRF 防护除非你的服务是纯 API 且不接受浏览器 Cookie 认证否则保持默认开启就好。4.2 SameSite Cookie浏览器层面的第一道防线CSRF 攻击成立的前提是浏览器自动携带 Cookie。如果 Cookie 本身声明了“跨站请求不要带上我”那么攻击链在第一步就被切断了。这就是SameSite属性的价值所在。Set-Cookie: sessionidabc123; SameSiteLax; Secure; HttpOnlySameSite有三个取值取值行为适用场景Strict任何跨站请求都不发送 Cookie内部管理后台、网银等高安全场景Lax跨站顶层导航时发送跨站子请求不发送大多数 Web 应用的默认推荐值None所有跨站请求都发送必须配合 Secure第三方嵌入、SSO 等必须跨站携带的场景Chrome 从 84 版本开始把没有声明SameSite的 Cookie 默认当作Lax处理这是整个行业的安全进步。但只依赖浏览器默认值还不够因为不是所有用户都用新版浏览器也不是所有场景都不允许跨站发送。我见过不少系统用的是SameSiteNone配合第三方登录跳转这种情况下 CSRF Token 就是最后的防线绝对不能省略。4.3 Referer 和 Origin 校验没有 Token 时的退路有些接口因为历史原因或者纯 API 场景不方便做 Token 校验这时可以退而求其次校验请求的来源。从原理上讲如果一个请求是攻击者在 evil.com 上伪造的那么请求头里的Origin或Referer大概率会露出马脚。Origin 校验的推荐写法是ALLOWED_ORIGINS {https://www.example.com, https://m.example.com} def check_origin(request): origin request.headers.get(Origin) if origin and origin not in ALLOWED_ORIGINS: return False return True但这里有一个必须注意的点Origin头不是所有请求都会携带。同源请求时有些浏览器带了 Origin有些浏览器比如部分旧版 Safari 不带。服务端如果发现没有 Origin 就直接拒绝会影响正常用户如果发现没有 Origin 就放行攻击者又能通过强制去掉 Origin 头的 curl 请求打进来。实际项目中我会建议Origin为空时继续看Referer两者都为空则直接拒绝敏感操作宁肯误杀也不要漏防。Referer 校验有一个天然缺陷Referer头可以被浏览器扩展、代理工具、部分旧版本浏览器提前移除而且攻击者在自己的恶意页面里可以用meta namereferrer contentno-referrer强制不发送 Referer。所以 Referer 只能作为辅助不能作为唯一的防护。4.4 双重提交 Cookie 与架构层面的兜底思路除了 Token 和 SameSite常用的还有双重提交 Cookie 方案。它的思路是服务端生成一个随机 Token同时放到 Cookie 和请求参数或请求头里服务端校验两者是否一致。因为攻击者没法在受害者的浏览器里同时写入目标域的 Cookie所以即使能拿到请求参数里的 Token也过不了比对。这种方案的优点是无状态不需要 Session 存储适合分布式架构。但也有使用前提Cookie 不能被攻击方写入也就是要求目标域没有子域类的 Cookie 投递漏洞。架构层面的兜底思路是“默认不给敏感操作放行”。我在不少大型企业里看到更稳妥的做法凡是修改密码、绑定手机号、转账这类高危操作不管 Token 校验结果如何一律要求用户输入原密码或者输入短信验证码。这已经是“人机核验”的概念能直接阻断绝大多数自动化 CSRF 攻击。验证码也能起到类似作用因为攻击者没法在自己的页面里提前获取验证码也没法让用户在一个陌生页面上自动输入。5. 绕过套路与踩坑实录防御和漏洞挖掘都在持续博弈讲过攻、讲过防最后分享一些我在实际测试和企业安全建设中踩过的坑。这部分内容在官方文档里基本看不到但对真正动手做的人非常有价值。5.1 Token 绕过从“删 Token”到“对称可预测”CSRF Token 绕过的第一个经典思路就是“既然服务端校验 Token那我就把请求里的 Token 删掉试试”。不少实现有缺陷的框架在预检请求时发现没有 Token会跳过校验直接进入业务逻辑。我见过一个 Java 老项目用了自定义的拦截器做 CSRF 校验拦截器只处理包含csrf_token参数的请求如果不带参数直接放行。这种错误在“先校验后放行”和“无 Token 直接放行”的边界上只要写错一行防护就形同虚设。第二个经典思路是利用跨站点响应读取之外的途径获取 Token。CSRF Token 通常放在 HTML 表单里同源策略会保护它不被恶意脚本读取但 Token 同样可能出现在 URL 参数、Referer 头、日志系统中。如果某个页面把带 Token 的完整 URL 打印到了日志里或者通过错误信息返回给前端攻击者就有机会通过日志链路侧信道拿到 Token。第三个思路是绕过“会话绑定”。有些系统的 Token 不是存在 Session 里的而是存在单独的 Cookie 里和会话没有任何绑定关系。这种 Token 对所有登录用户是通用的攻击者在自己的账号里申请一个 Token在受害者请求里替换成自己的 Token校验照样能过。还记得我们前面说的“伪造请求时把 Token 换成攻击者自己的”吗这招在实战里复现率极高。5.2 我在企业里见过的五种“看上去防了实际上没防”的部署把这个名单列出来基本上覆盖了企业 CSRF 防护的大部分翻车现场。第一种前端把 Token 放在 Cookie 里却要求前端从 Cookie 里取出来放到请求头里。因为一旦 Token 放在 Cookie 里双重提交反而可能被子域投递绕过。第二种Referer 校验判断的是字符串包含。比如写的是if example.com in referer攻击者在 evil.com 里随便构造一个包含example.com的 Referer就能绕过。我在测试时直接在恶意页面里加了一行meta namereferrer content...就把校验打穿了。第三种只对特定请求头校验 Content-Type 是 JSON 的接口却没有校验 Origin。攻击者用text/plain的请求体照样能触发业务逻辑这种坑在微服务网关层特别常见。第四种Token 校验放在 SPA 前端的路由拦截器里而不是放在后端。我见过某项目把 CSRF Token 校验写进 Vue 路由钩子里等于把安全控制完全交给了客户端随便一个引用静态资源的攻击都能绕过。第五种同一个 Token 不在用户操作后轮换。Token 长期有效、不失效等于攻击者只要有一次拿到 Token后面就可以一直用。正确做法是在每次敏感操作成功后立即把 Session 里的 Token 重新生成一遍。5.3 误报“ESE0102001”这类拦截提示背后的排查思路回到文章开头提到的那个错误提示。如果你在自己的环境中真的遇到“疑似跨站请求伪造访问已被禁止”先别急着怀疑系统被攻击绝大多数场景是误报。我的排查顺序是这样的先看请求头。打开浏览器开发者工具对比“正常操作”和“触发拦截”两个请求的差异重点看Referer、Origin、Cookie三个字段。很多网关的逻辑是请求没有带 Referer但目标接口是敏感操作就直接拦截。再看是否依赖了第三方链接。有些服务端逻辑是通过 URL 参数里的回调地址做跳转跳转过程丢失了 Session 里的 Token导致请求被网关判定为 CSRF。去年的一个案例里用户从企业微信点开内部 OA 链接经过一次重定向后 Token 丢失结果被自己的安全网关拦了。最后确认网关策略的松紧度。在配置安全网关时我建议对内部系统采用“宽松模式 重点接口强校验”的组合对所有写操作统一启用 CSRF 校验对外部用户系统则要仔细评估 Origin 白名单避免把移动端 App 的请求也误判成跨站请求。防御 CSRF 不是写一段代码那么简单它要求你真正理解 HTTP 的状态管理机制、浏览器的跨域行为以及业务系统的信任边界。每次评估一个接口时我脑子里都会过一遍这个问题如果我是攻击者站在 evil.com 上怎么用尽可能少的条件让这个接口替我做一件不被用户知道的事这个思路不管是做漏洞挖掘还是做安全建设都比背任何一份清单都管用。 
