1. 项目概述为什么CSRF是前端安全的“隐形杀手”如果你是一名前端开发者或者对Web安全稍有了解那么XSS跨站脚本攻击的大名你一定听过。相比之下CSRF跨站请求伪造就显得有些“低调”了。很多开发者甚至是一些经验丰富的同行都曾跟我聊起过“CSRF不就是伪造个请求吗感觉破坏力没XSS那么大而且现在浏览器安全机制这么完善应该问题不大吧” 这种想法恰恰是最大的安全隐患。我见过不止一个项目在安全审计时栽在了CSRF上轻则用户数据被篡改重则导致资金损失或核心业务功能被滥用。CSRF的可怕之处在于它的“静默”和“授权性”——攻击者利用的是用户已经获取的、合法的登录凭证在用户毫不知情的情况下代替用户发起一个恶意请求。整个过程用户可能只是在刷着邮件、看着新闻攻击就已经完成了。这个项目我们就来彻底拆解CSRF。我会从一个真实的攻击案例讲起带你一步步理解CSRF的攻击原理、多种攻击形态然后深入到目前主流的几种防御策略从最基础的同源检测到实践中广泛应用的Token验证、双重Cookie再到浏览器原生支持的Samesite Cookie属性。我们不止讲“怎么做”更要讲清楚“为什么这么做”以及每种方案的优缺点和适用场景。最后我还会分享一些在大型项目中落地CSRF防护时遇到的“坑”和实战心得以及如何建立监控体系来查漏补缺。无论你是刚入门的前端还是负责整体架构的资深工程师相信这篇深度解析都能帮你建立起对CSRF全面而立体的防御认知。2. 攻击原理深度剖析CSRF是如何“借刀杀人”的要防御CSRF首先必须吃透它的攻击原理。CSRF的全称是Cross-site request forgery中文叫“跨站请求伪造”。这个名字非常精准地描述了它的两个核心特征“跨站”和“伪造”。我们通过一个简化但经典的攻击流程来理解受害者登录用户小明访问并登录了可信网站bank.com。登录成功后bank.com会在小明的浏览器中设置一个会话Cookie例如sessionidabc123这个Cookie就是小明身份的凭证。保持登录状态小明没有退出bank.com浏览器会一直携带这个Cookie。诱导访问攻击者构造了一个恶意网站evil.com并通过邮件、论坛链接、广告等方式诱导小明点击访问。发起伪造请求evil.com的页面中隐藏了一个自动提交的表单或者一个自动加载的图片标签其目标地址是bank.com的一个敏感操作接口比如转账APIPOST https://bank.com/transfer参数是amount10000toattacker。浏览器自动携带凭证当小明的浏览器加载evil.com页面时会自动向bank.com的转账接口发起请求并且由于同源策略对Cookie的发送限制较松浏览器会自动将bank.com的Cookiesessionidabc123附加到这次请求中。服务器被欺骗bank.com的后端服务器收到了这个转账请求并验证了Cookie。由于Cookie是合法有效的服务器便认为这是小明本人发起的操作于是成功执行了转账。整个过程中攻击者evil.com从未直接窃取小明的Cookie。它只是“借用”了浏览器自动发送Cookie的这个机制伪造了一个来自小明的请求。这就是“借刀杀人”。2.1 CSRF攻击的几种常见类型根据请求方式的不同CSRF攻击主要有以下几种形态GET类型CSRF这是最简单的一种通常利用img、script、link等标签的src属性或者a标签的href属性来发起一个GET请求。!-- 在evil.com的页面中 -- img srchttps://bank.com/transfer?amount10000toattacker width0 height0 /小明访问这个页面时浏览器会尝试加载这张“图片”从而向银行发起一个GET转账请求。虽然现在敏感操作普遍改用POST但历史遗留或设计不当的接口仍可能存在此风险。POST类型CSRF这是目前最常见的形式。攻击者构造一个隐藏的form表单并通过JavaScript自动提交。form idcsrf-form actionhttps://bank.com/transfer methodPOST styledisplay: none; input typehidden nameamount value10000 input typehidden nameto valueattacker /form scriptdocument.getElementById(csrf-form).submit();/script页面加载后表单会自动提交模拟了一次用户POST操作。链接类型CSRF需要用户主动点击链接。攻击者将恶意请求伪装成普通链接诱使用户点击。a hrefhttps://bank.com/transfer?amount10000toattacker 点击领取您的万元红包 /a实操心得不要以为只用POST接口就安全了。在安全评估中我们曾发现一个后台系统的“删除”功能虽然是POST请求但攻击者完全可以通过一个精心构造的钓鱼页面利用上述表单自动提交的方式发起攻击。关键不在于请求方法而在于请求是否可以被第三方网站随意构造且浏览器会自动携带凭证。2.2 CSRF攻击的关键特点与影响范围理解CSRF的特点有助于我们找到防御的突破口攻击发生在第三方网站攻击的源头是evil.com而非被攻击的bank.com。这意味着bank.com无法直接阻止攻击的发生只能增强自身对伪造请求的识别能力。冒用而非窃取凭证攻击者并不知晓Cookie的具体内容只是利用了浏览器自动发送Cookie的机制。这决定了防御思路可以集中在“如何让服务器区分请求是来自用户本意还是第三方伪造”。跨域请求大多数CSRF攻击是跨域的。但需特别注意如果本网站如bank.com存在可以发布用户自定义内容如图片、链接的功能如论坛、评论攻击者可能将恶意代码直接植入本站发起“同域CSRF攻击”这种攻击更难防范因为绕过了简单的“同源检测”。CSRF的影响范围极广几乎所有基于Cookie/Session认证的Web应用都面临风险。常见的攻击场景包括篡改用户资料邮箱、密码、盗取用户资金转账、消费、滥用用户权限发布内容、删除数据、甚至结合其他漏洞进行更深层次的渗透。3. 核心防御策略解析从原理到实战选型防御CSRF的核心思路就是让服务器有能力区分“合法的用户请求”和“伪造的恶意请求”。围绕这个核心业界发展出了几种主流的防御策略各有优劣和适用场景。3.1 同源检测Origin/Referer Check这是最直观的防御思路既然攻击来自第三方网站那我直接拒绝所有来自外域的请求不就行了浏览器在发起跨域请求时通常会携带两个Header来标明请求来源Origin和Referer。Origin Header主要用于POST请求和跨域请求CORS包含协议、域名、端口不包含路径和查询参数。例如Origin: https://bank.com。Referer Header记录了请求页面的完整URL。例如Referer: https://bank.com/transfer/page。防御原理服务器端校验请求头中的Origin或Referer字段判断其值是否与本站的域名bank.com匹配。如果不匹配则拒绝请求。实操要点与坑优先使用OriginOrigin比Referer更可靠因为它不会被页面内的锚点#影响且在一些隐私敏感场景下浏览器策略可能禁止发送Referer。降级策略如果请求中没有Origin头例如IE11或302重定向则降级检查Referer。允许空Referer的情况需要谨慎处理Referer为空的情况。例如用户直接从地址栏输入URL、或从本地书签打开、或HTTPS页面跳转到HTTP页面时Referer可能为空。一个常见的策略是当Referer为空时仅允许安全的GET请求幂等操作对于POST等非幂等操作则要求必须携带有效的Referer或Origin。防止被绕过理论上攻击者可以篡改自己发出的请求头但浏览器出于安全考虑禁止前端JavaScript代码自定义Origin和Referer头。然而一些古老的浏览器如IE6/7或通过Flash等插件发起的请求可能存在漏洞或不可信。因此同源检测不能作为唯一的防御手段。注意事项同源检测是一种轻量级、易于实施的防护可以作为第一道防线。但它无法防御同域下的CSRF攻击例如站内XSS导致的攻击。在实际项目中我们通常将其与Token等更强的手段结合使用。3.2 CSRF Token验证这是目前公认最有效、最主流的CSRF防御方案。其核心思想是要求每个敏感请求都必须携带一个攻击者无法预测的随机值Token服务器通过校验这个Token来确认请求的合法性。防御原理与流程生成与存储用户访问页面时服务器生成一个高强度、随机的Token通常与用户会话绑定并将其埋入页面中如表单的隐藏域、或Meta标签。携带Token当用户提交表单或发起Ajax请求时前端必须将这个Token作为参数通常是POST的body或自定义Header一并提交。验证Token服务器收到请求后比对请求中的Token与当前会话中存储的Token是否一致。一致则通过不一致则拒绝。Token的放置位置与传输方式表单放在隐藏域input typehidden namecsrf_token value随机值。Ajax请求放在请求的Header中是一种更优雅和安全的方式例如X-CSRF-Token: 随机值。这可以避免Token意外通过URLGET请求泄露。Meta标签对于单页应用SPA可以将Token放在HTML的meta标签中供全局JavaScript读取并附加到所有异步请求中。分布式场景下的挑战与解决方案 在单体应用中Token存在服务器的Session里很简单。但在分布式、微服务架构下用户的请求可能被负载均衡到不同的服务器节点Session不共享就成了问题。方案一分布式Session采用Redis、Memcached等中间件存储Session使所有服务节点都能访问到统一的Token。方案二加密TokenEncrypted Token Pattern这是更推荐的方案。Token本身不再是一个随机字符串而是一个由“用户ID时间戳随机数”经过服务器密钥加密后的密文。服务器收到Token后直接解密并验证其有效性和时效性无需查询外部存储。这既解决了分布式一致性问题也减轻了存储压力。// 伪代码示例生成加密Token String token encrypt(userId | timestamp | random, serverSecretKey); // 验证时解密 String plainText decrypt(token, serverSecretKey); // 验证userId是否匹配当前用户timestamp是否在有效期内实操心得Token的生成一定要足够随机使用安全的随机数生成器并且确保每个会话或每个重要页面使用不同的Token即Token绑定会话或页面。绝对不要使用用户ID、时间戳等可预测信息直接作为Token。我们在一次内部攻防演练中就曾因为早期版本Token生成算法过于简单而被破解。3.3 双重Cookie验证这是一种“曲线救国”的思路利用了CSRF攻击“无法读取目标站点Cookie”的特点因为浏览器的同源策略限制了跨域读取Cookie。防御原理用户访问站点时服务器在Set-Cookie时除了常规的会话Cookie再额外设置一个自定义的Cookie例如csrf_token随机值。前端JavaScript代码读取这个Cookie的值。前端在发起请求时将这个Cookie的值以参数的形式例如Query String或Request Body附加到请求中。服务器收到请求后从Cookie中取出csrf_token的值与请求参数中传来的csrf_token值进行比对。两者一致则认为是合法请求。优点实现简单无需像Token方案那样为每个页面动态注入Token前端可以统一拦截所有请求自动添加参数。前后端解耦后端只需校验两个值是否相等逻辑清晰。无状态Token存储在客户端不占用服务器Session。致命缺点Cookie作用域问题为了能让前端JavaScript读取到这个Cookie不能设置为HttpOnly。这本身就是一个安全降级为XSS攻击窃取该Cookie留下了隐患。子域名隔离失效为了在多个子域名下共享这个Cookie通常被设置在顶级域名下如.a.com。这意味着如果任何一个子域名如upload.a.com存在XSS漏洞攻击者就可以修改或读取这个设置在顶级域下的Cookie从而攻破整个主域的所有服务。依赖Cookie携带如果用户浏览器禁用了第三方Cookie或者请求是跨子域且Cookie作用域设置不当可能导致Cookie无法发送从而验证失败。注意事项双重Cookie验证方案因其明显的安全隐患尤其是与XSS结合的风险在现代Web开发中已不推荐作为主要的CSRF防御手段。它更适合作为一种辅助验证或者在内部系统、对XSS有绝对把控的场景下谨慎使用。3.4 Samesite Cookie属性这是从浏览器层面根治CSRF的一种方案。Google在2016年提出了SamesiteCookie属性并已被现代浏览器广泛支持。防御原理Samesite属性告诉浏览器在什么情况下应该发送某个Cookie。SamesiteStrict严格模式Cookie仅在同站请求即当前页面URL的域与请求目标域一致时发送。这意味着如果用户从百度搜索结果点击进入你的网站由于是跨站请求登录Cookie不会被发送用户需要重新登录。这提供了最强的CSRF防护。SamesiteLax宽松模式在跨站请求中只有导航到目标页面的GET请求如点击链接会携带Cookie。而通过img,script加载的资源请求或者通过form methodPOST提交的POST请求则不会携带Cookie。这平衡了安全性和用户体验。SamesiteNoneCookie在所有上下文中发送即禁用Samesite保护。必须与Secure属性仅HTTPS一起使用。如何设置Set-Cookie: sessionidabc123; Path/; HttpOnly; Secure; SameSiteLax优点与局限优点实现极其简单只需后端在设置Cookie时添加一个属性几乎零成本。从源头切断了CSRF攻击的路径第三方请求不携带认证Cookie。局限兼容性虽然现代浏览器都已支持但仍需考虑少量旧版本浏览器的兼容问题。对用户体验的影响Strict模式可能导致用户在从外部链接进入时体验断裂。Lax模式是目前的推荐默认值它能防御大多数CSRF攻击特别是通过img,form发起的但对于某些特定的GET类型敏感操作如果存在防护不足。子域名问题Samesite属性是基于“站”SchemeDomain来判断的。a.com和sub.a.com属于同站Same-Site因此SamesiteLax的Cookie在子域名间请求时会携带。这意味着它不能防御来自同站子域名的CSRF攻击。实操心得将关键的身份认证Cookie设置为SamesiteLax或Strict是目前防御CSRF最简单、最有效且应优先采用的措施。在我们的项目中这已经成为所有新服务的默认配置。对于需要跨站携带Cookie的第三方集成场景如OAuth回调、支付网关回调才需要谨慎使用SamesiteNone; Secure。4. 综合防御体系构建与实战部署在实际的大型项目中单一的防御手段往往不够。我们需要构建一个纵深防御体系并结合开发流程和监控才能将CSRF风险降到最低。4.1 防御策略选型与组合建议没有银弹最佳实践是组合拳。以下是一个推荐的分层防御策略基础层必做为所有关键的会话Cookie设置SamesiteLax属性。这能挡掉绝大部分来自第三方网站的CSRF攻击成本极低收益极高。核心层必做对所有执行非幂等操作POST, PUT, DELETE, PATCH的接口实施CSRF Token验证。Token建议采用加密Token模式以适配分布式架构。Token可以通过服务器的模板引擎渲染到页面或由后端接口在登录后返回前端存储在内存或非HttpOnly的Cookie中并在每次请求时通过自定义Header如X-CSRF-Token发送。增强层推荐实施同源检测Origin/Referer Check作为辅助验证。可以在网关层或Web应用防火墙WAF统一配置对于缺失或来源可疑的请求进行记录或告警。业务层对于特别敏感的操作如转账、修改密码强制要求进行二次验证例如重新输入密码、短信验证码、或使用生物识别。这不仅是防御CSRF也是提升整体账户安全性的重要措施。4.2 前端与后端的协同实现以“加密Token 自定义Header”方案为例说明前后端如何配合后端以Node.js/Express为例const crypto require(crypto); const SECRET_KEY your-very-long-secure-secret-key; // 中间件生成并注入CSRF Token app.use((req, res, next) { if (req.session.userId) { // 生成加密Token: userId timestamp random const timestamp Date.now(); const random crypto.randomBytes(16).toString(hex); const plainText ${req.session.userId}|${timestamp}|${random}; const cipher crypto.createCipher(aes-256-gcm, SECRET_KEY); let token cipher.update(plainText, utf8, hex); token cipher.final(hex); const authTag cipher.getAuthTag().toString(hex); token token : authTag; // 将认证标签附加到Token后 // 将Token放在响应头或直接注入到HTML模板中 res.locals.csrfToken token; // 也可以放在一个非HttpOnly的Cookie中供前端JS读取 res.cookie(X-CSRF-Token, token, { sameSite: strict, secure: true }); } next(); }); // 中间件验证CSRF Token const csrfProtection (req, res, next) { // 1. 检查请求方法仅对非幂等方法进行验证 if ([GET, HEAD, OPTIONS].includes(req.method)) { return next(); } // 2. 从Header中获取Token const tokenFromHeader req.get(X-CSRF-Token); // 或者从Cookie中获取如果是双重Cookie方案 const tokenFromCookie req.cookies[X-CSRF-Token]; const tokenToVerify tokenFromHeader || tokenFromCookie; if (!tokenToVerify) { return res.status(403).json({ error: CSRF token missing }); } try { // 解密并验证Token const [encrypted, authTag] tokenToVerify.split(:); const decipher crypto.createDecipher(aes-256-gcm, SECRET_KEY); decipher.setAuthTag(Buffer.from(authTag, hex)); let decrypted decipher.update(encrypted, hex, utf8); decrypted decipher.final(utf8); const [userId, timestamp, random] decrypted.split(|); // 验证用户ID是否匹配当前会话 if (userId ! req.session.userId) { throw new Error(User mismatch); } // 验证Token是否在有效期内例如5分钟 if (Date.now() - parseInt(timestamp) 5 * 60 * 1000) { throw new Error(Token expired); } // 验证通过 next(); } catch (err) { console.error(CSRF token validation failed:, err); return res.status(403).json({ error: Invalid CSRF token }); } }; // 在需要保护的路由上应用该中间件 app.post(/api/transfer, csrfProtection, (req, res) { // 处理转账逻辑 });前端以Axios为例import axios from axios; // 创建axios实例配置全局拦截器 const apiClient axios.create({ baseURL: /api, headers: { Content-Type: application/json, }, }); // 请求拦截器自动添加CSRF Token到Header apiClient.interceptors.request.use( (config) { // 从Cookie或Meta标签中获取Token const token getCSRFToken(); // 实现一个函数来获取Token if (token ![GET, HEAD, OPTIONS].includes(config.method.toUpperCase())) { config.headers[X-CSRF-Token] token; } return config; }, (error) { return Promise.reject(error); } ); // 响应拦截器处理Token过期等情况 apiClient.interceptors.response.use( (response) response, (error) { if (error.response error.response.status 403) { const errorMsg error.response.data.error; if (errorMsg errorMsg.includes(CSRF)) { // CSRF Token无效或过期可以引导用户刷新页面获取新Token alert(会话已过期请刷新页面重试。); window.location.reload(); } } return Promise.reject(error); } );4.3 防御策略的常见漏洞与规避即使实施了上述策略如果细节处理不当仍可能留下漏洞Token泄露场景如果网站同时存在XSS漏洞攻击者可以通过XSS窃取页面中的CSRF Token。规避CSRF Token防御的前提是没有XSS。必须将防御XSS作为更基础的安全工作。此外可以考虑将Token也放在HttpOnly的Cookie中然后通过前端JavaScript读取该Cookie并附加到请求头这样即使存在XSS脚本也无法直接读取HttpOnly的Cookie但仍有被利用的风险。Token未绑定会话场景整个网站使用同一个静态Token或者Token只绑定用户ID而不绑定会话。攻击者可以先登录自己的账户获取Token然后诱导受害者使用这个Token发起请求。规避Token必须与当前用户会话强绑定。每个会话、甚至每次页面刷新都应生成新的Token。验证逻辑绕过场景后端只验证了POST请求的Token而忽略了GET请求。但某个关键的“删除”操作错误地使用了GET接口。规避遵循RESTful规范确保所有会产生副作用的操作都使用POST、PUT、DELETE等非幂等方法并对所有这些接口进行CSRF防护。同时在网关层或路由层统一配置防护策略避免遗漏。登录态Cookie未设置Samesite场景主Cookie设置了HttpOnly和Secure但忘了设置Samesite导致其仍然会在跨站POST请求中被携带。规避对所有认证Cookie明确设置SameSiteLax或Strict。5. 进阶CSRF监控、测试与安全开发流程防御措施部署后并不意味着可以高枕无忧。我们需要建立持续的监控和测试机制确保防护始终有效。5.1 CSRF漏洞的自动化测试在QA和开发自测阶段可以引入自动化工具或编写测试用例来检测CSRF防护是否缺失。手动测试思路使用浏览器插件如EditThisCookie删除或修改CSRF Token。尝试用一个已登录用户的会话在另一个浏览器或工具如Postman、curl中不携带Token或携带错误Token发起敏感请求看是否会被拒绝。尝试复制一个合法的请求包括Token在Token过期后重放看是否会被拒绝。自动化测试集成 可以将CSRF Token的验证逻辑集成到API测试套件中。例如使用Jest、Mocha等框架编写测试用例来验证未携带Token的请求返回403。携带错误Token的请求返回403。携带正确Token的请求返回成功。5.2 线上监控与告警在网关或应用层日志中可以监控潜在的CSRF攻击行为其特征通常包括请求头缺失关键字段大量403错误且错误原因为“CSRF token missing”或“Invalid origin”。Referer异常敏感接口的请求其Referer来自大量不同的、可疑的第三方域名。User-Agent异常攻击脚本可能使用非常规的User-Agent。可以配置日志分析系统如ELK Stack或应用性能监控APM工具对这类异常模式设置告警以便安全团队及时介入调查。5.3 将CSRF防护融入开发流程最有效的防御是将安全内建于开发过程框架选型选择内置了CSRF防护的现代Web框架如Spring Security, Django, Laravel等并了解其默认配置和原理。安全编码规范在团队编码规范中明确规定所有状态变更的API必须进行CSRF防护。可以在代码审查Code Review环节重点检查。基础设施统一在API网关或反向代理如Nginx层面通过插件或自定义逻辑统一为所有后端服务添加CSRF Token校验或Origin检查减轻业务开发团队的负担。定期安全扫描使用动态应用安全测试DAST工具或聘请专业的安全团队进行渗透测试定期对系统进行CSRF漏洞扫描。6. 总结与个人实战心得回顾CSRF的攻防其本质是一场关于“请求身份”的博弈。攻击者试图让服务器误判请求来源而防御者则千方百计为每一个合法请求打上无法伪造的“烙印”。从我经历过的多个项目来看对于CSRF防护以下几点体会最深第一Samesite Cookie是基石务必优先设置。它从浏览器层面解决了大部分跨站CSRF问题实现简单效果显著。对于新项目这应该是第一个要配置的安全选项。第二CSRF Token是核心设计要严谨。对于关键操作Token验证必不可少。在分布式系统中采用加密Token方案能省去很多分布式Session的麻烦。Token的生成必须强随机绑定会话并具备时效性。前端传递Token时优先使用自定义Header而非请求体这更符合语义且能避免一些意外泄露。第三没有一劳永逸的方案纵深防御是关键。不要依赖单一手段。SamesiteLaxCSRF Token敏感操作二次验证的组合能构建起相当坚固的防线。同时Origin/Referer检查可以作为一道廉价的预警线。第四安全是一个整体CSRF不是孤岛。一个牢固的CSRF防御可能因为一个XSS漏洞而瞬间崩塌。同样安全的密码策略、HTTPS强制实施、输入输出编码等都是整体安全拼图中不可或缺的一块。在项目初期就引入安全考量远比后期修补成本低得多。最后保持对安全动态的关注。浏览器安全特性在持续演进新的攻击手法也可能出现。作为开发者理解这些防御措施背后的原理远比死记硬背配置命令更重要。当你能清晰地回答“为什么这个Token要这样设计”、“Samesite的Lax和Strict区别在哪儿”这些问题时你才真正掌握了抵御CSRF攻击的主动权。