1. 项目概述从一次“被转账”说起如果你是一名网站开发者或者对网络安全稍有了解那你一定听说过XSS跨站脚本攻击。但今天我们要聊的是它的“近亲”一种同样常见却可能更隐蔽、更“自动化”的攻击方式——CSRF全称跨站请求伪造。我第一次真正重视起CSRF是在一次内部安全演练中。我们模拟了一个场景一个已登录内部管理系统的员工在午休时点开了一封伪装成“团建活动投票”的邮件链接。这个链接背后悄无声息地触发了一个请求将他本人的管理员权限添加给了另一个账号。整个过程他本人毫不知情浏览器却“忠实”地完成了所有操作。这就是CSRF攻击的威力。简单来说CSRF攻击就是攻击者诱骗受害者的浏览器以其已登录的身份和权限向目标网站发起一个非本意的请求。这个请求可以是转账、改密、发帖、删数据任何受害者有权执行的操作。它的核心悖论在于网站用来识别用户身份的机制通常是Cookie恰恰成了攻击者利用的武器。而Cookie这个我们日常开发中再熟悉不过的“小饼干”在CSRF攻击中扮演了至关重要的“通行证”角色。理解Cookie在其中的作用是构建有效防御的第一道门槛。这篇文章我将从一个一线开发者的视角彻底拆解CSRF。我们不仅会弄明白它“是什么”和“为什么”能成功更会深入探讨“如何防”。我会结合真实的代码案例、配置细节以及我踩过的坑带你从原理到实战构建起对CSRF的立体防御体系。无论你是刚入门的前端或后端工程师还是希望提升系统安全性的架构师这篇内容都将提供可直接落地的参考。2. CSRF攻击原理深度拆解Cookie为何成为“帮凶”要防御CSRF绝不能停留在“加个Token”的层面。我们必须深入骨髓地理解它的攻击原理尤其是HTTP协议、浏览器行为和会话管理机制之间那个微妙的“信任三角”是如何被打破的。2.1 核心攻击流程与“信任三角”CSRF攻击成功的核心建立在三个前提之上我称之为“信任三角”用户已登录目标网站A站并在浏览器中持有有效的会话标识如Session Cookie。这是攻击的“燃料”。没有身份认证请求毫无意义。目标网站A站完全依赖Cookie这类浏览器自动携带的凭证来验证请求。这是攻击的“漏洞”。网站没有额外的、需要用户主动感知的校验机制。用户在未登出A站的情况下访问了恶意网站B站。这是攻击的“触发器”。B站通过某种方式诱导用户的浏览器向A站发出请求。攻击流程可以浓缩为以下几步用户登录bank.com服务器返回一个包含SessionID的Cookie浏览器保存。用户在同一浏览器中访问了攻击者控制的evil.com。evil.com的页面上隐藏了一个自动提交的表单或者一个img标签其src指向bank.com/transfer?toattackeramount1000。浏览器在加载evil.com时会自动将之前为bank.com存储的Cookie附加到对bank.com/transfer...的请求中。bank.com的服务器收到请求看到带有有效SessionID的Cookie便认为这是用户的合法操作执行转账。整个过程用户可能只在看evil.com的搞笑视频对背后的转账一无所知。2.2 Cookie的核心角色自动化的“双刃剑”Cookie在这里扮演的角色是身份凭证的自动携带者。这是由HTTP协议和浏览器的同源策略SOP中关于Cookie的规则决定的。同源策略与Cookie的发送同源策略限制了不同源协议、域名、端口任一不同的脚本访问彼此的DOM、Cookie等。但是它不限制从一个源向另一个源发送HTTP请求即“跨站请求”。更关键的是浏览器在发送跨站请求时会根据Cookie的作用域Domain和Path规则自动附带上属于目标站点的Cookie。这是浏览器的默认行为旨在提供无缝的用户体验比如保持登录状态。“静默”提交对于GET请求可以通过img、script、link等标签的src属性触发。对于POST请求则可以通过在恶意页面中构造一个隐藏的form并用JavaScript自动submit()。这些操作都不需要用户的任何交互如点击页面加载即触发。注意这里有一个常见的误解认为CSRF需要攻击者“窃取”Cookie。完全不需要攻击者根本不知道你的Cookie值是什么。他只是在利用浏览器“自动发送Cookie”这个机制让受害者的浏览器“帮”他把合法的Cookie带过去。这比窃取Cookie要容易得多。2.3 一个简单的攻击代码示例让我们看一个最简单的GET型CSRF攻击示例。假设银行有一个危险的接口用GET请求处理转账GET /transfer?toAccount攻击者账号amount10000 HTTP/1.1 Host: vulnerable-bank.com Cookie: sessionId用户的真实会话ID攻击者可以在自己的网站(evil.com)上放置这样一段HTML!-- 用户看不见的图片 -- img srchttp://vulnerable-bank.com/transfer?toAccountattacker123amount10000 width0 height0 / !-- 或者诱导用户点击的链接 -- a hrefhttp://vulnerable-bank.com/transfer?toAccountattacker123amount10000 点击领取红包 !-- 诱饵文字 -- /a当已登录银行的用户访问这个页面时浏览器会自动加载图片或用户点击链接带着用户的Cookie发出转账请求。对于POST请求攻击页面会复杂一点但原理相同body onloaddocument.forms[0].submit() form actionhttp://vulnerable-bank.com/transfer methodPOST input typehidden nametoAccount valueattacker123 / input typehidden nameamount value10000 / !-- 如果需要其他参数都可以用隐藏域填充 -- /form /body页面一加载表单便自动提交。3. CSRF防御体系构建从基础到进阶理解了攻击原理防御思路就清晰了打破“信任三角”中的任意一环。我们不能阻止用户登录第一环也很难完全阻止用户访问恶意网站第三环因此防御的重点在于第二环让网站不再单纯依赖浏览器自动携带的凭证来验证请求。下面我将按照从易到难、从通用到强化的顺序详细拆解每一种防御方案。3.1 基础防御良好的开发规范这些是应该写入团队开发规范的最基本要求成本低能抵御大部分“懒汉”式攻击。1. 严格区分HTTP方法关键操作禁用GET这是第一条防线。GET请求的设计初衷是幂等的、安全的仅获取资源它不应该产生副作用。像转账、修改密码、删除数据这类操作必须使用POST、PUT、DELETE等方法。为什么有效这增加了攻击难度。攻击者无法仅通过一个链接或图片标签就触发攻击必须构造一个表单并诱导提交虽然仍可通过JavaScript自动提交但门槛稍高。实操要点在后端路由或控制器层对关键接口的HTTP方法进行严格校验。例如Spring框架中可以使用PostMapping注解明确限制。2. 校验请求来源Referer/Origin HeaderHTTP请求头中的Referer或更现代的Origin字段表明了请求是从哪个页面发起的。我们可以检查这个值是否来自我们自己的域名。如何操作在服务器端拦截请求检查Referer或Origin头。如果存在且来源域名不在白名单内通常只允许自己的域名则拒绝请求。局限性Referer可能被某些浏览器隐私设置或插件移除导致合法请求被误拦。Referer理论上可以被篡改尽管在浏览器环境中很难因此不能作为唯一的安全依赖。Origin头对于跨域POST请求是浏览器自动添加的但对于同域请求或GET请求可能不会发送。建议可以作为一项辅助的、深度防御措施但不能作为主要防御手段。3.2 核心防御Anti-CSRF Token同步器令牌模式这是目前业界防御CSRF最主流、最有效的方法。其核心思想是在请求中增加一个攻击者无法预测、无法伪造的随机值Token服务器通过校验这个Token来确认请求的合法性。3.2.1 Token的生成、存储与校验流程生成当用户会话建立时如登录成功服务器生成一个高强度加密的随机字符串作为CSRF Token。这个Token必须与当前用户会话Session绑定。下发服务器将这个Token放在以下位置之一返回给客户端嵌入在HTML表单中作为一个隐藏字段input typehidden namecsrf_token value...。放在Meta标签中meta namecsrf-token content...供前端JavaScript全局获取。通过Cookie下发注意这不是用于校验的Cookie只是传输载体设置一个Cookie如X-CSRF-Token但HttpOnly属性通常设为false以便前端JS能读取并添加到请求头中。这种方式常用于单页应用(SPA)。携带客户端在发起非幂等请求POST/PUT/DELETE等时必须将这个Token携带上如果是表单随着表单数据一起提交。如果是Ajax请求通常放在一个自定义的HTTP请求头中例如X-CSRF-Token: token值。校验服务器收到请求后从请求体表单字段或请求头中取出客户端提交的Token然后与服务器端为该会话存储的Token进行比对。一致则通过不一致或缺失则拒绝请求。3.2.2 为什么Token能防御CSRF因为同源策略。恶意网站(evil.com)的JavaScript无法读取目标网站(bank.com)下发的Token无论Token是在Cookie中但设置了HttpOnly还是在bank.com的页面DOM中。因此攻击者无法构造出包含有效Token的伪造请求。3.2.3 关键实现细节与避坑指南Token的强度与生命周期强度使用安全的随机数生成器如/dev/urandom,crypto.getRandomValues()长度建议32字节以上。生命周期通常与会话Session绑定用户登录时生成登出时失效。也可以为每个表单或每次请求生成新Token更安全但实现复杂需考虑多标签页并发问题。存储与传输分离推荐模式一种最佳实践是采用“Cookie-to-Header”模式。服务器在用户访问页面时生成Token并将其同时放在两个地方一个HttpOnly的Cookie中例如CSRF-TOKENabc123; HttpOnly; Secure; SameSiteLax。这个Cookie前端JS读不到用于校验。页面的一个Meta标签或全局变量中供前端JS读取。前端JS从Meta标签中读取Token在发起Ajax请求时将其放入一个自定义Header如X-CSRF-Token中。服务器收到请求后从X-CSRF-Token头中获取客户端Token从CSRF-TOKENCookie中获取服务器端Token进行比对。优势即使存在XSS漏洞攻击者能读取到Meta标签中的Token但由于HttpOnlyCookie无法被JS读取他无法伪造一个包含有效Cookie的请求来通过校验因为Cookie是自动带上的他控制不了其值。这提供了双重保障。确保Token校验覆盖所有敏感操作不要遗漏任何可能产生副作用的API端点包括那些看似“只读”但实际会修改状态的接口如“标记为已读”。3.3 现代浏览器的内建防御SameSite Cookie属性这是近年来对抗CSRF的一大利器由浏览器厂商直接实现。通过设置Cookie的SameSite属性你可以直接告诉浏览器“这个Cookie只能在同站Same-Site请求中发送不能用于跨站Cross-Site请求。”3.3.1 SameSite的三个值Strict最严格。Cookie仅在同站请求即当前页面URL的站点与请求目标站点一致时发送。这意味着即使用户从google.com点击一个指向你网站的链接这次跳转请求也不会携带SameSiteStrict的Cookie。这能最大程度防御CSRF但可能影响用户体验例如第三方登录回调。Lax默认值现代浏览器的默认行为一种平衡的选择。允许在顶级导航如点击链接的GET请求中发送Cookie但会阻止在跨站POST请求以及像img,iframe等子资源加载时发送。这能防御大多数CSRF攻击因为CSRF通常依赖自动提交的POST请求或资源加载同时保持了基本的用户体验。NoneCookie可以在所有上下文中发送包括跨站请求。必须与Secure属性一同使用即仅限HTTPS。这是为了兼容一些需要跨站Cookie的旧场景如第三方登录、嵌入式iframe应用等但会完全禁用SameSite保护。3.3.2 如何设置与实战建议在服务器设置Cookie时添加该属性即可Set-Cookie: sessionIdabc123; Path/; Secure; HttpOnly; SameSiteLax建议对于会话Cookie将SameSite设置为Lax或Strict。Lax是当前大多数场景下的推荐值它在安全性和可用性之间取得了良好平衡。对于新项目可以优先考虑Strict。注意SameSite是深度防御的重要一环但不能作为唯一的防御手段。因为并非所有用户的浏览器都支持尽管现代浏览器均已支持。如果攻击发生在你的站点子域名下同站但不同源SameSite无法防御。它主要防御的是由第三方站点发起的CSRF对于存储型XSS等站内漏洞导致的“伪CSRF”攻击无效。3.4 增强验证二次确认与用户交互对于极高风险的操作如转账、修改核心账号信息除了上述技术手段还应引入必须由用户主动完成的二次验证。图形验证码操作前必须输入正确的验证码。由于验证码是动态生成且与当前会话绑定的攻击者无法预先获取或预测。短信/邮箱验证码执行操作前向用户注册的手机或邮箱发送一次性验证码。重新输入密码要求用户再次输入登录密码进行确认。生物识别在移动端或支持的环境下使用指纹、面部识别等。这些方法能从根本上杜绝CSRF因为攻击者无法完成这些需要用户主动参与的交互。但其代价是降低了用户体验因此通常只用于最关键的操作。4. 实战部署与配置详解理论懂了我们来看看具体怎么干。我会以最常见的Web技术栈为例展示如何实现核心的CSRF Token防御。4.1 后端实现以Node.js/Express 前端模板为例1. 生成并注入Token中间件// middleware/csrf.js const crypto require(crypto); function generateCSRFToken(req) { // 生成一个32字节的随机十六进制字符串 return crypto.randomBytes(32).toString(hex); } const csrfProtection (req, res, next) { // 从session中读取或生成token let token req.session.csrfToken; if (!token) { token generateCSRFToken(req); req.session.csrfToken token; // 存储在session中 } // 将token注入到res.locals供模板使用 res.locals.csrfToken token; // 对于非安全方法POST, PUT, DELETE, PATCH进行校验 const safeMethods [GET, HEAD, OPTIONS]; if (!safeMethods.includes(req.method)) { const clientToken req.body._csrf || req.headers[x-csrf-token]; if (!clientToken || clientToken ! req.session.csrfToken) { return res.status(403).send(Invalid CSRF token); } // 校验通过后可以选择刷新token更安全 // req.session.csrfToken generateCSRFToken(req); } next(); }; module.exports csrfProtection;2. 在应用中使用中间件// app.js const express require(express); const session require(express-session); const csrfProtection require(./middleware/csrf); const app express(); app.use(session({ secret: your-secret-key, resave: false, saveUninitialized: false })); app.use(express.urlencoded({ extended: true })); // 解析表单数据 app.use(csrfProtection); // 应用CSRF中间件 // 路由 app.get(/form, (req, res) { // 模板中可以直接使用 res.locals.csrfToken res.render(form-view); }); app.post(/transfer, (req, res) { // CSRF中间件已校验此处可安全处理业务逻辑 const { toAccount, amount } req.body; // ... 执行转账 res.send(Transfer successful!); });3. 在前端模板中嵌入Token!-- form-view.ejs -- form action/transfer methodPOST !-- 关键隐藏的CSRF Token字段 -- input typehidden name_csrf value% csrfToken % label fortoAccount收款账户/label input typetext idtoAccount nametoAccountbr label foramount金额/label input typenumber idamount nameamountbr button typesubmit转账/button /form4.2 单页应用(SPA)的Token管理以Axios为例对于SPAToken通常通过Cookie下发非HttpOnly并由前端JS读取后添加到请求头。1. 后端设置Cookie并响应Token// 登录成功或首次访问API时 app.post(/api/login, (req, res) { // ... 验证逻辑 const csrfToken generateCSRFToken(req); req.session.csrfToken csrfToken; // 将token设置在Cookie中供前端读取和响应体中 res.cookie(X-CSRF-TOKEN, csrfToken, { httpOnly: false, // 允许JS读取 secure: process.env.NODE_ENV production, sameSite: lax }); res.json({ success: true, csrfToken }); // 也可以不通过body返回前端直接从cookie读 });2. 前端Axios拦截器配置// axiosConfig.js import axios from axios; // 从Cookie中读取CSRF Token的函数需要引入js-cookie等库或自己写解析逻辑 function getCSRFToken() { const name X-CSRF-TOKEN; const decodedCookie decodeURIComponent(document.cookie); const ca decodedCookie.split(;); for(let i 0; i ca.length; i) { let c ca[i]; while (c.charAt(0) ) { c c.substring(1); } if (c.indexOf(name) 0) { return c.substring(name.length, c.length); } } return ; } // 创建axios实例 const instance axios.create({ baseURL: /api, }); // 请求拦截器为所有非幂等请求添加CSRF Token头 instance.interceptors.request.use( (config) { const safeMethods [get, head, options]; if (!safeMethods.includes(config.method?.toLowerCase())) { const token getCSRFToken(); if (token) { config.headers[X-CSRF-Token] token; } else { console.warn(CSRF token not found, request might be rejected.); } } return config; }, (error) Promise.reject(error) ); export default instance;4.3 SameSite Cookie的服务器配置Nginx配置示例 在设置Cookie的代理规则或应用返回的Set-Cookie头中添加SameSite属性。Nginx的proxy_cookie_path指令可以修改上游应用返回的Cookie。location / { proxy_pass http://your-backend-app; # 为所有名为sessionid或JSESSIONID的Cookie添加Secure和SameSiteLax属性 proxy_cookie_flags ~ secure samesitelax; }更精细的控制通常在后端应用代码中完成如前面Node.js示例所示。Spring Boot (Java) 配置示例 在application.properties或配置类中全局设置server.servlet.session.cookie.same-sitelax或者在单个响应中设置GetMapping(/set-cookie) public ResponseEntityVoid setCookie(HttpServletResponse response) { ResponseCookie cookie ResponseCookie.from(sessionId, value) .httpOnly(true) .secure(true) .sameSite(Lax) .path(/) .build(); response.addHeader(HttpHeaders.SET_COOKIE, cookie.toString()); return ResponseEntity.ok().build(); }5. 常见问题、排查技巧与进阶思考在实际开发和运维中你会遇到各种各样关于CSRF防御的问题。下面是我整理的一些典型场景和解决思路。5.1 常见问题速查表问题现象可能原因排查步骤与解决方案CSRF校验总是失败返回4031. 前端未正确携带Token。2. Token已过期Session失效。3. 多标签页操作Token被覆盖。4. 前端缓存了旧页面表单中的Token是旧的。1. 检查浏览器开发者工具F12的“网络(Network)”标签查看请求是否包含_csrf字段或X-CSRF-Token头值是否正确。2. 检查服务器端Session生命周期。考虑延长Session时间或使用更持久的Token存储方案需权衡安全。3. 考虑使用“每个表单一个Token”或“双Token”策略一个用于页面一个用于校验。4. 在Meta标签中设置meta http-equivCache-Control contentno-cache, no-store或为包含Token的API请求添加缓存破坏参数。SPA中Ajax请求带上了Token仍被拒绝1. Token未正确从Cookie中读取。2. 跨域请求(CORS)下自定义头未被允许。3. 后端校验逻辑错误比较的不是同一个Token。1. 确认Cookie已正确设置httpOnly: false并用document.cookie或库函数测试是否能读到。2. 检查后端CORS配置确保响应头包含Access-Control-Allow-Headers: X-CSRF-Token或你使用的头字段。3. 在后端打印日志对比收到的Token和Session中存储的Token是否完全一致注意空格、编码。设置了SameSiteLax但第三方登录回调失败第三方登录流程是跨站POST请求回调Lax模式会阻止Cookie发送。1.最佳方案将用于第三方登录回调的特定Cookie设置为SameSiteNone; Secure。2. 调整登录流程将回调改为GET请求如果第三方支持因为Lax允许顶级导航的GET请求携带Cookie。移动端App内WebView请求不带Cookie/TokenWebView默认可能不处理Cookie或会话同源策略与浏览器不同。1. 确保WebView已启用Cookie和DOM存储。例如在Android中webView.getSettings().setDomStorageEnabled(true);webView.getSettings().setAppCacheEnabled(true);CookieManager.getInstance().setAcceptCookie(true);2. 考虑为App提供专用的认证方式如Bearer TokenJWT通过URL参数或自定义Header传递绕过Cookie机制。测试环境HTTPS证书不受信任导致SecureCookie无法设置浏览器会拒绝在非HTTPS页面设置SecureCookie。1. 为测试环境部署有效的证书如Let‘s Encrypt免费证书。2.临时方案在测试环境的后端配置中根据环境变量动态决定是否添加Secure和SameSiteNone属性。切勿将此配置用于生产环境5.2 进阶思考与权衡Token存储在哪里Session vs. 专用缓存Session默认简单与用户会话生命周期一致。但如果是分布式服务需要确保Session是共享的如使用Redis存储Session。专用缓存如Redis更灵活可以独立于Session设置TTL便于管理。键可以设计为csrf:userId或csrf:sessionId。每个请求一个TokenPRG vs. 每个会话一个Token每个请求最安全Token使用一次即失效能有效防止重放攻击。但实现复杂需要处理多标签页并发提交后一个请求会使前一个页面的Token失效。每个会话平衡了安全与易用性是大多数框架如Spring Security, Django的默认选择。只要会话安全Token就安全。CSRF与CORS的关系两者常被混淆。CORS跨源资源共享是一种机制允许服务器声明哪些外部源可以访问其资源。CSRF是一种攻击。CORS配置不当如过于宽松的Access-Control-Allow-Origin: *本身不会导致CSRF因为CSRF依赖浏览器自动携带Cookie而CORS下的简单请求如GET、POST withapplication/x-www-form-urlencoded本来就会被发送。但是CORS可以用来限制哪些源可以发送“预检”请求作为深度防御的一部分。防御CSRF主要靠Token和SameSite而不是CORS。API专属客户端移动端/桌面端还需要CSRF防护吗通常不需要。CSRF攻击依赖于浏览器的Cookie自动携带机制。原生App、命令行工具等客户端其HTTP客户端库不会像浏览器那样自动管理和发送Cookie。它们通常使用Bearer Token如JWT等认证方式这些Token需要显式地添加到请求头中因此不受CSRF影响。但前提是你的API不依赖Cookie进行会话管理。5.3 我的个人实操心得防御要分层不要只依赖一种方法。我现在的标准做法是SameSiteLaxCookie CSRF Token双Cookie/Header模式。对于高危操作再叠加二次验证。这样即使某一层被意外绕过比如旧浏览器不支持SameSite还有其他层保护。框架优先除非有极特殊需求否则直接使用成熟框架内建的CSRF防护。比如Spring Security的CsrfFilterDjango的{% csrf_token %}标签Laravel的VerifyCsrfToken中间件。它们经过千锤百炼比自己从头实现要安全、省心得多。你的主要精力应该放在确保这些防护被正确启用和配置上。测试不可或缺将CSRF漏洞测试纳入你的自动化安全测试流程。可以使用像OWASP ZAP、Burp Suite这样的工具进行主动扫描。在代码审查时要特别关注所有状态修改的端点是否都有防护。关注“影子API”最容易出问题的往往不是那些显眼的业务接口而是后台的、运维的、遗留的“影子API”。确保你的防护中间件或过滤器是全局生效的或者有明确的豁免清单并定期审查。用户体验与安全的平衡将SameSite设为Strict可能会破坏一些合法的跨站跳转用户体验如从邮件链接跳回网站。从Lax开始是一个更稳妥的选择。对于二次验证可以通过分析用户设备和行为模式在可信设备上适当减少验证频率。安全是一个持续的过程而非一劳永逸的配置。理解CSRF的原理建立分层的防御体系并保持对新技术如即将到来的Cookie新规范的关注才能让你的应用在复杂的网络环境中保持坚固。