1. 项目概述为什么CSRF依然是悬在头顶的剑最近在内部渗透测试和漏洞赏金项目中CSRF跨站请求伪造漏洞的检出率又悄然回升了。这让我有点意外毕竟这算是一个“古典”漏洞了各种框架都号称内置了防护。但现实是随着前后端分离、微服务架构的普及以及开发人员对“同源策略”的盲目信任CSRF正在以新的形式卷土重来。很多新手安全工程师甚至测试人员对它的理解还停留在“加个Token不就行了”的层面结果在复杂的现代Web应用面前频频翻车。这篇文章我想彻底拆解CSRF。目标很明确让你从完全不懂“跨站请求伪造”这六个字是什么意思的小白成长为能独立挖掘、验证、修复中高危CSRF漏洞的熟手。我会避开教科书式的定义直接用我们渗透测试中遇到的真实案例来贯穿讲解把攻击原理掰开揉碎手把手教你几种实战中最有效的检测方法最后给出不同技术栈下真正靠谱、可落地的防范方案。如果你觉得每次看到CSRF的科普文章都像隔靴搔痒看完还是不会挖洞那这篇就是为你写的。2. CSRF攻击原理深度拆解它到底是如何“伪造”你的很多人把CSRF想象得很复杂其实它的核心诡计非常简单就两个字“借用”。攻击者无法直接窃取你的密码或Session但他可以“借用”你浏览器当前的身份去执行他想要的操作。2.1 核心诡计浏览器“认牌不认人”的机制理解CSRF必须从浏览器处理请求的机制说起。假设你已经登录了网银bank.com浏览器里存有网银服务器颁发的Session Cookie。这个Cookie就是你的“临时身份证”。关键点在于浏览器在向某个域名如bank.com发起请求时会自动、静默地带上该域名下的所有Cookie无论这个请求是从哪里发起的。攻击者就利用了这一点。他构造一个恶意页面这个页面里隐藏着一个向bank.com转账的请求。当你已经登录网银的状态下访问了这个恶意页面浏览器就会自动带着你的网银Session Cookie向bank.com发出转账请求。服务器收到这个请求一看Cookie正确就会认为这是你本人操作的从而执行转账。整个过程攻击者没有碰你的Cookie他只是“诱骗”你的浏览器用你已有的身份去发了一个请求。这就是“伪造”的本质。2.2 一个现代SPA应用中的真实攻击案例教科书总用GET请求转账举例但现在很少有应用这么傻了。我们来看一个更真实的场景来自一次对某SaaS平台的前端渗透测试。该平台前端是Vue.js单页应用SPA后端是RESTful API。用户修改邮箱的流程是前端POST到/api/user/email数据格式为JSON{newEmail: xxxxxx.com}请求头会带上Authorization: Bearer Token。乍一看很安全POSTJSON好像不容易CSRF我们来看攻击链漏洞点我们发现该API虽然要求JSON但服务器同时也接受Content-Type: application/x-www-form-urlencoded格式的数据并且没有严格校验Content-Type头。这是第一个隐患。构造攻击攻击者创建一个恶意网站页面中包含一个自动提交的表单。form idcsrfForm actionhttps://target-saas.com/api/user/email methodPOST input typehidden namenewEmail valueattackerevil.com / /form script document.getElementById(csrfForm).submit(); /script触发攻击已登录该SaaS平台的用户访问了这个恶意网站。浏览器会自动携带该平台域名下的Session Cookie或Token如果存储在Cookie中发起POST请求。结果服务器处理了请求因为Cookie有效且数据格式它也能解析于是成功将用户绑定邮箱修改为攻击者的邮箱。后续密码重置链接就会发到攻击者邮箱。这个案例的要点在于不要以为用了POST、AJAX、JSON就免疫CSRF。如果服务器端没有同步的、不可预测的凭证如CSRF Token进行校验并且浏览器的同源策略没有被正确利用如CORS配置不当攻击依然可能发生。许多现代API默认不防御CSRF认为Bearer Token放在Header里就安全但如果Token被存储在Cookie中一种常见的实现就瞬间沦陷。2.3 CSRF与XSS的本质区别一个必须澄清的误区很多新人会混淆CSRF和XSS跨站脚本攻击。这里必须划清界限XSS目标是用户浏览器和同站点的其他用户。攻击者在网站上注入恶意脚本当其他用户浏览时脚本在其浏览器上下文执行可以窃取该用户的Cookie、操作DOM、发起请求等。XSS是在“你的地盘”目标网站上搞破坏。CSRF目标是服务器。攻击者利用用户浏览器对目标网站的信任以用户的名义发送恶意请求。攻击发生在“我的地盘”攻击者网站上但枪口对准的是“你的服务器”。简单说XSS是“把坏人放进你家”CSRF是“冒充你去你家仓库提货”。防御思路也完全不同防XSS主要靠对用户输入的输出编码防CSRF则要靠服务端验证请求的“意图”是否来自合法的源。3. 实战检测方法论如何像黑客一样寻找CSRF漏洞知道了原理我们怎么把它找出来不能光靠猜。下面是我在渗透测试中常用的一套组合拳从简单到深入。3.1 手动检测与观察老派但有效的第一步工具永远替代不了人的观察。首先用Burp Suite或浏览器开发者工具抓取目标应用的一个关键状态变更请求如修改资料、添加用户、转账。你需要像法医一样检查这个请求检查认证凭证这个请求靠什么认证是Cookie、Authorization Header还是别的如果主要依赖CookieCSRF风险就很高。检查是否存在CSRF Token在请求参数或Header里通常是X-CSRF-TokenX-XSRF-TOKEN等寻找一个长随机字符串。这个Token的值每次页面加载应该变化并且与用户Session绑定。检查自定义Header有些应用会要求请求携带一个自定义Header如X-Requested-With: XMLHttpRequest。注意这不能单独作为防御因为攻击者可以通过Flash或form的target等技巧添加简单Header但结合其他措施可以增加难度。检查Referer/Origin Header服务器可能会校验这两个Header。Origin头在现代浏览器中对于跨域请求会自动添加且不可被前端修改比Referer更可靠。但如果服务器只检查Referer攻击者可能通过某些方式如从HTTPS跳转到HTTP或利用某些浏览器漏洞将其置空或篡改。实操心得不要只看表面。有的应用Token放在meta标签里通过JS读取后塞到Header有的应用Token虽然存在但服务器根本没校验还有的应用对GET请求校验Token对POST请求反而放松了。必须每个关键操作都测。3.2 工具自动化辅助Burp Suite的CSRF PoC生成手动分析后可以用工具快速生成攻击证明PoC。Burp Suite的右键菜单“Engagement tools” - “Generate CSRF PoC”功能非常强大。它的工作原理是把你捕获的请求自动转换成一个包含表单和自动提交脚本的HTML文件。你可以在这个生成器里做很多事情移除Token参数如果请求里有CSRF Token你可以手动删除这个参数模拟攻击者构造的请求。修改请求方法尝试将POST改为GET看看服务器是否还接受。测试Referer绕过生成的PoC可以本地打开file://协议此时Referer头为空可以测试服务器是否因缺失Referer而拒绝请求。生成PoC后在一个已登录目标网站的浏览器中打开这个HTML文件观察操作是否被执行。如果成功一个中高危CSRF漏洞就坐实了。3.3 高级检测技巧针对现代应用的“花式”测试对于前后端分离、使用JWT/Token认证的应用检测需要更精细。Token存储位置审计如果应用使用Token认证务必确认Token存储在哪里。如果存储在localStorage或sessionStorage那么标准的基于Cookie的CSRF攻击无效因为恶意网站无法访问这些存储。但是如果开发为了“方便”将Token也放在了Cookie里比如用于SSR同构应用风险就回来了。CORS配置不当引发的CSRF检查目标API的CORS跨源资源共享策略。如果响应头包含Access-Control-Allow-Origin: *或Access-Control-Allow-Origin: 攻击者域名并且Access-Control-Allow-Credentials: true那么攻击者网站上的JavaScript就可以直接使用你的凭证发起跨域请求这比表单CSRF更强大因为可以发起任意类型的请求PUT, DELETE等并且能读取响应。这本质上是CORS配置错误但效果等同于CSRF。JSON CSRF如前文案例如果API接受application/x-www-form-urlencoded或multipart/form-data格式就可以用表单攻击。如果只接受application/json传统表单不行表单无法直接发送JSON。但攻击者可以通过Flash307状态码重定向等古老技巧或者利用某些浏览器的特性来构造JSON请求。更常见的是如果服务器没有严格校验Content-Type头攻击者依然有机会。4. 从开发视角构建防御体系不只是加个Token那么简单防御CSRF必须站在攻击者的对立面思考如何让服务器能区分“这是用户本意发出的请求”还是“被伪造的请求”核心思路是加入一个攻击者无法预测、无法伪造的凭证。4.1 同步令牌Synchronizer Token Pattern最经典的方案这是最主流、最可靠的方案。原理如下用户访问包含表单的页面时服务器生成一个随机、加密强度高的Token将其与用户Session绑定并同时发送给客户端可以藏在表单的隐藏域input typehidden namecsrf_token valuexxx或放在meta标签里供JS读取。客户端提交表单时必须将这个Token作为参数或自定义Header如X-CSRF-TOKEN一并提交。服务器收到请求后比对提交的Token和Session中存储的Token是否一致且未过期。一致则通过否则拒绝。关键实现细节与避坑指南Token的生成与存储必须使用密码学安全的随机数生成器如Java的SecureRandom Node.js的crypto.randomBytes。Token必须与用户会话绑定存储在服务器端Session或加密的Cookie中。每个表单/会话独立理想情况下每个表单都应使用独立的Token或至少每个会话周期更换Token。避免整个应用使用一个全局Token。Token的提交位置优先放在HTTP Header中如X-CSRF-TOKEN。放在请求体如表单参数中也可以但要防止Token因GET请求而泄露在URL或日志中。最佳实践是同时支持Header和参数但以Header校验优先。对GET请求的处理GET请求不应引起状态变更这是HTTP协议的最佳实践。因此理论上GET请求不需要CSRF Token。如果你的GET请求会修改数据首先应该重构接口改为POST/PUT/DELETE。踩过的坑在一次代码审计中我发现一个系统虽然用了Token但生成算法是MD5(用户ID 时间戳)。攻击者只要知道用户ID通常是公开的就可以轻易推算出Token防御形同虚设。所以Token必须是不可预测的随机数。4.2 双重Cookie验证适合API服务的简易方案在前后端分离且前端域名与后端API域名不同的场景下同步令牌模式有点麻烦需要前端额外获取Token。双重Cookie验证是一个替代方案。用户登录后后端在响应中设置一个Cookie例如csrf_tokenrandom_value。这个Cookie的SameSite属性可以设为Lax或Strict。前端JS从Cookie中读取这个csrf_token的值需要Cookie设置为HttpOnlyfalse这是一个安全权衡在发起非简单请求如POST时将其作为一个自定义Header如X-CSRF-Token发送。后端同时校验请求头中的X-CSRF-Token值和Cookie中的csrf_token值是否一致。优点实现简单前端无需额外请求获取Token。缺点与风险Cookie必须能被JS读取HttpOnlyfalse这增加了被XSS攻击窃取的风险。因此此方案必须建立在已充分防御XSS的前提下。需要仔细配置CORS确保只有可信的前端域名才能访问API。4.3 SameSite Cookie属性浏览器提供的“天然”屏障这是近年来防御CSRF最有效、最省事的方案之一。通过设置Cookie的SameSite属性你可以告诉浏览器在什么情况下发送这个Cookie。SameSiteStrict最严格。浏览器只会在同站请求即当前页面的域名与请求目标域名完全一致中发送此Cookie。这意味着即使用户在A网站点击了指向B网站的链接浏览器也不会携带B网站的StrictCookie。这完全杜绝了CSRF但可能影响用户体验比如从邮件链接点回网站需要重新登录。SameSiteLax默认值现代浏览器的默认行为。在跨站的顶级导航如点击链接且是安全的HTTP方法如GET时会发送Cookie。但对于跨站的POST请求或者通过img,script等标签发起的请求则不会发送。这平衡了安全与可用性能防御大多数CSRF攻击。SameSiteNoneCookie将在所有上下文中发送即跨站请求也会发送。必须与Secure属性一同使用即仅限HTTPS。部署建议 对于会话Cookie强烈建议设置为SameSiteLax或Strict。这能挡掉绝大部分利用form提交和img发起的CSRF攻击。但请注意它不能防御同源下的CSRF比如网站存在XSS漏洞也不能防御某些特定的攻击场景如利用308状态码的跳转。因此应将其视为一道重要的补充防线而非唯一防线。4.4 校验Origin与Referer Header辅助验证手段服务器可以检查请求头中的Origin或Referer字段判断请求来源是否在白名单内。Origin对于跨域请求浏览器会自动添加且前端无法修改。对于同源请求有时不发送。它比Referer更可靠因为不包含路径信息隐私性更好。Referer包含了完整的来源URL。但用户可能出于隐私禁用Referer或者在某些场景下如从HTTPS跳到HTTP浏览器不会发送存在被篡改的历史漏洞。实施要点优先检查Origin头如果存在且合法则通过。如果Origin头不存在同源请求则检查Referer头。必须确保校验逻辑严密防止绕过。例如不能因为头不存在就放行。这只能作为辅助或次要的验证手段不能替代CSRF Token因为其可靠性不如Token。5. 不同技术栈下的具体实现示例理论说再多不如一行代码。这里给出几个主流框架的防御实现要点。5.1 Spring Security (Java)Spring Security默认就提供了CSRF防护对于传统同步Web应用如Thymeleaf, JSP开箱即用。原理它会自动生成一个Token存储在HttpSession中并通过_csrf请求属性暴露给视图层。在表单中你需要添加input typehidden name${_csrf.parameterName} value${_csrf.token} /对于REST API默认配置下Spring Security会对所有非GET,HEAD,TRACE,OPTIONS的请求进行CSRF校验。这对于无状态的REST API很不友好。通常有两种处理方式禁用CSRF在配置中明确对API路径禁用CSRF。http.csrf().disable()。这非常危险除非你确信API通过其他方式如OAuth2 Bearer Token且不存储在Cookie免疫CSRF。使用Token更安全的方式是启用CSRF并让前端从CookieSpring Security默认将Token放在名为XSRF-TOKEN的Cookie中或特定接口获取Token在请求时以Header默认是X-CSRF-TOKEN或参数形式提交。5.2 Django (Python)Django的CSRF中间件django.middleware.csrf.CsrfViewMiddleware提供了强大的防护。模板中使用在模板表单内使用{% csrf_token %}标签即可。针对AJAX请求Django会将CSRF Token设置在名为csrftoken的Cookie中。前端需要从Cookie读取并在AJAX请求的Header中设置X-CSRFTOKEN。// 使用js-cookie库示例 const csrftoken Cookies.get(csrftoken); fetch(/api/endpoint/, { method: POST, headers: { X-CSRFToken: csrftoken, Content-Type: application/json, }, body: JSON.stringify(data) })重要配置确保CSRF_COOKIE_SAMESITE和CSRF_COOKIE_HTTPONLY设置合理。通常CSRF_COOKIE_HTTPONLYFalse因为JS需要读取CSRF_COOKIE_SAMESITELax。5.3 Express.js (Node.js)在Express中通常使用csurf中间件但该库已不再维护。社区推荐使用csrf-csrf或helmet库的xssFilter结合自定义实现。自定义实现示例const crypto require(crypto); const tokens new Map(); // 简单内存存储生产环境用Redis // 生成并返回Token app.get(/csrf-token, (req, res) { const token crypto.randomBytes(32).toString(hex); tokens.set(req.sessionID, token); // 与session绑定 res.json({ csrfToken: token }); }); // 验证中间件 const csrfProtection (req, res, next) { const clientToken req.headers[x-csrf-token] || req.body._csrf; const serverToken tokens.get(req.sessionID); if (!clientToken || clientToken ! serverToken) { return res.status(403).send(Invalid CSRF token); } // 验证通过后可以生成新的Token双重提交 const newToken crypto.randomBytes(32).toString(hex); tokens.set(req.sessionID, newToken); res.setHeader(X-CSRF-Token, newToken); // 可选返回新Token给前端 next(); }; // 受保护的路由 app.post(/api/transfer, csrfProtection, (req, res) { // 处理业务逻辑 });6. 渗透测试中的疑难杂症与排查实录在实际测试中你会遇到各种“看起来防住了”但实则脆弱的情况。这里记录几个典型案例和排查思路。6.1 Token泄露导致的连锁崩溃场景一个系统在用户个人资料页面返回了完整的用户信息JSON里面竟然包含了当前会话的CSRF Token。攻击者如果通过其他漏洞如XSS、信息泄露获取到这个JSON就等于拿到了Token。排查在测试任何接口时不仅要看功能是否正常还要仔细检查响应体、响应头、甚至JS文件注释里是否包含了不该出现的敏感信息如Token、内部密钥、服务器路径等。6.2 验证逻辑缺陷Token可重复使用场景系统使用了Token但服务器验证后没有使旧Token失效。这意味着攻击者只要获取到一个有效的Token比如通过诱使用户点击一个包含合法请求的链接从中截取Token就可以无限次使用它发起伪造请求。测试方法用同一个Token连续发起两次相同请求。如果都成功说明Token未失效存在风险。安全的做法应该是“一次一用”或“一个会话周期内有效用后即废”。6.3 绕过Referer检查的奇技淫巧虽然现在不常见但历史上存在一些绕过Referer检查的方法缺失Referer如果服务器逻辑是“Referer头不存在则跳过检查”攻击者可以构造一个从HTTPS页面跳转到HTTP目标的请求某些浏览器在这种情况下不会发送Referer。或者利用meta标签的referrerpolicyno-referrer。Referer过滤不严如果服务器只检查Referer是否包含某个域名如example.com攻击者可以注册一个子域名attack.example.com或者利用example.com.attacker.com这样的域名来绕过。防御建议不要依赖Referer作为主要防御。如果要用必须进行严格的全等匹配并处理好头缺失的情况应视为非法。6.4 针对JSON API的“盲打”CSRF对于严格只接受JSON的API传统表单攻击无效。但可以尝试“盲打”构造一个简单的HTML页面用fetch或XMLHttpRequest发送JSON请求。由于浏览器的同源策略跨域请求默认会被阻止。但如果服务器CORS配置为Access-Control-Allow-Origin: *且允许凭证攻击脚本就能成功。即使CORS配置正确如果服务器没有校验Content-Type攻击者有时可以通过构造一个form将其enctype设置为text/plain然后提交一个看起来像JSON的文本块某些服务器解析器可能会错误处理。根本的防御服务器端严格校验Content-Type: application/json并结合CSRF Token或SameSite Cookie。7. 企业级安全开发流程中的CSRF防控对于开发团队将CSRF防御融入流程比事后修补更重要。框架选型与安全特性评估在选择Web框架时应将其对CSRF等常见漏洞的默认防护能力作为重要考量。优先选择那些开箱即提供健全、易用CSRF防护机制的框架。安全编码规范在团队编码规范中明确要求所有会导致状态变更的HTTP端点POST, PUT, PATCH, DELETE必须经过CSRF防护中间件或显式校验。可以将此作为代码审查Code Review的必查项。自动化安全测试SAST/DAST在CI/CD流水线中集成静态应用安全测试SAST和动态应用安全测试DAST工具。这些工具可以自动扫描代码中是否存在未受保护的端点或在测试环境中尝试CSRF攻击。定期渗透测试与漏洞评估无论内部防御多完善定期邀请外部安全专家或使用自动化渗透测试平台进行测试是发现逻辑漏洞和配置错误的有效手段。CSRF往往是测试中的基础项目。安全意识培训让所有开发人员特别是前端和API开发者理解CSRF的原理、危害和防御方法。知其然并知其所以然才能避免在无意中引入漏洞。我在推动团队安全建设时习惯把CSRF防御 checklist 贴在项目Wiki首页[ ] 所有状态变更操作是否使用POST/PUT/PATCH/DELETE[ ] 是否为每个用户会话生成不可预测的CSRF Token[ ] Token是否通过安全方式传递优先Header其次表单隐藏域[ ] 服务器端是否对每个相关请求进行严格的Token校验[ ] 会话Cookie是否设置了SameSiteLax或Strict属性[ ] 对于API是否明确了认证方式Bearer Token in Header并禁用了基于Cookie的CSRF保护或实现了适合API的Token验证[ ] CORS策略是否已严格配置禁止使用Access-Control-Allow-Origin: *且Allow-Credentials: true的组合说到底CSRF漏洞的根源在于HTTP协议的无状态性和浏览器默认的信任行为。防御的本质就是打破这种“默认信任”让服务器有能力验证每一个敏感请求的“真实意图”。从开发的第一行代码开始就绷紧这根弦比漏洞出现后再亡羊补牢要有效得多。