CSRF跨站请求伪造是我在给多个Web项目做安全评审时最常被开发者低估的一类漏洞。相比SQL注入或XSS那种“直接打进来”的攻击方式CSRF更像是“借刀杀人”——攻击者不碰你的服务器而是利用浏览器自动携带Cookie的机制伪造一个合法用户的请求让服务器误以为是用户本人在操作。这篇文章就用一个完整的实操案例把CSRF从原理到攻击复现再到防护落地一整套流程拆开讲清楚适合刚接触Web安全的开发者也适合需要给老项目补安全策略的技术负责人。1. 内容整体设计与思路拆解1.1 CSRF的本质一切问题出在“身份凭证自动携带”上要理解CSRF先得搞清楚一个关键机制浏览器在发出请求时会根据目标域名自动携带该域名下的Cookie这个过程完全由浏览器自己完成页面里的JavaScript根本插不上手。这个设计本来是为了方便用户保持登录态但同时也埋下了隐患——服务器收到请求时只能看到“这个请求带着合法用户的Cookie”却无法判断这个请求究竟是用户主动发起的还是某个恶意页面里偷偷发起的。举个例子我用某银行系统管理后台时登录成功后服务端会下发一个SessionId到Cookie里。只要我在这台浏览器上继续访问该后台的任意接口请求头里都会自动带上这个SessionId。如果此时我在另一个浏览器标签页打开了一个恶意站点而那个站点里有一个自动提交的隐藏表单表单的action指向银行后台的“修改邮箱”接口那么浏览器向银行后台发起请求时一样会带上SessionId。服务端一看哟合法用户的会话放行。整个过程用户毫不知情服务器也无法辨别真伪。这也是CSRF和XSS最本质的区别XSS是攻击者往你的页面里注入脚本直接在你的浏览器里执行而CSRF则是在第三方页面里伪造请求借你的身份发送出去。XSS需要找到一个可注入的点CSRF只需要你“正在登录着目标站点”这一个条件。1.2 一个成功的CSRF攻击需要满足哪些条件从攻击者视角来看一次成功的CSRF攻击通常要凑齐四个要素第一目标站点存在一个“状态变更类”接口比如改密码、改邮箱、转账、删除资源、发表评论等而且这个接口只依赖Cookie来识别用户身份。第二这个接口的请求参数可以被攻击者预先猜到或者至少大部分参数是固定的。如果接口要求一个随机的、只有用户自己才知道的动态令牌攻击者就无法构造有效的请求。第三用户访问目标站点时仍处于有效的登录状态Cookie没有过期。第四用户必须在同一浏览器里访问了攻击者控制的恶意页面无论是通过诱导点击还是单纯扫了一眼带链接的邮件。这四个要素前两个是目标站点的问题后两个是用户侧的条件。所以CSRF的防护思路也很清晰要么让攻击者无法预测请求参数Token机制要么让浏览器不再无条件地携带CookieSameSite属性要么让服务器能在请求里辨别出真实来源自定义请求头、Referer校验。1.3 危害分级不是所有CSRF都只是“改个昵称”CSRF的危害和接口的重要程度强相关。低危场景比如改个头像、换一下主题颜色顶多算骚扰。但高危场景堪称致命电商平台的收货地址被篡改可能导致包裹被劫持管理后台的“修改管理员权限”接口被利用等于直接把系统最高权限交给攻击者在线支付系统的“转账”接口被伪造用户的资金会直接打到攻击者账户上。我在给某公司内部的工单系统做安全评审时就发现过一个实际存在的CSRF隐患该系统的“重置用户密码”接口完全依赖Session认证管理员登录后攻击者只要诱导管理员访问一个恶意页面就能通过自动提交表单把任意用户的密码重置成攻击者指定的值。最棘手的是这类后台系统通常部署在内网运营人员不认为内网系统会遭受攻击于是连最基本的Token校验都没有做。所以无论内网还是外网CSRF的防护标准都应该一视同仁。1.4 为什么CSRF经常被开发者忽略CSRF不像XSS可以在页面里看到实际弹窗效果也不像SQL注入能直接拉出数据库内容。它是一个“看不见”的漏洞——攻击结束后用户看到的结果只是“我的密码怎么改了”“我没买东西啊怎么多了个订单”。很多开发者测试时用自己的账号操作一遍流程发现一切正常就认为系统是安全的却忽略了“这个请求换一个来源是否依然会被信任”这个问题。还有一个现实原因早期的Web开发教材重点讲的都是输入校验和SQL注入对CSRF的讲解往往一笔带过。加上一些前后端分离项目在开发阶段就全量开启了跨域接口开发者在本地调试时习惯了“裸奔”上线后忘了补上防护留下了大量可被CSRF利用的接口。这也是我写这篇实操案例的原因——用一次完整的攻击和防护演示把问题彻底说透。2. 核心细节解析与实操要点2.1 攻击链路拆解从用户登录到请求伪造每一步都在干什么我习惯把一次完整的CSRF攻击拆成五个阶段方便在排查时逐一对照阶段一用户登录目标站点。用户在浏览器里访问某系统假设域名是app.demo.com输入账号密码登录成功后服务器下发一个会话标识浏览器把它存放在Cookie里。阶段二用户未登出同时访问了恶意页面。用户没有关闭浏览器而是继续浏览网页点开了一封邮件里的链接或直接访问了攻击者布置的页面假设域名是evil.example.com。阶段三恶意页面自动触发请求。恶意页面里有隐藏表单、img标签或JavaScript脚本页面一加载就自动向app.demo.com发出请求。此时浏览器会根据同源策略放行跨域请求的发送只是限制了读取响应结果而请求本身照发不误。阶段四浏览器自动携带Cookie。请求真正发出时浏览器检查目标域名app.demo.com发现当前浏览器的Cookie中存有该域名的会话标识于是自动加到请求头里。阶段五服务端处理请求。服务端只校验了会话是否有效并未校验请求的发起来源于是执行了状态变更操作攻击成功。这里有一个极其关键的细节值得注意浏览器同源策略禁止JavaScript读取跨域响应但不禁止发送跨域请求。很多开发者误以为“跨域请求会被浏览器拦截”实际上被拦截的只是响应读取表单提交、图片加载、脚本加载这些请求照样能发出去。CSRF攻击利用的正是这个不对称的策略。2.2 携带Cookie的机制SameSite属性到底管不管用现代浏览器普遍支持Cookie的SameSite属性取值有三个Strict、Lax、None。SameSiteStrict时浏览器在任何跨站场景下都不会携带Cookie这种设置最安全但用户体验比较差。用户从第三方链接跳转到目标站点时会话Cookie丢失需要重新登录。所以这个值适合用于那些不依赖第三方跳转的业务比如管理后台。SameSiteLax是Chrome浏览器近年来的默认值它允许在顶级导航场景下携带Cookie也就是用户点击链接从外部站点跳转到目标站点时Cookie会带上但通过iframe内嵌、img标签、AJAX发起的子请求Cookie不会携带。这个取值能拦截掉大部分CSRF攻击但有一个缺口如果目标接口支持别名为链接导航的GET请求并且业务上允许GET方法执行状态变更那么点击链接也能触发CSRF。所以Lax适合与“禁止GET方法修改状态”的规范配合使用。SameSiteNone必须配合Secure属性一起使用也就是仅限HTTPS场景。它表示浏览器在所有场景下都携带Cookie相当于关闭了这层防护最危险。只有当下有明确的跨站业务需求才考虑用这个取值。实际操作中我见过很多系统把Cookie的SameSite显式设置成None理由很简单“因为有跨域调用需求”。结果跨域业务没跑起来CSRF防护倒是先被自己亲手关了。这里要说明的是SameSite是Cookie属性层面的防护不是唯一手段不能因为设置了Lax就以为高枕无忧也不能因为业务需要跨站就彻底放弃其他防护方案。2.3 攻击向量细说不只是隐藏表单这一种姿势提到CSRF的POC很多文章只写了隐藏表单自动提交但实际攻击向量比这丰富得多。第一种是HTML表单自动提交。这是最经典的姿势用一个隐藏的form表单加载时调用JavaScript的form.submit()方法。优点是不受同源策略限制支持POST和GET适合接口接收常规表单字段的请求。第二种是图片标签伪造GET请求。如果目标接口用GET方法执行状态变更比如通过请求参数删除一条记录、激活账户等攻击者只需构造一个带src的img标签浏览器加载页面时就会自动发出这个GET请求。由于img标签发出的请求带Referer但这并不能阻止请求发送出去。第三种是XMLHttpRequest或fetch。这种方式适合接口返回JSON且Content-Type为application/json的场景。需要注意跨域XHR请求会触发预检请求OPTIONS如果目标接口没有正确处理OPTIONS攻击还是会失败。但在过去很长一段时间里一些老系统的接口设计并不规范开发者在后端只做了“放行所有OPTIONS请求”的处理导致这部分请求也能被利用。第四种是JSONP接口。如果目标站点存在JSONP回调接口攻击者可以通过script标签触发请求还能读取返回内容虽然这和纯CSRF不是同一个问题但攻击效果被放大了。我在评估风险时通常把JSONP问题单独排查因为它涉及的不仅是CSRF还可能造成数据泄露。2.4 容易忽略的CSRF变形场景不止“登录态”还有一个容易被忽略的变形场景不依赖Cookie的CSRF。单页应用项目如果采用Token放在localStorage里的方式认证浏览器不会自动携带这些Token所以常规强制浏览器发起请求的方式无法利用CSRF。但有些项目会把Token放在URL参数或请求头里请求头必须通过自定义脚本添加浏览器没法自动完成反而天然防了一手。真正容易出问题的是基础认证Basic Auth和摘要认证Digest Auth。这种认证方式下浏览器会缓存用户的认证凭据并且在后续的每次请求中自动携带Authorization头不依赖Cookie。我测试过一个带有基础认证的老系统攻击者在恶意页面里构造一个跨域请求浏览器会向用户弹出登录框如果用户恰好在这个浏览器里已经认证过该系统或者是用户自己输入了凭据那么Authorization头会被自动携带系统照样执行了伪造请求。这种情况CSRF依然成立且和Cookie毫无关系。所以我在做接口排查时会把认证方式先列一遍基于Cookie的、基于Header的、基于URL参数的、基于浏览器内建认证的逐个看是否满足“自动携带凭据”这个条件。3. 实操过程与核心环节实现3.1 搭建实验环境快速构造一个带漏洞的模拟系统这个实验中我会构造一个简化版的“用户账号设置系统”来模拟真实环境但它被刻意暴露在漏洞之下。我选择一种当前很常见的Web框架技术栈——Python的Flask框架因为它够简洁便于把注意力集中在CSRF本身。先在本地建一个最小的应用功能只有两个用户登录、修改用户邮箱。这里的“修改邮箱”是高危操作实际场景中通常还伴随密码修改、手机号修改等。仅是写伪代码吗不是下面是可以直接跑起来的完整代码。我把代码放在 /opt/csrf_demo/app.py 位置使用Python 3.8以上版本# -*- coding: utf-8 -*- from flask import Flask, request, session, jsonify, render_template_string app Flask(__name__) app.secret_key unsafe_secret_key_do_not_use_in_prod # 模拟用户数据库 USERS { admin: {password: secret123, email: originaldemo.com} } # 登录页面 LOGIN_PAGE form methodpost action/login 用户名input typetext nameusernamebr 密码input typepassword namepasswordbr button typesubmit登录/button /form app.route(/login, methods[GET, POST]) def login(): if request.method POST: username request.form.get(username) password request.form.get(password) user USERS.get(username) if user and user[password] password: session[username] username return 登录成功你的邮箱是 user[email] br \ 修改邮箱a href/profile去修改/a return 用户名或密码错误 return render_template_string(LOGIN_PAGE) app.route(/profile, methods[GET]) def profile(): if username not in session: return 请先登录, 403 return h3修改邮箱/h3 form methodpost action/update_email 新邮箱input typetext nameemail valuenewdemo.com button typesubmit提交/button /form app.route(/update_email, methods[POST]) def update_email(): if username not in session: return 请先登录, 403 new_email request.form.get(email) username session[username] USERS[username][email] new_email return 邮箱已修改为 new_email if __name__ __main__: app.run(host0.0.0.0, port5000, debugTrue)为了方便演示我再写一个攻击者模拟站点端口开在 6000。这个站点专门用来展示攻击页面# -*- coding: utf-8 -*- from flask import Flask, render_template_string app Flask(__name__) ATTACK_PAGE !DOCTYPE html html headtitle安全测试演示页面/title/head body h3你看到的是一个测试页面/h3 iframe namehidden_frame styledisplay:none/iframe form methodPOST actionhttp://127.0.0.1:5000/update_email targethidden_frame input typehidden nameemail valueattackerevil.com /form script // 页面加载后自动提交表单 window.onload function() { document.forms[0].submit(); }; /script /body /html app.route(/) def index(): return render_template_string(ATTACK_PAGE) if __name__ __main__: app.run(port6000)需要说明的是这个模拟使用了127.0.0.1地址仅用于本地教学复现切勿对非授权系统进行真实攻击测试。如果你想完整模拟跨域行为可以改成两个不同的域名但核心逻辑一致。3.2 攻击复现全流程亲眼看着邮箱被改掉现在的实验环境有两个站点目标站app.demo.com或本地127.0.0.1:5000恶意站evil.example.com或本地127.0.0.1:6000第一步在浏览器里访问目标站用admin/secret123登录确认登录成功后SessionId写入Cookie。第二步在同一个浏览器的新标签页里访问恶意站。此时页面会自动发起对/update_email接口的POST请求请求内容是emailattackerevil.com。第三步查看目标站的响应。如果一切正常页面会显示“邮箱已修改为attackerevil.com”而事实是管理员本人完全没有任何操作。从浏览器开发者工具里可以观察到更有意思的现象这个“攻击请求”的请求头里带着目标站的Cookie显示来自本地站点请求来源是Localhost而页面里还带着一个隐藏的iframe。这就是CSRF的完整链条。细心的读者会问恶意页面在127.0.0.1:6000目标站在127.0.0.1:5000端口不同属于跨域为什么表单能提交成功因为表单提交和普通链接一样不受浏览器的跨域读取限制请求可以发出、服务器也能处理只是恶意页面里的JavaScript无法读取这个请求的响应内容而已。这正符合CSRF的攻击特点——攻击者不需要读取数据只需要让请求被服务器执行。3.3 防护方案一CSRF Token用一次性的随机凭证验证请求源CSRF Token是目前应用最广泛的CSRF防护方案它的核心思路是给每个用户的会话分配一个不可预测的随机值然后把这个值嵌入到每个状态变更请求中服务器在处理请求时校验这个值的存在性和正确性。我把这个方案补丁打到刚才的代码里import secrets from functools import wraps TOKENS {} def generate_csrf_token(): if session.get(username): token TOKENS.get(session[username]) if not token: token secrets.token_urlsafe(32) TOKENS[session[username]] token return token return None def csrf_protect(f): wraps(f) def wrapper(*args, **kwargs): if request.method POST: token request.form.get(csrf_token) or request.headers.get(X-CSRF-Token) user_token TOKENS.get(session.get(username)) if not token or token ! user_token: return CSRF校验失败, 400 return f(*args, **kwargs) return wrapper app.route(/update_email, methods[POST]) csrf_protect def update_email(): ...在页面模板里登录后需要在表单中加入隐藏字段input typehidden namecsrf_token value{{ csrf_token }}这样之后恶意页面无论怎么提交表单都拿不到当前会话的正確Token请求就会被拒绝。Token方案为什么有效因为Token是服务器在用户会话层面动态生成的攻击者无法预知也无法从目标站点获取跨域读取被同源策略挡住了。不过要注意一个前提Token不能放在URL里否则它会随请求被写入日志、Referer或浏览器历史记录攻击者一查就泄露了。Token只应该放在表单字段或自定义请求头里面。还有一个常见的坑很多项目喜欢用“固定Token对全局生效”的方式也就是用户第一次请求时生成一个Token之后整个会话都用这个Token。这种方式安全性稍弱因为一旦Token泄露攻击者可以在有效期内长期利用。更稳妥的做法是每次会话刷新或关键操作完成后更新Token。3.4 防护方案二SameSite Cookie属性从源头控制凭据的携带如果不想侵入业务代码加Token最省时省力的防护是给Cookie加上SameSite属性。它直接作用于“浏览器是否自动携带Cookie”这个环节相当于从源头掐断了攻击链路。来看这个简单的配置app.config.update( SESSION_COOKIE_SAMESITEStrict, SESSION_COOKIE_HTTPONLYTrue, SESSION_COOKIE_SECUREFalse # 生产环境务必改为True )把SameSite设为Lax或Strict后前面写的恶意页面里那个自动提交的表单发出的请求就不会携带目标站的Cookie。目标站发现请求里没有会话标识直接返回“请先登录”攻击失败。但这里我要强调一个重点SameSite适用于“基于Cookie的会话认证”。如果你的系统用的是Bearer Token放在请求头里、Basic Auth等方式SameSite完全无效因为攻击不依赖Cookie。另外如果选择的SameSiteLax那么GET形式的CSRF仍然可能成立。也就是说同Site并不是银弹它应该与下面的“自定义请求头校验”或“Referer校验”配合使用。3.5 防护方案三自定义请求头校验前后端分离项目的常用解法现在很多项目采用前后端分离架构后端只提供API前端用Vue或React开发请求通过AJAX发出。这时候一个简单但有效的方案是要求每个请求都必须携带一个自定义请求头比如X-Requested-With: XMLHttpRequest或X-CSRF-Token。原理很简单在跨域场景下自定义请求头会触发浏览器的预检请求OPTIONS如果攻击者的恶意代码只是构造一个表单或图片标签发起请求它无法主动添加自定义请求头字段浏览器不知道跨域请求中允许哪些请求头除非服务器响应了相应的Access-Control-Allow-Headers。所以只要后端校验“请求中是否包含特定的自定义请求头”就能挡掉绝大多数基于表单自动提交的CSRF攻击。前端代码片段如下// 使用axios axios.post(/api/update_email, { email: newEmail }, { headers: { X-Requested-With: XMLHttpRequest } });后端校验app.route(/api/update_email, methods[POST]) def api_update_email(): if request.headers.get(X-Requested-With) ! XMLHttpRequest: return 拒绝非AJAX请求, 403 ...这个方案的优点是实现成本低不需要在服务器端存Token状态。缺点是它不能防御那些能够直接构造带自定义请求头的攻击——比如如果有XSS漏洞或者目标系统本身就允许恶意站点配置CORS跨域并允许特定请求头那么该方案也能被绕过。所以它更准确的定位是“提高攻击成本”而不是“彻底阻断”。3.6 防护方案四Referer/Origin校验历史传统但依然管用Referer校验的原理也很直观服务器检查请求里的Referer或Origin头看它是否来自目标站点的合法页面。不是则拒绝。Referer校验的实现ALLOWED_ORIGINS [http://app.demo.com] app.route(/update_email, methods[POST]) def update_email_with_referer_check(): origin request.headers.get(Origin) if origin and origin not in ALLOWED_ORIGINS: return 非法来源, 403 referer request.headers.get(Referer) if referer: from urllib.parse import urlparse parsed urlparse(referer) if parsed.netloc not in ALLOWED_ORIGINS: return 非法来源, 403 ...这个方案的缺点是Referer在某些环境下可能缺失或不可靠比如用户使用了隐身模式、安全策略设置了Referrer-Policy为no-referrer时Referer为空这时如果服务器只是简单校验Referer就会误伤正常请求。所以纯靠Referer校验不太稳定但作为辅助手段和Token或自定义头方案配合完全没问题。4. 常见问题与排查技巧实录4.1 问题为什么我加了CSRF Token攻击还是成功了我在帮人排查的时候遇到过好几次这样的结论最终定位的结果往往不是Token方案本身失效而是Token的实现存在明显漏洞。比较常见的有三种第一种是Token没有绑定会话。项目的Token是全局唯一的常量字符串所有用户、所有请求都共用同一个Token。这种Token一旦泄露可以通过XSS或日志记录窃取攻击者直接硬编码到恶意表单里就能通过校验。正确做法是Token必须和用户会话强绑定不能全局共享。第二种是Token只校验“存在性”不校验“正确性”。有些开发者写校验逻辑时犯了一个简化错误只要请求里带了csrf_token字段就视为合法。攻击者只需要在恶意表单里随便填一个Token字符串就能绕过。这种情况比没有Token更危险因为开发者以为自己防护了实际仍然裸奔。第三种是Token存储位置错误。Token放在URL路径或查询参数里比如 /update_email?csrf_tokenabc攻击者从Referer日志、代理服务器日志、浏览器历史中就能提取到合法Token然后伪造请求时带上它。Token只应该乖乖待在表单隐藏字段或请求头里。4.2 问题SameSiteLax明明设置了为什么某些浏览器上CSRF还是成功这个问题的原因通常出在“浏览器版本”和“顶级导航”这两个词上。老版本的浏览器不支持SameSite属性或者把它默认当作None处理。如果你把Cookie配置了SameSiteLax但用户用的是某企业定制的老旧内核浏览器它可能完全不识别这个属性Cookie仍然全场景携带CSRF防线形同虚设。此外Lax模式下允许“顶级导航”携带Cookie这意味着如果目标接口支持GET请求修改状态很多老接口都有这个习惯比如 /delete?id1攻击者只要在恶意页面放一个普通链接诱导用户点击浏览器会在顶级导航里带着Cookie访问该URL攻击照样成立。所以在确定业务场景时我总是把“禁止用GET方法修改状态”作为一条硬性规范。4.3 问题前后端分离项目如何做CSRF防护前后端分离项目前端和后端通常不在同一个域名下Cookie跨域携带会被阻断所以如果后端不使用Cookie认证CSRF的风险反而相对可控。但如果后端仍然使用Cookie认证同时开启了CORS允许跨域那就需要在CORS配置中精确限制允许的来源不能让Access-Control-Allow-Origin是星号否则任何一个外部站点都能向该API发送带Cookie的请求。对于使用Bearer Token认证的项目我的建议是不要依赖CSRF Token而是检查是否存在CORS配置漏洞、浏览器是否可能自动携带认证凭据。如果Token放在Authorization头中跨域请求必须经过预检预检会要求服务器明确允许Authorization头所以只要后端不盲目放行任意Origin风险就是可控的。另外使用Cookie存储Token时记得设置SameSite和Secure属性。4.4 实践心得排查一个接口是否受CSRF威胁只看五个点第一接口的认证方式是否依赖浏览器自动携带的凭据。Cookie、Basic Auth属于自动携带Header里的Bearer Token不属于自动携带除非前端有存储机制。第二接口是否会造成状态变更。只读接口即使被CSRF命中也顶多泄露信息不构成直接篡改风险。第三接口的可预测性。参数里是否包含攻击者可以猜到的信息例如通过遍历对象ID批量删除资源就是高风险。第四系统是否已部署基础的防护设施。比如全局CSRF Token、SameSiteStrict、接口层面的来源校验。第五目标站点的安全性。如果站点本身存在XSSCSRF防护再好也可能是白搭——XSS可以直接窃取Token、读取页面内容完全绕开所有CSRF防御手段。4.5 CSRF防护方案选型速查表场景推荐方案补充说明传统服务端渲染多页应用Cookie认证CSRF Token SameSiteLaxToken存在表单隐藏字段严格绑定会话前后端分离Bearer Token认证不依赖CSRF Token检查CORS配置禁止Access-Control-Allow-Origin为*精确指定可信域名内网部署的老系统SameSiteStrict 自定义请求头升级浏览器兼容性不稳时优先服务端校验支付/核心敏感操作二次校验 CSRF Token建议增加密码或短信验证码做二次确认第三方跨站嵌入式场景Token 自定义请求头 Referer辅助不要依赖SameSite因为跨站场景下Lax允许导航携带Cookie4.6 实操中我踩过的坑和教训第一次给一个管理后台加CSRF防护时我直接在过滤器里校验了Referer结果上线后一批老用户反馈“填完表单就被弹出去”。后来一查发现原因有两个一是部分用户浏览器安装了插件把Referer字段全部抹掉了二是站点的落地页从一个不带路径的域名跳转到带www的域名Referer里带了不同子域被误判成非法来源。这类事故给我留下的经验就是Referer校验尽量只作为辅助手段不要当主力。主力永远是Token或SameSite这类不会因为浏览器环境差异而失效的方案。还有一个经验是安全方案要覆盖“全局”而不是只覆盖“部分接口”。我见过某个系统只在“修改密码”接口加了Token其他几十个接口全部裸奔。攻击者只要找到一个没防护的接口照样可以完成恶意操作。安全测试时应该自动化遍历接口清单逐个确认是否有防护而不是只盯着核心接口。另外我建议在开发环境里就把CSRF防护打开不要等上线前再补。开发时如果不开很多代码逻辑会在没有Token的情况下跑通上线前再补就会各种兼容性问题。开发环境模拟生产环境的防护策略是避免上线事故的最有效方式。最后分享一个调试时的小技巧排查CSRF相关问题时打开浏览器开发者工具在Network面板里看请求的Headers如果发现某个敏感请求的Cookie字段非常整齐地自动携带、且没有自定义的防护头这个请求就是CSRF的高危候选。用这个方式我在5分钟内就能给一个接口做出初步的风险研判不需要任何安全工具。CSRF的核心矛盾在于服务器无法从请求本身判断“这是用户自己干的还是第三方干的”。所有的防护方案本质都是给请求增加一个“只有用户自己页面才知道的标记”让服务器有条件地区分来源。明白这一点你就已经掌握了判断所有CSRF防护方案有效性的核心方法。 
长河君 · 2026/10/16 12:42:34 · 阅读 1.2k CSRF跨站请求伪造：原理、攻击复现与防护实战
CSRF跨站请求伪造是我在给多个Web项目做安全评审时最常被开发者低估的一类漏洞。相比SQL注入或XSS那种“直接打进来”的攻击方式CSRF更像是“借刀杀人”——攻击者不碰你的服务器而是利用浏览器自动携带Cookie的机制伪造一个合法用户的请求让服务器误以为是用户本人在操作。这篇文章就用一个完整的实操案例把CSRF从原理到攻击复现再到防护落地一整套流程拆开讲清楚适合刚接触Web安全的开发者也适合需要给老项目补安全策略的技术负责人。1. 内容整体设计与思路拆解1.1 CSRF的本质一切问题出在“身份凭证自动携带”上要理解CSRF先得搞清楚一个关键机制浏览器在发出请求时会根据目标域名自动携带该域名下的Cookie这个过程完全由浏览器自己完成页面里的JavaScript根本插不上手。这个设计本来是为了方便用户保持登录态但同时也埋下了隐患——服务器收到请求时只能看到“这个请求带着合法用户的Cookie”却无法判断这个请求究竟是用户主动发起的还是某个恶意页面里偷偷发起的。举个例子我用某银行系统管理后台时登录成功后服务端会下发一个SessionId到Cookie里。只要我在这台浏览器上继续访问该后台的任意接口请求头里都会自动带上这个SessionId。如果此时我在另一个浏览器标签页打开了一个恶意站点而那个站点里有一个自动提交的隐藏表单表单的action指向银行后台的“修改邮箱”接口那么浏览器向银行后台发起请求时一样会带上SessionId。服务端一看哟合法用户的会话放行。整个过程用户毫不知情服务器也无法辨别真伪。这也是CSRF和XSS最本质的区别XSS是攻击者往你的页面里注入脚本直接在你的浏览器里执行而CSRF则是在第三方页面里伪造请求借你的身份发送出去。XSS需要找到一个可注入的点CSRF只需要你“正在登录着目标站点”这一个条件。1.2 一个成功的CSRF攻击需要满足哪些条件从攻击者视角来看一次成功的CSRF攻击通常要凑齐四个要素第一目标站点存在一个“状态变更类”接口比如改密码、改邮箱、转账、删除资源、发表评论等而且这个接口只依赖Cookie来识别用户身份。第二这个接口的请求参数可以被攻击者预先猜到或者至少大部分参数是固定的。如果接口要求一个随机的、只有用户自己才知道的动态令牌攻击者就无法构造有效的请求。第三用户访问目标站点时仍处于有效的登录状态Cookie没有过期。第四用户必须在同一浏览器里访问了攻击者控制的恶意页面无论是通过诱导点击还是单纯扫了一眼带链接的邮件。这四个要素前两个是目标站点的问题后两个是用户侧的条件。所以CSRF的防护思路也很清晰要么让攻击者无法预测请求参数Token机制要么让浏览器不再无条件地携带CookieSameSite属性要么让服务器能在请求里辨别出真实来源自定义请求头、Referer校验。1.3 危害分级不是所有CSRF都只是“改个昵称”CSRF的危害和接口的重要程度强相关。低危场景比如改个头像、换一下主题颜色顶多算骚扰。但高危场景堪称致命电商平台的收货地址被篡改可能导致包裹被劫持管理后台的“修改管理员权限”接口被利用等于直接把系统最高权限交给攻击者在线支付系统的“转账”接口被伪造用户的资金会直接打到攻击者账户上。我在给某公司内部的工单系统做安全评审时就发现过一个实际存在的CSRF隐患该系统的“重置用户密码”接口完全依赖Session认证管理员登录后攻击者只要诱导管理员访问一个恶意页面就能通过自动提交表单把任意用户的密码重置成攻击者指定的值。最棘手的是这类后台系统通常部署在内网运营人员不认为内网系统会遭受攻击于是连最基本的Token校验都没有做。所以无论内网还是外网CSRF的防护标准都应该一视同仁。1.4 为什么CSRF经常被开发者忽略CSRF不像XSS可以在页面里看到实际弹窗效果也不像SQL注入能直接拉出数据库内容。它是一个“看不见”的漏洞——攻击结束后用户看到的结果只是“我的密码怎么改了”“我没买东西啊怎么多了个订单”。很多开发者测试时用自己的账号操作一遍流程发现一切正常就认为系统是安全的却忽略了“这个请求换一个来源是否依然会被信任”这个问题。还有一个现实原因早期的Web开发教材重点讲的都是输入校验和SQL注入对CSRF的讲解往往一笔带过。加上一些前后端分离项目在开发阶段就全量开启了跨域接口开发者在本地调试时习惯了“裸奔”上线后忘了补上防护留下了大量可被CSRF利用的接口。这也是我写这篇实操案例的原因——用一次完整的攻击和防护演示把问题彻底说透。2. 核心细节解析与实操要点2.1 攻击链路拆解从用户登录到请求伪造每一步都在干什么我习惯把一次完整的CSRF攻击拆成五个阶段方便在排查时逐一对照阶段一用户登录目标站点。用户在浏览器里访问某系统假设域名是app.demo.com输入账号密码登录成功后服务器下发一个会话标识浏览器把它存放在Cookie里。阶段二用户未登出同时访问了恶意页面。用户没有关闭浏览器而是继续浏览网页点开了一封邮件里的链接或直接访问了攻击者布置的页面假设域名是evil.example.com。阶段三恶意页面自动触发请求。恶意页面里有隐藏表单、img标签或JavaScript脚本页面一加载就自动向app.demo.com发出请求。此时浏览器会根据同源策略放行跨域请求的发送只是限制了读取响应结果而请求本身照发不误。阶段四浏览器自动携带Cookie。请求真正发出时浏览器检查目标域名app.demo.com发现当前浏览器的Cookie中存有该域名的会话标识于是自动加到请求头里。阶段五服务端处理请求。服务端只校验了会话是否有效并未校验请求的发起来源于是执行了状态变更操作攻击成功。这里有一个极其关键的细节值得注意浏览器同源策略禁止JavaScript读取跨域响应但不禁止发送跨域请求。很多开发者误以为“跨域请求会被浏览器拦截”实际上被拦截的只是响应读取表单提交、图片加载、脚本加载这些请求照样能发出去。CSRF攻击利用的正是这个不对称的策略。2.2 携带Cookie的机制SameSite属性到底管不管用现代浏览器普遍支持Cookie的SameSite属性取值有三个Strict、Lax、None。SameSiteStrict时浏览器在任何跨站场景下都不会携带Cookie这种设置最安全但用户体验比较差。用户从第三方链接跳转到目标站点时会话Cookie丢失需要重新登录。所以这个值适合用于那些不依赖第三方跳转的业务比如管理后台。SameSiteLax是Chrome浏览器近年来的默认值它允许在顶级导航场景下携带Cookie也就是用户点击链接从外部站点跳转到目标站点时Cookie会带上但通过iframe内嵌、img标签、AJAX发起的子请求Cookie不会携带。这个取值能拦截掉大部分CSRF攻击但有一个缺口如果目标接口支持别名为链接导航的GET请求并且业务上允许GET方法执行状态变更那么点击链接也能触发CSRF。所以Lax适合与“禁止GET方法修改状态”的规范配合使用。SameSiteNone必须配合Secure属性一起使用也就是仅限HTTPS场景。它表示浏览器在所有场景下都携带Cookie相当于关闭了这层防护最危险。只有当下有明确的跨站业务需求才考虑用这个取值。实际操作中我见过很多系统把Cookie的SameSite显式设置成None理由很简单“因为有跨域调用需求”。结果跨域业务没跑起来CSRF防护倒是先被自己亲手关了。这里要说明的是SameSite是Cookie属性层面的防护不是唯一手段不能因为设置了Lax就以为高枕无忧也不能因为业务需要跨站就彻底放弃其他防护方案。2.3 攻击向量细说不只是隐藏表单这一种姿势提到CSRF的POC很多文章只写了隐藏表单自动提交但实际攻击向量比这丰富得多。第一种是HTML表单自动提交。这是最经典的姿势用一个隐藏的form表单加载时调用JavaScript的form.submit()方法。优点是不受同源策略限制支持POST和GET适合接口接收常规表单字段的请求。第二种是图片标签伪造GET请求。如果目标接口用GET方法执行状态变更比如通过请求参数删除一条记录、激活账户等攻击者只需构造一个带src的img标签浏览器加载页面时就会自动发出这个GET请求。由于img标签发出的请求带Referer但这并不能阻止请求发送出去。第三种是XMLHttpRequest或fetch。这种方式适合接口返回JSON且Content-Type为application/json的场景。需要注意跨域XHR请求会触发预检请求OPTIONS如果目标接口没有正确处理OPTIONS攻击还是会失败。但在过去很长一段时间里一些老系统的接口设计并不规范开发者在后端只做了“放行所有OPTIONS请求”的处理导致这部分请求也能被利用。第四种是JSONP接口。如果目标站点存在JSONP回调接口攻击者可以通过script标签触发请求还能读取返回内容虽然这和纯CSRF不是同一个问题但攻击效果被放大了。我在评估风险时通常把JSONP问题单独排查因为它涉及的不仅是CSRF还可能造成数据泄露。2.4 容易忽略的CSRF变形场景不止“登录态”还有一个容易被忽略的变形场景不依赖Cookie的CSRF。单页应用项目如果采用Token放在localStorage里的方式认证浏览器不会自动携带这些Token所以常规强制浏览器发起请求的方式无法利用CSRF。但有些项目会把Token放在URL参数或请求头里请求头必须通过自定义脚本添加浏览器没法自动完成反而天然防了一手。真正容易出问题的是基础认证Basic Auth和摘要认证Digest Auth。这种认证方式下浏览器会缓存用户的认证凭据并且在后续的每次请求中自动携带Authorization头不依赖Cookie。我测试过一个带有基础认证的老系统攻击者在恶意页面里构造一个跨域请求浏览器会向用户弹出登录框如果用户恰好在这个浏览器里已经认证过该系统或者是用户自己输入了凭据那么Authorization头会被自动携带系统照样执行了伪造请求。这种情况CSRF依然成立且和Cookie毫无关系。所以我在做接口排查时会把认证方式先列一遍基于Cookie的、基于Header的、基于URL参数的、基于浏览器内建认证的逐个看是否满足“自动携带凭据”这个条件。3. 实操过程与核心环节实现3.1 搭建实验环境快速构造一个带漏洞的模拟系统这个实验中我会构造一个简化版的“用户账号设置系统”来模拟真实环境但它被刻意暴露在漏洞之下。我选择一种当前很常见的Web框架技术栈——Python的Flask框架因为它够简洁便于把注意力集中在CSRF本身。先在本地建一个最小的应用功能只有两个用户登录、修改用户邮箱。这里的“修改邮箱”是高危操作实际场景中通常还伴随密码修改、手机号修改等。仅是写伪代码吗不是下面是可以直接跑起来的完整代码。我把代码放在 /opt/csrf_demo/app.py 位置使用Python 3.8以上版本# -*- coding: utf-8 -*- from flask import Flask, request, session, jsonify, render_template_string app Flask(__name__) app.secret_key unsafe_secret_key_do_not_use_in_prod # 模拟用户数据库 USERS { admin: {password: secret123, email: originaldemo.com} } # 登录页面 LOGIN_PAGE form methodpost action/login 用户名input typetext nameusernamebr 密码input typepassword namepasswordbr button typesubmit登录/button /form app.route(/login, methods[GET, POST]) def login(): if request.method POST: username request.form.get(username) password request.form.get(password) user USERS.get(username) if user and user[password] password: session[username] username return 登录成功你的邮箱是 user[email] br \ 修改邮箱a href/profile去修改/a return 用户名或密码错误 return render_template_string(LOGIN_PAGE) app.route(/profile, methods[GET]) def profile(): if username not in session: return 请先登录, 403 return h3修改邮箱/h3 form methodpost action/update_email 新邮箱input typetext nameemail valuenewdemo.com button typesubmit提交/button /form app.route(/update_email, methods[POST]) def update_email(): if username not in session: return 请先登录, 403 new_email request.form.get(email) username session[username] USERS[username][email] new_email return 邮箱已修改为 new_email if __name__ __main__: app.run(host0.0.0.0, port5000, debugTrue)为了方便演示我再写一个攻击者模拟站点端口开在 6000。这个站点专门用来展示攻击页面# -*- coding: utf-8 -*- from flask import Flask, render_template_string app Flask(__name__) ATTACK_PAGE !DOCTYPE html html headtitle安全测试演示页面/title/head body h3你看到的是一个测试页面/h3 iframe namehidden_frame styledisplay:none/iframe form methodPOST actionhttp://127.0.0.1:5000/update_email targethidden_frame input typehidden nameemail valueattackerevil.com /form script // 页面加载后自动提交表单 window.onload function() { document.forms[0].submit(); }; /script /body /html app.route(/) def index(): return render_template_string(ATTACK_PAGE) if __name__ __main__: app.run(port6000)需要说明的是这个模拟使用了127.0.0.1地址仅用于本地教学复现切勿对非授权系统进行真实攻击测试。如果你想完整模拟跨域行为可以改成两个不同的域名但核心逻辑一致。3.2 攻击复现全流程亲眼看着邮箱被改掉现在的实验环境有两个站点目标站app.demo.com或本地127.0.0.1:5000恶意站evil.example.com或本地127.0.0.1:6000第一步在浏览器里访问目标站用admin/secret123登录确认登录成功后SessionId写入Cookie。第二步在同一个浏览器的新标签页里访问恶意站。此时页面会自动发起对/update_email接口的POST请求请求内容是emailattackerevil.com。第三步查看目标站的响应。如果一切正常页面会显示“邮箱已修改为attackerevil.com”而事实是管理员本人完全没有任何操作。从浏览器开发者工具里可以观察到更有意思的现象这个“攻击请求”的请求头里带着目标站的Cookie显示来自本地站点请求来源是Localhost而页面里还带着一个隐藏的iframe。这就是CSRF的完整链条。细心的读者会问恶意页面在127.0.0.1:6000目标站在127.0.0.1:5000端口不同属于跨域为什么表单能提交成功因为表单提交和普通链接一样不受浏览器的跨域读取限制请求可以发出、服务器也能处理只是恶意页面里的JavaScript无法读取这个请求的响应内容而已。这正符合CSRF的攻击特点——攻击者不需要读取数据只需要让请求被服务器执行。3.3 防护方案一CSRF Token用一次性的随机凭证验证请求源CSRF Token是目前应用最广泛的CSRF防护方案它的核心思路是给每个用户的会话分配一个不可预测的随机值然后把这个值嵌入到每个状态变更请求中服务器在处理请求时校验这个值的存在性和正确性。我把这个方案补丁打到刚才的代码里import secrets from functools import wraps TOKENS {} def generate_csrf_token(): if session.get(username): token TOKENS.get(session[username]) if not token: token secrets.token_urlsafe(32) TOKENS[session[username]] token return token return None def csrf_protect(f): wraps(f) def wrapper(*args, **kwargs): if request.method POST: token request.form.get(csrf_token) or request.headers.get(X-CSRF-Token) user_token TOKENS.get(session.get(username)) if not token or token ! user_token: return CSRF校验失败, 400 return f(*args, **kwargs) return wrapper app.route(/update_email, methods[POST]) csrf_protect def update_email(): ...在页面模板里登录后需要在表单中加入隐藏字段input typehidden namecsrf_token value{{ csrf_token }}这样之后恶意页面无论怎么提交表单都拿不到当前会话的正確Token请求就会被拒绝。Token方案为什么有效因为Token是服务器在用户会话层面动态生成的攻击者无法预知也无法从目标站点获取跨域读取被同源策略挡住了。不过要注意一个前提Token不能放在URL里否则它会随请求被写入日志、Referer或浏览器历史记录攻击者一查就泄露了。Token只应该放在表单字段或自定义请求头里面。还有一个常见的坑很多项目喜欢用“固定Token对全局生效”的方式也就是用户第一次请求时生成一个Token之后整个会话都用这个Token。这种方式安全性稍弱因为一旦Token泄露攻击者可以在有效期内长期利用。更稳妥的做法是每次会话刷新或关键操作完成后更新Token。3.4 防护方案二SameSite Cookie属性从源头控制凭据的携带如果不想侵入业务代码加Token最省时省力的防护是给Cookie加上SameSite属性。它直接作用于“浏览器是否自动携带Cookie”这个环节相当于从源头掐断了攻击链路。来看这个简单的配置app.config.update( SESSION_COOKIE_SAMESITEStrict, SESSION_COOKIE_HTTPONLYTrue, SESSION_COOKIE_SECUREFalse # 生产环境务必改为True )把SameSite设为Lax或Strict后前面写的恶意页面里那个自动提交的表单发出的请求就不会携带目标站的Cookie。目标站发现请求里没有会话标识直接返回“请先登录”攻击失败。但这里我要强调一个重点SameSite适用于“基于Cookie的会话认证”。如果你的系统用的是Bearer Token放在请求头里、Basic Auth等方式SameSite完全无效因为攻击不依赖Cookie。另外如果选择的SameSiteLax那么GET形式的CSRF仍然可能成立。也就是说同Site并不是银弹它应该与下面的“自定义请求头校验”或“Referer校验”配合使用。3.5 防护方案三自定义请求头校验前后端分离项目的常用解法现在很多项目采用前后端分离架构后端只提供API前端用Vue或React开发请求通过AJAX发出。这时候一个简单但有效的方案是要求每个请求都必须携带一个自定义请求头比如X-Requested-With: XMLHttpRequest或X-CSRF-Token。原理很简单在跨域场景下自定义请求头会触发浏览器的预检请求OPTIONS如果攻击者的恶意代码只是构造一个表单或图片标签发起请求它无法主动添加自定义请求头字段浏览器不知道跨域请求中允许哪些请求头除非服务器响应了相应的Access-Control-Allow-Headers。所以只要后端校验“请求中是否包含特定的自定义请求头”就能挡掉绝大多数基于表单自动提交的CSRF攻击。前端代码片段如下// 使用axios axios.post(/api/update_email, { email: newEmail }, { headers: { X-Requested-With: XMLHttpRequest } });后端校验app.route(/api/update_email, methods[POST]) def api_update_email(): if request.headers.get(X-Requested-With) ! XMLHttpRequest: return 拒绝非AJAX请求, 403 ...这个方案的优点是实现成本低不需要在服务器端存Token状态。缺点是它不能防御那些能够直接构造带自定义请求头的攻击——比如如果有XSS漏洞或者目标系统本身就允许恶意站点配置CORS跨域并允许特定请求头那么该方案也能被绕过。所以它更准确的定位是“提高攻击成本”而不是“彻底阻断”。3.6 防护方案四Referer/Origin校验历史传统但依然管用Referer校验的原理也很直观服务器检查请求里的Referer或Origin头看它是否来自目标站点的合法页面。不是则拒绝。Referer校验的实现ALLOWED_ORIGINS [http://app.demo.com] app.route(/update_email, methods[POST]) def update_email_with_referer_check(): origin request.headers.get(Origin) if origin and origin not in ALLOWED_ORIGINS: return 非法来源, 403 referer request.headers.get(Referer) if referer: from urllib.parse import urlparse parsed urlparse(referer) if parsed.netloc not in ALLOWED_ORIGINS: return 非法来源, 403 ...这个方案的缺点是Referer在某些环境下可能缺失或不可靠比如用户使用了隐身模式、安全策略设置了Referrer-Policy为no-referrer时Referer为空这时如果服务器只是简单校验Referer就会误伤正常请求。所以纯靠Referer校验不太稳定但作为辅助手段和Token或自定义头方案配合完全没问题。4. 常见问题与排查技巧实录4.1 问题为什么我加了CSRF Token攻击还是成功了我在帮人排查的时候遇到过好几次这样的结论最终定位的结果往往不是Token方案本身失效而是Token的实现存在明显漏洞。比较常见的有三种第一种是Token没有绑定会话。项目的Token是全局唯一的常量字符串所有用户、所有请求都共用同一个Token。这种Token一旦泄露可以通过XSS或日志记录窃取攻击者直接硬编码到恶意表单里就能通过校验。正确做法是Token必须和用户会话强绑定不能全局共享。第二种是Token只校验“存在性”不校验“正确性”。有些开发者写校验逻辑时犯了一个简化错误只要请求里带了csrf_token字段就视为合法。攻击者只需要在恶意表单里随便填一个Token字符串就能绕过。这种情况比没有Token更危险因为开发者以为自己防护了实际仍然裸奔。第三种是Token存储位置错误。Token放在URL路径或查询参数里比如 /update_email?csrf_tokenabc攻击者从Referer日志、代理服务器日志、浏览器历史中就能提取到合法Token然后伪造请求时带上它。Token只应该乖乖待在表单隐藏字段或请求头里。4.2 问题SameSiteLax明明设置了为什么某些浏览器上CSRF还是成功这个问题的原因通常出在“浏览器版本”和“顶级导航”这两个词上。老版本的浏览器不支持SameSite属性或者把它默认当作None处理。如果你把Cookie配置了SameSiteLax但用户用的是某企业定制的老旧内核浏览器它可能完全不识别这个属性Cookie仍然全场景携带CSRF防线形同虚设。此外Lax模式下允许“顶级导航”携带Cookie这意味着如果目标接口支持GET请求修改状态很多老接口都有这个习惯比如 /delete?id1攻击者只要在恶意页面放一个普通链接诱导用户点击浏览器会在顶级导航里带着Cookie访问该URL攻击照样成立。所以在确定业务场景时我总是把“禁止用GET方法修改状态”作为一条硬性规范。4.3 问题前后端分离项目如何做CSRF防护前后端分离项目前端和后端通常不在同一个域名下Cookie跨域携带会被阻断所以如果后端不使用Cookie认证CSRF的风险反而相对可控。但如果后端仍然使用Cookie认证同时开启了CORS允许跨域那就需要在CORS配置中精确限制允许的来源不能让Access-Control-Allow-Origin是星号否则任何一个外部站点都能向该API发送带Cookie的请求。对于使用Bearer Token认证的项目我的建议是不要依赖CSRF Token而是检查是否存在CORS配置漏洞、浏览器是否可能自动携带认证凭据。如果Token放在Authorization头中跨域请求必须经过预检预检会要求服务器明确允许Authorization头所以只要后端不盲目放行任意Origin风险就是可控的。另外使用Cookie存储Token时记得设置SameSite和Secure属性。4.4 实践心得排查一个接口是否受CSRF威胁只看五个点第一接口的认证方式是否依赖浏览器自动携带的凭据。Cookie、Basic Auth属于自动携带Header里的Bearer Token不属于自动携带除非前端有存储机制。第二接口是否会造成状态变更。只读接口即使被CSRF命中也顶多泄露信息不构成直接篡改风险。第三接口的可预测性。参数里是否包含攻击者可以猜到的信息例如通过遍历对象ID批量删除资源就是高风险。第四系统是否已部署基础的防护设施。比如全局CSRF Token、SameSiteStrict、接口层面的来源校验。第五目标站点的安全性。如果站点本身存在XSSCSRF防护再好也可能是白搭——XSS可以直接窃取Token、读取页面内容完全绕开所有CSRF防御手段。4.5 CSRF防护方案选型速查表场景推荐方案补充说明传统服务端渲染多页应用Cookie认证CSRF Token SameSiteLaxToken存在表单隐藏字段严格绑定会话前后端分离Bearer Token认证不依赖CSRF Token检查CORS配置禁止Access-Control-Allow-Origin为*精确指定可信域名内网部署的老系统SameSiteStrict 自定义请求头升级浏览器兼容性不稳时优先服务端校验支付/核心敏感操作二次校验 CSRF Token建议增加密码或短信验证码做二次确认第三方跨站嵌入式场景Token 自定义请求头 Referer辅助不要依赖SameSite因为跨站场景下Lax允许导航携带Cookie4.6 实操中我踩过的坑和教训第一次给一个管理后台加CSRF防护时我直接在过滤器里校验了Referer结果上线后一批老用户反馈“填完表单就被弹出去”。后来一查发现原因有两个一是部分用户浏览器安装了插件把Referer字段全部抹掉了二是站点的落地页从一个不带路径的域名跳转到带www的域名Referer里带了不同子域被误判成非法来源。这类事故给我留下的经验就是Referer校验尽量只作为辅助手段不要当主力。主力永远是Token或SameSite这类不会因为浏览器环境差异而失效的方案。还有一个经验是安全方案要覆盖“全局”而不是只覆盖“部分接口”。我见过某个系统只在“修改密码”接口加了Token其他几十个接口全部裸奔。攻击者只要找到一个没防护的接口照样可以完成恶意操作。安全测试时应该自动化遍历接口清单逐个确认是否有防护而不是只盯着核心接口。另外我建议在开发环境里就把CSRF防护打开不要等上线前再补。开发时如果不开很多代码逻辑会在没有Token的情况下跑通上线前再补就会各种兼容性问题。开发环境模拟生产环境的防护策略是避免上线事故的最有效方式。最后分享一个调试时的小技巧排查CSRF相关问题时打开浏览器开发者工具在Network面板里看请求的Headers如果发现某个敏感请求的Cookie字段非常整齐地自动携带、且没有自定义的防护头这个请求就是CSRF的高危候选。用这个方式我在5分钟内就能给一个接口做出初步的风险研判不需要任何安全工具。CSRF的核心矛盾在于服务器无法从请求本身判断“这是用户自己干的还是第三方干的”。所有的防护方案本质都是给请求增加一个“只有用户自己页面才知道的标记”让服务器有条件地区分来源。明白这一点你就已经掌握了判断所有CSRF防护方案有效性的核心方法。