1. 项目概述与核心价值上一期我们聊透了CSRF攻击的原理、危害和常见攻击场景相信大家已经对“跨站请求伪造”这个老牌但依然活跃的Web安全漏洞有了深刻的理解。原理懂了但光懂原理没用关键是怎么防。很多开发者在面对安全需求时常常陷入两个极端要么觉得加个Token就万事大吉要么被各种安全术语和方案搞得晕头转向最后可能选了个并不适合自己业务场景的方案要么防御过度影响体验要么防御不足留下隐患。这期内容我们就来点实在的。我将结合自己十多年在前后端安全对抗中的实战经验为你拆解四种经过大量线上业务验证、可直接落地的CSRF防御方案。我不会只告诉你“用什么”更重要的是讲清楚“为什么用这个”以及“怎么用才不出错”。这四种方案覆盖了从经典通用到前沿强制的不同层次你可以根据自己项目的技术栈、业务复杂度和安全等级像搭积木一样组合使用。无论是刚上线的创业项目还是承载亿级流量的成熟系统都能在这里找到适合你的防御策略。2. 四种可落地防御方案全景解析在深入每个方案之前我们必须建立一个核心认知没有一种安全方案是银弹。CSRF防御的本质是增加攻击者伪造请求的难度直至成本高到不可行。我们的目标是在安全、用户体验和开发维护成本之间找到一个最佳平衡点。下面这张表概括了四种方案的核心思路、适用场景和优缺点你可以快速建立一个全局视图防御方案核心防御思路典型适用场景优点缺点与注意事项同步令牌 (Synchronizer Token Pattern)服务端生成随机令牌随页面下发请求时校验。传统服务端渲染应用、表单提交、关键操作如转账、改密。原理简单防御力强业界最广泛验证。需解决令牌存储、分发、校验的完整链路对单页应用(SPA)不友好。双重Cookie验证 (Double Submit Cookie)将随机令牌同时放在Cookie和请求参数/头中服务端比对是否一致。前后端分离架构、API接口、希望简化令牌管理的场景。无需服务端存储会话状态天然支持分布式。依赖浏览器Cookie策略需防范子域漏洞需注意Cookie的HttpOnly和SameSite属性。自定义请求头 (Custom Header)要求前端在发起敏感请求时携带一个自定义的HTTP头如X-Requested-With。基于XMLHttpRequest或Fetch API的异步请求Ajax。实现简单防御效果可靠同源策略保护。仅对异步请求有效对通过form、img等标签发起的请求无效。SameSite Cookie属性从浏览器层面限制Cookie的发送场景直接阻止跨站请求携带认证Cookie。所有依赖Cookie进行会话管理的Web应用。从源头防御近乎零开发成本现代浏览器广泛支持。需要权衡Lax和Strict模式对用户体验的影响需考虑老旧浏览器兼容性。这四种方案并非互斥在实际项目中我强烈推荐采用“组合拳”策略。例如为所有Cookie设置SameSiteLax作为基础防线对关键API采用“同步令牌”或“双重Cookie验证”并对所有Ajax请求强制校验自定义请求头。接下来我们逐一深入每个方案的实现细节、坑点和最佳实践。2.1 方案一同步令牌 (Synchronizer Token Pattern) —— 经典之选这是防御CSRF最经典、最根本的方法其原理是“一次一密”。服务端为每个用户会话生成一个高强度的、不可预测的随机字符串即CSRF Token在渲染页面时将其嵌入如表单的隐藏域、Meta标签。当用户提交请求时必须将这个Token一并带回服务端进行校验匹配则通过不匹配或缺失则拒绝。为什么它有效攻击者可以伪造请求的URL和参数但他无法在遵守同源策略的前提下读取目标站点页面中的内容因此他无法获知这个每次都在变化的Token值。实操要点与深度解析Token的生成与存储生成必须使用密码学安全的随机数生成器CSPRNG。在Java中可用java.security.SecureRandom在Node.js中可用crypto.randomBytes()在Python中可用secrets.token_urlsafe()。Token长度建议32字节256位以上编码为Base64或Hex字符串。存储Token必须与用户会话Session绑定存储。通常是将Token存入服务器端的Session存储中如Redis、MemcachedKey可以是csrf_token:{sessionId}。绝对不要将Token直接放在Cookie里返回否则就退化为“双重Cookie验证”方案且可能因Cookie被自动携带而降低安全性。Token的分发与嵌入传统多页应用(MPA)在渲染表单的页面时从Session中取出Token放入一个隐藏的input字段。form action/change-password methodPOST input typehidden namecsrf_token value生成的随机令牌值 !-- 其他表单字段 -- input typepassword namenew_password button typesubmit修改密码/button /form单页应用(SPA)这是同步令牌模式最头疼的地方。SPA通常通过API获取数据页面本身是静态的。一个常见的模式是在用户登录成功后或应用初始化时专门调用一个API如GET /api/csrf-token来获取最新的CSRF Token。服务端生成Token并存入Session然后通过响应体如JSON返回给前端。前端获取后将其存储在内存如Vuex、Redux或Web StoragesessionStorage中。注意不要存到localStorage因为它生命周期太长且可能被XSS攻击读取。在发起任何非幂等的请求POST, PUT, DELETE, PATCH时前端需要从存储中取出Token将其添加到请求参数或自定义Header中如X-CSRF-TOKEN。Token的校验服务端在接收到请求后从请求中提取Token从参数或Header中同时从当前用户的Session中取出之前存储的Token。进行字符串比较建议使用恒定时间比较函数如hash_equalsin PHP以防时序攻击。校验成功后强烈建议使当前Session中的Token失效删除或更新即采用“一次一用”原则。对于某些需要支持“后退”按钮或短暂并发的场景可以允许Token在短时间内重复使用但这会略微降低安全性需谨慎评估。实操心得Token的“一次一用”与并发请求的冲突这是实战中高频出现的坑。假设用户快速连续点击两次提交按钮第一个请求消耗了Token第二个请求就会因Token失效而失败导致用户困惑。解决方案有几种1) 采用“双Token”机制一个用于校验一个用于刷新2) 允许Token在极短时间窗口内如2秒被重复使用3) 前端在发起请求后禁用提交按钮直到收到响应。具体选择需结合业务交互复杂度来定。2.2 方案二双重Cookie验证 (Double Submit Cookie) —— 无状态架构的利器这个方案巧妙利用了Cookie的同源策略。其核心是服务端生成一个随机Token将其同时设置在Cookie里通过Set-Cookie响应头和返回给客户端如嵌入JSON。前端在发起请求时需要手动将这个Token从Cookie中读出通过document.cookie前提是该Cookie未设置HttpOnly并将其作为参数或请求头如X-CSRF-TOKEN随请求一起发送。服务端收到请求后只需比对请求中的Token值和Cookie中的Token值是否一致。为什么它有效攻击者可以伪造请求并带上参数但他无法因同源策略读取或设置目标站点的Cookie。因此他无法让请求中的Token参数与受害者Cookie中的Token值匹配。实操要点与深度解析实现流程用户访问站点服务端生成随机TokenR。服务端在响应中设置CookieSet-Cookie: csrf_tokenR; Path/; Secure; SameSiteLax。注意这里Cookie不能设置HttpOnly因为前端JS需要读取它。同时服务端将TokenR通过其他方式如JSON响应体传给前端。前端将TokenR保存通常在内存中。前端发起敏感请求时从保存处取出TokenR将其添加到请求参数如?csrf_tokenR或请求头如X-CSRF-TOKEN: R。服务端接收到请求从Cookie中读取csrf_token的值从请求参数/头中读取提交的Token值进行比对。优势与适用场景无状态/分布式友好由于校验逻辑只是比对两个来自客户端的值不需要查询服务器端的Session存储因此非常适合RESTful API、微服务等无状态架构也避免了Session同步或共享的问题。实现相对简单省去了服务端Token存储和管理的开销。核心风险与规避措施子域漏洞 (Subdomain Vulnerability)如果应用部署在app.example.com而Cookie的Domain被设置为.example.com那么任何*.example.com的子域都能读取到这个Cookie。如果攻击者控制了attacker.example.com他就可以通过AJAX请求读取到受害者的CSRF Token Cookie从而完成攻击。防御将CSRF Token Cookie的Domain设置为当前主域的最小范围避免使用顶级域。或者更推荐使用SameSiteStrict或Lax属性它能从根本上限制Cookie的跨站发送。Cookie篡改风险由于Cookie能被前端JS读取它也暴露给了站内的XSS攻击。如果网站存在XSS漏洞攻击者脚本可以轻易读取Cookie中的Token。防御这是双重Cookie验证的固有弱点。因此必须与严格的XSS防御措施结合使用如输入输出编码、内容安全策略(CSP)等。也可以考虑将Token的一部分放在HttpOnly的Cookie中另一部分由前端携带进行组合校验增加攻击复杂度。2.3 方案三自定义请求头 (Custom Header) —— Ajax请求的守护者这个方案基于一个简单的事实浏览器允许JavaScript在发起跨域请求时添加自定义请求头但浏览器不会允许攻击者从第三方网站发起跨域请求时携带自定义请求头在预检请求环节就会被阻止。因此我们可以在服务端要求所有“非简单请求”通常是修改数据的POST、PUT等必须携带一个特定的自定义头如X-Requested-With: XMLHttpRequest。为什么它有效它利用了浏览器的CORS跨源资源共享策略。对于“非简单请求”浏览器会先发送一个OPTIONS方法的预检请求。攻击者无法控制受害者浏览器发送的预检请求中的头信息因此无法通过预检真正的攻击请求也就发不出去。实操要点与深度解析实现方法前端在使用XMLHttpRequest或Fetch API发起请求时显式设置一个自定义Header。// 使用Fetch API fetch(/api/change-password, { method: POST, headers: { Content-Type: application/json, X-Custom-CSRF-Header: 固定值或动态令牌 // 自定义头 }, body: JSON.stringify({ newPassword: xxx }) });后端在拦截器或中间件中检查敏感端点非GET、HEAD等的请求是否包含了约定的自定义头。如果没有直接拒绝返回403状态码。优势与局限优势实现极其简单对于纯前后端分离、完全基于Ajax交互的应用防御效果非常好。致命局限它只对由JavaScript发起的请求有效。对于通过HTMLform元素提交、img src...、script src...等浏览器自动发起的请求攻击者无法添加自定义头因此此方案完全无效。这意味着如果你的应用还有传统的表单提交或者未来可能增加这个方案就存在防御缺口。最佳实践切勿单独使用永远不要将自定义请求头作为唯一的CSRF防御手段。它应该作为“同步令牌”或“双重Cookie验证”的补充为Ajax请求增加一道额外的校验。头的值可以动态化为了增加安全性可以不让头的值固定而是让前端从某个接口获取一个动态值类似Token这样即使攻击者通过某种方式知道了头的名称也不知道具体的值。2.4 方案四SameSite Cookie属性 —— 浏览器原生的防线这是近年来最有效的CSRF缓解措施之一它直接在Cookie上设置了一个属性告诉浏览器在什么情况下可以发送这个Cookie。它有三个值Strict最严格。Cookie仅在同站请求即当前站点自身的导航时发送。这意味着如果用户从百度搜索结果页点击链接进入你的网站连最初的请求都不会携带Strict模式的Cookie可能导致用户“未登录”状态。适合安全性要求极高的操作。Lax默认值宽松模式。在跨站请求中仅对安全HTTPS的顶级导航如点击链接发送Cookie而对子资源请求如图片、iframe、Ajax则不发送。这平衡了安全性和用户体验是大多数场景的推荐设置。NoneCookie将在所有上下文中发送即允许跨站发送。必须与Secure属性仅限HTTPS一同使用。为什么它有效它从传输层截断了攻击路径。对于Lax或Strict的Cookie当攻击者试图从evil.com向your-bank.com发起一个POST表单提交或GET请求通过img标签时浏览器根本不会携带用户的认证Cookie请求到达服务器时就是未认证状态攻击自然失败。实操要点与深度解析如何设置在服务端设置Cookie时添加SameSite属性。Set-Cookie: sessionidxxxx; Path/; HttpOnly; Secure; SameSiteLax对于需要跨站使用的Cookie例如用于嵌入式组件的第三方Cookie才需要设置为SameSiteNone; Secure。带来的变化与适配“Lax”成为现代浏览器的默认值Chrome、Firefox等主流浏览器现在默认将未明确指定SameSite的Cookie视为Lax。这意味着如果你的老应用依赖跨站发送Cookie比如第三方登录回调现在可能会出问题。测试与兼容在应用此策略前必须进行全面测试确保所有关键业务流程特别是涉及跨站跳转的OAuth、支付回调等不受影响。对于受影响且必须跨站的场景需要将特定Cookie显式设置为SameSiteNone; Secure。定位与组合SameSite是防御CSRF的基础性、低成本、高收益的方案。我建议所有新项目从一开始就将会话Cookie设置为SameSiteLax。但它不是万能的。一方面仍有部分旧版本浏览器不支持此属性另一方面Lax模式对于某些特定类型的攻击如某些GET类型的CSRF防护可能不彻底。因此它必须与其他服务端校验方案如同步令牌结合使用形成纵深防御。3. 方案选型与组合策略实战指南了解了四种方案到底该怎么选我的建议是不要单选要组合。根据你的应用架构和安全等级可以参考以下策略策略A传统服务端渲染MPA应用核心防御同步令牌 (Synchronizer Token Pattern)。为所有执行状态变更操作的表单POST嵌入并校验Token。加固措施为所有Cookie设置SameSiteLax或Strict。对关键操作如转账、修改密码实施二次认证如密码、短信验证码这不仅能防CSRF也能防会话劫持。实施要点确保Token与Session绑定且一次一用。处理好表单重复提交的问题。策略B现代前后端分离SPA API应用核心防御双重Cookie验证 (Double Submit Cookie) 或 同步令牌的API变种。双重Cookie流登录后/api/login接口在响应中设置csrf_tokenCookie并返回Token值。前端将Token存入内存并在后续所有非幂等请求的Header如X-CSRF-TOKEN中携带。服务端比对Header和Cookie中的值。API令牌流前端在初始化时调用GET /api/csrf-token获取Token存入内存/sessionStorage后续请求在Header中携带。加固措施强制为所有Cookie设置SameSiteLax。推荐为所有API请求增加自定义请求头校验如X-Requested-With作为额外防线。启用CORS策略严格配置Access-Control-Allow-Origin避免任意源访问。实施严格的输入验证和输出编码防御XSS因为XSS会破坏大多数CSRF防御。策略C高安全等级应用如金融、政务必须组合同步令牌 SameSiteStrictCookie 关键操作二次认证。进阶考虑使用反CSRF令牌库管理令牌的生成、绑定、校验和过期。在关键页面如交易确认页增加用户交互验证例如要求拖动滑块、点击特定图案等确保是真人操作。监控异常请求模式如短时间内同一令牌在不同地理位置的使用。4. 常见漏洞场景、测试与排查实录即使部署了防御也可能因为实现不当而留下漏洞。下面是一些我实战中遇到的典型问题及排查思路。漏洞场景1Token校验逻辑被绕过现象系统部署了Token校验但攻击依然成功。排查检查校验顺序中间件或拦截器的顺序是否正确是否在认证检查之后、业务逻辑之前执行CSRF校验我曾见过把校验放在日志记录之后的攻击请求已被记录但业务照样执行。检查Token比对逻辑是否使用了弱类型比较而不是或专门的恒定时间比较函数攻击者可能提交0、false等值在某些语言弱类型比较下可能匹配。检查Token获取来源代码是否只从POST参数中取Token如果攻击者将Token放在GET查询字符串或Header中是否能绕过应统一校验逻辑明确只接受来自特定位置如HeaderX-CSRF-TOKEN的Token。检查Session绑定Token是否真的和当前登录用户的Session绑定了是否存在全局共享Token池的bug漏洞场景2双重Cookie验证中的子域劫持现象公司主域为company.com内部系统hr.company.com和oa.company.com共享了顶级域Cookie。攻击者利用oa系统的一个XSS漏洞窃取了用户在hr系统的CSRF Token。根因CSRF Token Cookie的Domain被设置为.company.com。修复将CSRF Token Cookie的Domain严格设置为各自子域如hr.company.com。同时确保所有子域都实施了严格的XSS防护和CSP。漏洞场景3SameSite Lax的“漏网之鱼”现象设置了SameSiteLax但通过Burp Suite测试发现某些GET请求的CSRF攻击依然可能成功例如利用img src”/delete-account?confirmtrue”。分析Lax模式允许在顶级导航如点击链接时发送Cookie给GET请求。如果某个关键操作如删除账户是通过GET方法实现的这就存在风险。铁律永远不要用GET方法执行具有副作用的操作。遵循RESTful规范状态变更必须使用POST、PUT、DELETE等方法。这是防御CSRF和保证API语义正确性的基本原则。使用Burp Suite进行CSRF漏洞测试的实战流程抓取请求拦截一个正常的修改密码请求例如POST /change-password。生成测试POC在Burp的Proxy历史记录中右键该请求选择Engagement tools-Generate CSRF PoC。Burp会自动生成一个包含该请求的HTML表单。移除防御参数在生成的PoC HTML中手动删除你认为可能是CSRF Token的参数如csrf_token、X-CSRF-TOKENheader对应的隐藏域。模拟攻击将修改后的PoC HTML保存在浏览器中打开模拟受害者访问了恶意页面。观察表单是否会自动提交以及服务器是否接受了这个缺少Token的请求。深度测试如果系统使用双重Cookie验证尝试在PoC中通过JavaScript读取Cookie这需要目标站点存在XSS或Cookie未设置HttpOnly。如果使用自定义Header尝试在PoC中添加该Header浏览器会阻止但可以验证服务端是否真的校验了它。防御CSRF是一个系统工程需要开发、运维、测试共同关注。作为开发者理解原理选择并正确实现适合自己业务的组合方案作为测试者要像攻击者一样思考主动使用工具进行验证。安全没有终点唯有持续警惕和不断加固。
1. 项目概述与核心价值上一期我们聊透了CSRF攻击的原理、危害和常见攻击场景相信大家已经对“跨站请求伪造”这个老牌但依然活跃的Web安全漏洞有了深刻的理解。原理懂了但光懂原理没用关键是怎么防。很多开发者在面对安全需求时常常陷入两个极端要么觉得加个Token就万事大吉要么被各种安全术语和方案搞得晕头转向最后可能选了个并不适合自己业务场景的方案要么防御过度影响体验要么防御不足留下隐患。这期内容我们就来点实在的。我将结合自己十多年在前后端安全对抗中的实战经验为你拆解四种经过大量线上业务验证、可直接落地的CSRF防御方案。我不会只告诉你“用什么”更重要的是讲清楚“为什么用这个”以及“怎么用才不出错”。这四种方案覆盖了从经典通用到前沿强制的不同层次你可以根据自己项目的技术栈、业务复杂度和安全等级像搭积木一样组合使用。无论是刚上线的创业项目还是承载亿级流量的成熟系统都能在这里找到适合你的防御策略。2. 四种可落地防御方案全景解析在深入每个方案之前我们必须建立一个核心认知没有一种安全方案是银弹。CSRF防御的本质是增加攻击者伪造请求的难度直至成本高到不可行。我们的目标是在安全、用户体验和开发维护成本之间找到一个最佳平衡点。下面这张表概括了四种方案的核心思路、适用场景和优缺点你可以快速建立一个全局视图防御方案核心防御思路典型适用场景优点缺点与注意事项同步令牌 (Synchronizer Token Pattern)服务端生成随机令牌随页面下发请求时校验。传统服务端渲染应用、表单提交、关键操作如转账、改密。原理简单防御力强业界最广泛验证。需解决令牌存储、分发、校验的完整链路对单页应用(SPA)不友好。双重Cookie验证 (Double Submit Cookie)将随机令牌同时放在Cookie和请求参数/头中服务端比对是否一致。前后端分离架构、API接口、希望简化令牌管理的场景。无需服务端存储会话状态天然支持分布式。依赖浏览器Cookie策略需防范子域漏洞需注意Cookie的HttpOnly和SameSite属性。自定义请求头 (Custom Header)要求前端在发起敏感请求时携带一个自定义的HTTP头如X-Requested-With。基于XMLHttpRequest或Fetch API的异步请求Ajax。实现简单防御效果可靠同源策略保护。仅对异步请求有效对通过form、img等标签发起的请求无效。SameSite Cookie属性从浏览器层面限制Cookie的发送场景直接阻止跨站请求携带认证Cookie。所有依赖Cookie进行会话管理的Web应用。从源头防御近乎零开发成本现代浏览器广泛支持。需要权衡Lax和Strict模式对用户体验的影响需考虑老旧浏览器兼容性。这四种方案并非互斥在实际项目中我强烈推荐采用“组合拳”策略。例如为所有Cookie设置SameSiteLax作为基础防线对关键API采用“同步令牌”或“双重Cookie验证”并对所有Ajax请求强制校验自定义请求头。接下来我们逐一深入每个方案的实现细节、坑点和最佳实践。2.1 方案一同步令牌 (Synchronizer Token Pattern) —— 经典之选这是防御CSRF最经典、最根本的方法其原理是“一次一密”。服务端为每个用户会话生成一个高强度的、不可预测的随机字符串即CSRF Token在渲染页面时将其嵌入如表单的隐藏域、Meta标签。当用户提交请求时必须将这个Token一并带回服务端进行校验匹配则通过不匹配或缺失则拒绝。为什么它有效攻击者可以伪造请求的URL和参数但他无法在遵守同源策略的前提下读取目标站点页面中的内容因此他无法获知这个每次都在变化的Token值。实操要点与深度解析Token的生成与存储生成必须使用密码学安全的随机数生成器CSPRNG。在Java中可用java.security.SecureRandom在Node.js中可用crypto.randomBytes()在Python中可用secrets.token_urlsafe()。Token长度建议32字节256位以上编码为Base64或Hex字符串。存储Token必须与用户会话Session绑定存储。通常是将Token存入服务器端的Session存储中如Redis、MemcachedKey可以是csrf_token:{sessionId}。绝对不要将Token直接放在Cookie里返回否则就退化为“双重Cookie验证”方案且可能因Cookie被自动携带而降低安全性。Token的分发与嵌入传统多页应用(MPA)在渲染表单的页面时从Session中取出Token放入一个隐藏的input字段。form action/change-password methodPOST input typehidden namecsrf_token value生成的随机令牌值 !-- 其他表单字段 -- input typepassword namenew_password button typesubmit修改密码/button /form单页应用(SPA)这是同步令牌模式最头疼的地方。SPA通常通过API获取数据页面本身是静态的。一个常见的模式是在用户登录成功后或应用初始化时专门调用一个API如GET /api/csrf-token来获取最新的CSRF Token。服务端生成Token并存入Session然后通过响应体如JSON返回给前端。前端获取后将其存储在内存如Vuex、Redux或Web StoragesessionStorage中。注意不要存到localStorage因为它生命周期太长且可能被XSS攻击读取。在发起任何非幂等的请求POST, PUT, DELETE, PATCH时前端需要从存储中取出Token将其添加到请求参数或自定义Header中如X-CSRF-TOKEN。Token的校验服务端在接收到请求后从请求中提取Token从参数或Header中同时从当前用户的Session中取出之前存储的Token。进行字符串比较建议使用恒定时间比较函数如hash_equalsin PHP以防时序攻击。校验成功后强烈建议使当前Session中的Token失效删除或更新即采用“一次一用”原则。对于某些需要支持“后退”按钮或短暂并发的场景可以允许Token在短时间内重复使用但这会略微降低安全性需谨慎评估。实操心得Token的“一次一用”与并发请求的冲突这是实战中高频出现的坑。假设用户快速连续点击两次提交按钮第一个请求消耗了Token第二个请求就会因Token失效而失败导致用户困惑。解决方案有几种1) 采用“双Token”机制一个用于校验一个用于刷新2) 允许Token在极短时间窗口内如2秒被重复使用3) 前端在发起请求后禁用提交按钮直到收到响应。具体选择需结合业务交互复杂度来定。2.2 方案二双重Cookie验证 (Double Submit Cookie) —— 无状态架构的利器这个方案巧妙利用了Cookie的同源策略。其核心是服务端生成一个随机Token将其同时设置在Cookie里通过Set-Cookie响应头和返回给客户端如嵌入JSON。前端在发起请求时需要手动将这个Token从Cookie中读出通过document.cookie前提是该Cookie未设置HttpOnly并将其作为参数或请求头如X-CSRF-TOKEN随请求一起发送。服务端收到请求后只需比对请求中的Token值和Cookie中的Token值是否一致。为什么它有效攻击者可以伪造请求并带上参数但他无法因同源策略读取或设置目标站点的Cookie。因此他无法让请求中的Token参数与受害者Cookie中的Token值匹配。实操要点与深度解析实现流程用户访问站点服务端生成随机TokenR。服务端在响应中设置CookieSet-Cookie: csrf_tokenR; Path/; Secure; SameSiteLax。注意这里Cookie不能设置HttpOnly因为前端JS需要读取它。同时服务端将TokenR通过其他方式如JSON响应体传给前端。前端将TokenR保存通常在内存中。前端发起敏感请求时从保存处取出TokenR将其添加到请求参数如?csrf_tokenR或请求头如X-CSRF-TOKEN: R。服务端接收到请求从Cookie中读取csrf_token的值从请求参数/头中读取提交的Token值进行比对。优势与适用场景无状态/分布式友好由于校验逻辑只是比对两个来自客户端的值不需要查询服务器端的Session存储因此非常适合RESTful API、微服务等无状态架构也避免了Session同步或共享的问题。实现相对简单省去了服务端Token存储和管理的开销。核心风险与规避措施子域漏洞 (Subdomain Vulnerability)如果应用部署在app.example.com而Cookie的Domain被设置为.example.com那么任何*.example.com的子域都能读取到这个Cookie。如果攻击者控制了attacker.example.com他就可以通过AJAX请求读取到受害者的CSRF Token Cookie从而完成攻击。防御将CSRF Token Cookie的Domain设置为当前主域的最小范围避免使用顶级域。或者更推荐使用SameSiteStrict或Lax属性它能从根本上限制Cookie的跨站发送。Cookie篡改风险由于Cookie能被前端JS读取它也暴露给了站内的XSS攻击。如果网站存在XSS漏洞攻击者脚本可以轻易读取Cookie中的Token。防御这是双重Cookie验证的固有弱点。因此必须与严格的XSS防御措施结合使用如输入输出编码、内容安全策略(CSP)等。也可以考虑将Token的一部分放在HttpOnly的Cookie中另一部分由前端携带进行组合校验增加攻击复杂度。2.3 方案三自定义请求头 (Custom Header) —— Ajax请求的守护者这个方案基于一个简单的事实浏览器允许JavaScript在发起跨域请求时添加自定义请求头但浏览器不会允许攻击者从第三方网站发起跨域请求时携带自定义请求头在预检请求环节就会被阻止。因此我们可以在服务端要求所有“非简单请求”通常是修改数据的POST、PUT等必须携带一个特定的自定义头如X-Requested-With: XMLHttpRequest。为什么它有效它利用了浏览器的CORS跨源资源共享策略。对于“非简单请求”浏览器会先发送一个OPTIONS方法的预检请求。攻击者无法控制受害者浏览器发送的预检请求中的头信息因此无法通过预检真正的攻击请求也就发不出去。实操要点与深度解析实现方法前端在使用XMLHttpRequest或Fetch API发起请求时显式设置一个自定义Header。// 使用Fetch API fetch(/api/change-password, { method: POST, headers: { Content-Type: application/json, X-Custom-CSRF-Header: 固定值或动态令牌 // 自定义头 }, body: JSON.stringify({ newPassword: xxx }) });后端在拦截器或中间件中检查敏感端点非GET、HEAD等的请求是否包含了约定的自定义头。如果没有直接拒绝返回403状态码。优势与局限优势实现极其简单对于纯前后端分离、完全基于Ajax交互的应用防御效果非常好。致命局限它只对由JavaScript发起的请求有效。对于通过HTMLform元素提交、img src...、script src...等浏览器自动发起的请求攻击者无法添加自定义头因此此方案完全无效。这意味着如果你的应用还有传统的表单提交或者未来可能增加这个方案就存在防御缺口。最佳实践切勿单独使用永远不要将自定义请求头作为唯一的CSRF防御手段。它应该作为“同步令牌”或“双重Cookie验证”的补充为Ajax请求增加一道额外的校验。头的值可以动态化为了增加安全性可以不让头的值固定而是让前端从某个接口获取一个动态值类似Token这样即使攻击者通过某种方式知道了头的名称也不知道具体的值。2.4 方案四SameSite Cookie属性 —— 浏览器原生的防线这是近年来最有效的CSRF缓解措施之一它直接在Cookie上设置了一个属性告诉浏览器在什么情况下可以发送这个Cookie。它有三个值Strict最严格。Cookie仅在同站请求即当前站点自身的导航时发送。这意味着如果用户从百度搜索结果页点击链接进入你的网站连最初的请求都不会携带Strict模式的Cookie可能导致用户“未登录”状态。适合安全性要求极高的操作。Lax默认值宽松模式。在跨站请求中仅对安全HTTPS的顶级导航如点击链接发送Cookie而对子资源请求如图片、iframe、Ajax则不发送。这平衡了安全性和用户体验是大多数场景的推荐设置。NoneCookie将在所有上下文中发送即允许跨站发送。必须与Secure属性仅限HTTPS一同使用。为什么它有效它从传输层截断了攻击路径。对于Lax或Strict的Cookie当攻击者试图从evil.com向your-bank.com发起一个POST表单提交或GET请求通过img标签时浏览器根本不会携带用户的认证Cookie请求到达服务器时就是未认证状态攻击自然失败。实操要点与深度解析如何设置在服务端设置Cookie时添加SameSite属性。Set-Cookie: sessionidxxxx; Path/; HttpOnly; Secure; SameSiteLax对于需要跨站使用的Cookie例如用于嵌入式组件的第三方Cookie才需要设置为SameSiteNone; Secure。带来的变化与适配“Lax”成为现代浏览器的默认值Chrome、Firefox等主流浏览器现在默认将未明确指定SameSite的Cookie视为Lax。这意味着如果你的老应用依赖跨站发送Cookie比如第三方登录回调现在可能会出问题。测试与兼容在应用此策略前必须进行全面测试确保所有关键业务流程特别是涉及跨站跳转的OAuth、支付回调等不受影响。对于受影响且必须跨站的场景需要将特定Cookie显式设置为SameSiteNone; Secure。定位与组合SameSite是防御CSRF的基础性、低成本、高收益的方案。我建议所有新项目从一开始就将会话Cookie设置为SameSiteLax。但它不是万能的。一方面仍有部分旧版本浏览器不支持此属性另一方面Lax模式对于某些特定类型的攻击如某些GET类型的CSRF防护可能不彻底。因此它必须与其他服务端校验方案如同步令牌结合使用形成纵深防御。3. 方案选型与组合策略实战指南了解了四种方案到底该怎么选我的建议是不要单选要组合。根据你的应用架构和安全等级可以参考以下策略策略A传统服务端渲染MPA应用核心防御同步令牌 (Synchronizer Token Pattern)。为所有执行状态变更操作的表单POST嵌入并校验Token。加固措施为所有Cookie设置SameSiteLax或Strict。对关键操作如转账、修改密码实施二次认证如密码、短信验证码这不仅能防CSRF也能防会话劫持。实施要点确保Token与Session绑定且一次一用。处理好表单重复提交的问题。策略B现代前后端分离SPA API应用核心防御双重Cookie验证 (Double Submit Cookie) 或 同步令牌的API变种。双重Cookie流登录后/api/login接口在响应中设置csrf_tokenCookie并返回Token值。前端将Token存入内存并在后续所有非幂等请求的Header如X-CSRF-TOKEN中携带。服务端比对Header和Cookie中的值。API令牌流前端在初始化时调用GET /api/csrf-token获取Token存入内存/sessionStorage后续请求在Header中携带。加固措施强制为所有Cookie设置SameSiteLax。推荐为所有API请求增加自定义请求头校验如X-Requested-With作为额外防线。启用CORS策略严格配置Access-Control-Allow-Origin避免任意源访问。实施严格的输入验证和输出编码防御XSS因为XSS会破坏大多数CSRF防御。策略C高安全等级应用如金融、政务必须组合同步令牌 SameSiteStrictCookie 关键操作二次认证。进阶考虑使用反CSRF令牌库管理令牌的生成、绑定、校验和过期。在关键页面如交易确认页增加用户交互验证例如要求拖动滑块、点击特定图案等确保是真人操作。监控异常请求模式如短时间内同一令牌在不同地理位置的使用。4. 常见漏洞场景、测试与排查实录即使部署了防御也可能因为实现不当而留下漏洞。下面是一些我实战中遇到的典型问题及排查思路。漏洞场景1Token校验逻辑被绕过现象系统部署了Token校验但攻击依然成功。排查检查校验顺序中间件或拦截器的顺序是否正确是否在认证检查之后、业务逻辑之前执行CSRF校验我曾见过把校验放在日志记录之后的攻击请求已被记录但业务照样执行。检查Token比对逻辑是否使用了弱类型比较而不是或专门的恒定时间比较函数攻击者可能提交0、false等值在某些语言弱类型比较下可能匹配。检查Token获取来源代码是否只从POST参数中取Token如果攻击者将Token放在GET查询字符串或Header中是否能绕过应统一校验逻辑明确只接受来自特定位置如HeaderX-CSRF-TOKEN的Token。检查Session绑定Token是否真的和当前登录用户的Session绑定了是否存在全局共享Token池的bug漏洞场景2双重Cookie验证中的子域劫持现象公司主域为company.com内部系统hr.company.com和oa.company.com共享了顶级域Cookie。攻击者利用oa系统的一个XSS漏洞窃取了用户在hr系统的CSRF Token。根因CSRF Token Cookie的Domain被设置为.company.com。修复将CSRF Token Cookie的Domain严格设置为各自子域如hr.company.com。同时确保所有子域都实施了严格的XSS防护和CSP。漏洞场景3SameSite Lax的“漏网之鱼”现象设置了SameSiteLax但通过Burp Suite测试发现某些GET请求的CSRF攻击依然可能成功例如利用img src”/delete-account?confirmtrue”。分析Lax模式允许在顶级导航如点击链接时发送Cookie给GET请求。如果某个关键操作如删除账户是通过GET方法实现的这就存在风险。铁律永远不要用GET方法执行具有副作用的操作。遵循RESTful规范状态变更必须使用POST、PUT、DELETE等方法。这是防御CSRF和保证API语义正确性的基本原则。使用Burp Suite进行CSRF漏洞测试的实战流程抓取请求拦截一个正常的修改密码请求例如POST /change-password。生成测试POC在Burp的Proxy历史记录中右键该请求选择Engagement tools-Generate CSRF PoC。Burp会自动生成一个包含该请求的HTML表单。移除防御参数在生成的PoC HTML中手动删除你认为可能是CSRF Token的参数如csrf_token、X-CSRF-TOKENheader对应的隐藏域。模拟攻击将修改后的PoC HTML保存在浏览器中打开模拟受害者访问了恶意页面。观察表单是否会自动提交以及服务器是否接受了这个缺少Token的请求。深度测试如果系统使用双重Cookie验证尝试在PoC中通过JavaScript读取Cookie这需要目标站点存在XSS或Cookie未设置HttpOnly。如果使用自定义Header尝试在PoC中添加该Header浏览器会阻止但可以验证服务端是否真的校验了它。防御CSRF是一个系统工程需要开发、运维、测试共同关注。作为开发者理解原理选择并正确实现适合自己业务的组合方案作为测试者要像攻击者一样思考主动使用工具进行验证。安全没有终点唯有持续警惕和不断加固。
