1. 项目概述从一次“被转账”说起几年前我在一个内部安全测试项目中遇到了一个让我印象深刻的场景。当时我们模拟一个已登录的银行用户在另一个标签页里访问了一个恶意构造的页面。这个页面看起来人畜无害可能只是一张有趣的图片或者一个“点击抽奖”的按钮。然而就在用户点击的瞬间后台悄无声息地发起了一笔转账请求将用户账户里的资金转到了攻击者的账户。整个过程用户毫无感知因为浏览器自动带上了用户的登录凭证Cookie。这就是典型的跨站请求伪造攻击也就是我们今天要深入拆解的CSRF。CSRF全称Cross-Site Request Forgery中文常译为“跨站请求伪造”。它不像SQL注入那样直接操作数据库也不像XSS那样在页面里弹个窗那么“显眼”。它的核心在于“伪造”和“利用信任”。攻击者诱导受害者在已登录目标网站的状态下去访问一个恶意页面这个页面会携带受害者的身份凭证如Session Cookie向目标网站发起一个非预期的请求如修改密码、转账、发表评论。由于这个请求是从受害者的浏览器发出的并且携带了合法的身份信息服务器很难区分这到底是用户的本意还是攻击者的“借刀杀人”。理解CSRF对于任何从事Web开发、测试或安全运维的朋友都至关重要。它位列OWASP Top 10多年是Web安全中最经典、也最容易被忽视的漏洞之一。说它经典是因为其原理简单直接说它容易被忽视是因为在前后端分离、API泛滥的今天很多开发者误以为用了Token就万事大吉实则不然。本文将带你从攻击者的视角彻底拆解CSRF的原理再从防御者的角度构建一套从原理到实战的立体化防御体系。无论你是刚入门的安全新手还是希望加固自己系统的开发者这篇文章都将提供可直接“抄作业”的解决方案和避坑指南。2. CSRF攻击原理深度拆解信任是如何被滥用的要防御CSRF我们必须先成为“攻击者”理解其每一个环节是如何运作的。CSRF攻击的成功依赖于Web浏览器一个默认的、且至关重要的机制同源策略对Cookie发送的豁免以及用户身份验证的“状态保持”方式。2.1 核心攻击流程与三要素一次完整的CSRF攻击通常包含三个不可或缺的要素我们可以将其类比为一次“完美的冒名顶替”。受害者已登录并持有凭证这是攻击的前提。受害者必须在目标网站例如bank.com处于登录状态浏览器中保存了有效的会话Cookie。这个Cookie就是受害者的“身份证”。攻击者构造恶意请求攻击者分析目标网站的关键业务接口如修改邮箱的POST /change_email转账的POST /transfer。然后他精心制作一个网页这个网页中包含了一个会自动或诱导用户触发的请求指向目标接口并且参数齐全例如to_accountattackeramount10000。诱导受害者触发请求攻击者通过社交工程学手段如发送一封包含恶意链接的钓鱼邮件或在论坛中嵌入一张伪装成图片的请求诱使已登录的受害者访问这个恶意页面。受害者一旦访问其浏览器就会自动向bank.com发出那个携带了其本人Cookie的转账请求。这个过程的核心矛盾在于服务器无法区分一个携带了合法Session Cookie的请求到底是来自用户本人在其网站上的真实操作还是来自另一个网站恶意站点的伪造请求。因为浏览器在发起跨站请求时默认会带上目标站点的Cookie这是维持会话状态的基石但也成了CSRF的温床。2.2 攻击载荷的多种形式攻击者构造恶意请求的手法非常灵活主要分为以下几种自动提交的HTML表单这是最经典的方式。在恶意页面中嵌入一个隐藏的form通过JavaScript在页面加载时自动submit()。body onloaddocument.forms[0].submit() form actionhttps://bank.com/transfer methodPOST input typehidden nameto_account valueATTACKER_ACCOUNT / input typehidden nameamount value10000 / /form /body注意这种方式对POST请求非常有效因为表单可以携带请求体。IMG/Script等标签的SRC属性对于GET请求攻击可以更加隐蔽。例如在论坛帖子中插入一张“图片”img srchttps://bank.com/delete_account?confirm1 width0 height0 /当浏览器加载这个“图片”时就会自动向bank.com发起一个GET请求删除当前登录用户的账户。这种方式完全不需要用户交互。AJAX请求的局限性很多初学者会问能用AJAXFetch/XMLHttpRequest发起CSRF吗答案是在现代浏览器默认的CORS策略下简单的AJAX跨域请求无法成功携带Cookie发起非简单请求如带自定义头的POST。浏览器会先发一个OPTIONS预检请求如果服务器没有明确返回允许此源和凭证Access-Control-Allow-Origin和Access-Control-Allow-Credentials真正的请求就不会发出。这实际上使得“纯AJAX CSRF”变得困难。但攻击者完全可以使用上述form或img等不受CORS预检限制的古老方式。因此绝不能因为用了AJAX就放松对CSRF的警惕。2.3 与XSS的本质区别这里必须厘清一个关键概念CSRF不等于XSS。它们经常被一同提及但攻击模式截然不同。XSS跨站脚本核心是“脚本注入”。攻击者将恶意脚本注入到目标网站本身当其他用户访问被篡改的目标网站时脚本在其浏览器的目标站源下执行可以窃取该用户的Cookie从而发起更复杂的攻击、操作DOM、发起请求等。XSS利用了用户对目标网站的信任。CSRF跨站请求伪造核心是“请求伪造”。攻击者自己有一个独立的恶意网站利用用户浏览器对目标网站的自动身份验证机制伪造一个来自用户的请求。它利用了网站对用户浏览器的信任信任其发送的Cookie。一个简单的记忆方法是XSS是“在真网站里干坏事”CSRF是“从假网站向真网站发真请求”。当然两者可以结合例如通过XSS窃取的Token来绕过CSRF防御但这属于组合攻击。3. 实战防御体系构建从基础到纵深理解了攻击原理防御思路就清晰了我们要让服务器有能力区分“来自本网站的合法请求”和“来自其他网站的伪造请求”。下面我将从易到难构建一个四层的立体防御体系。3.1 第一层同步令牌Synchronizer Token Pattern这是最经典、最有效的防御方案适用于有服务端渲染能力的传统Web应用或部分前后端混合应用。原理服务器在为用户生成会话的同时生成一个随机、不可预测的令牌CSRF Token将其存放在用户的Session中。同时在需要保护的表单页面或页面模板中将这个Token作为一个隐藏字段input typehidden namecsrf_token value...输出。当用户提交表单时这个Token会随着表单数据一同提交到服务器。服务器接收到请求后比对请求体中的Token和Session中存储的Token是否一致。只有一致才认为是合法请求。实操要点与避坑指南Token的生成与存储生成必须使用密码学安全的随机数生成器CSPRNG如Java的java.security.SecureRandomPython的os.urandom或secrets.token_urlsafe。长度建议32字节以上。存储Token必须与用户会话Session绑定。每个会话应使用独立的Token。Token的传递与校验传递对于GET请求通常用于展示表单Token可以放在页面的Meta标签或JavaScript变量中供前端脚本读取并在后续POST时附加。对于POST/PUT/DELETE等修改数据的请求Token必须放在请求体Form Data或JSON中绝不能放在URL查询参数里因为URL可能被记录在浏览器历史、服务器日志中导致泄露。校验服务器端校验必须严格。不仅要比对Token是否存在、是否匹配还要在验证后使当前Session中的Token失效即每次验证后更新Token防止Token被重放攻击。对于重要的操作如转账、改密甚至可以要求每次请求都使用新Token。常见问题Q前后端分离如React/Vue REST API怎么用A这是一个大坑。传统同步Token模式依赖服务端渲染表单。在纯前后端分离中前端首次加载时需要通过一个安全的、非幂等的端点例如GET /api/csrf-token来获取Token。这个端点必须检查会话并返回一个Token可以放在JSON响应体或自定义HTTP头如X-CSRF-Token中。前端获取后需要将其存储例如在内存或非HttpOnly的Cookie中并在后续所有非安全方法POST,PUT,DELETE等的请求中携带通常放在请求头X-CSRF-Token里。关键点这个获取Token的端点本身可能成为CSRF的目标如果它返回的Token被攻击者页面获取因此需要仔细设计或结合其他校验如验证Referer。Q多标签页操作会导致Token失效吗A如果每个标签页共享同一个Session并且Token在验证后立即刷新那么在一个标签页提交后另一个标签页的旧Token就会失效导致提交失败。更好的做法是采用“每会话一个主Token每表单一个派生Token”的策略或者允许Token在短时间窗口内重复使用需权衡安全性与体验。3.2 第二层双重Cookie验证这是一种利用浏览器同源策略的“巧劲”在纯API接口、单页应用SPA中实现相对简单的方案。原理用户登录后服务器在响应中设置一个Cookie例如csrf_tokenabc123但这个Cookie的HttpOnly属性为false使得前端JavaScript可以读取document.cookie。同时前端在发起任何非安全请求如POST时需要从Cookie中读取这个Token值并将其附加到请求的Header中例如X-CSRF-Token: abc123。服务器收到请求后比对Header中的Token值和Cookie中携带的Token值是否一致。为什么能防御CSRF攻击者可以在其恶意站点上伪造请求浏览器也会自动带上目标站点的Cookie这是CSRF攻击的基础。但是浏览器同源策略禁止了恶意站点的JavaScript读取目标站点的Cookie内容。因此攻击者无法知道csrf_token这个Cookie的具体值是什么也就无法将其正确地放入请求Header中。服务器比对时发现Header中缺失或值不匹配就会拒绝请求。实操心得与巨坑预警警告此方案有严格的前提条件盲目使用等于裸奔。必须确保无XSS漏洞这是生命线因为该方案允许JS读取Cookie。如果网站存在XSS漏洞攻击者脚本可以轻松读取到csrf_tokenCookie的值从而完美构造出带有正确Header的伪造请求使CSRF防御彻底失效。因此在采用此方案前必须对XSS的防御有绝对信心包括对输入输出进行严格的过滤和转义设置内容安全策略CSP等。Cookie的作用域设置应将CSRF Token的Cookie的Path和Domain设置得尽可能严格通常与主会话Cookie一致避免不必要的暴露。子域名间的风险如果主站是www.example.com而API服务在api.example.com那么设置在.example.com域上的Cookie对于www和api子域都是可见且可被JS读取的。这本身不是问题但如果www子域存在XSS可能会泄露给api子域用的Token。需要仔细规划安全边界。个人建议对于内部系统、可控环境且对XSS防御有充分信心的SPA项目双重Cookie验证是一个轻量级的选择。对于面向公众、业务复杂的大型应用更推荐下面将介绍的SameSiteCookie属性。3.3 第三层利用现代浏览器特性 - SameSite Cookie这是目前最简单、最有效的防御措施之一几乎可以阻断绝大多数传统的CSRF攻击因为它直接从源头——Cookie的发送策略上做了限制。原理SameSite是Set-Cookie响应头的一个属性用于控制Cookie在跨站请求时是否被发送。它有三个值Strict最严格。浏览器只会在同一站点的请求中发送Cookie。即请求的源协议域名端口必须与设置Cookie的源完全一致。这意味着如果用户从邮件链接点击进入你的网站在首次请求时不会携带SameSiteStrict的Cookie可能导致“未登录”状态。Lax默认值现代浏览器的默认行为在大多数跨站子请求如图片、iframe中不发送Cookie但在顶级导航如点击链接且是安全方法GET的请求中会发送。这平衡了安全性和用户体验。例如从谷歌搜索结果点击进入网站登录态Cookie会被携带。NoneCookie在所有上下文中都会发送即禁用SameSite限制。必须同时设置Secure属性即仅通过HTTPS传输。如何防御CSRF将你的会话标识Cookie如SESSIONID设置为SameSiteLax或Strict。当攻击者从evil.com发起一个指向bank.com的POST表单提交时由于这是一个跨站且非顶级导航的请求浏览器将不会自动携带SameSiteLax的Cookie导致请求失去身份认证攻击失败。配置示例与注意事项Set-Cookie: SESSIONIDabc123; Path/; HttpOnly; Secure; SameSiteLaxHttpOnly和Secure依然是黄金搭档即使设置了SameSite也务必保持HttpOnly防XSS窃取和Secure仅HTTPS传输。对GET请求的影响SameSiteLax允许顶级导航的GET请求携带Cookie。这意味着如果你的关键操作如删除文章GET /delete/1是通过GET方法实现的它依然可能受到CSRF攻击。因此严格遵守RESTful规范永不使用GET方法进行数据修改是配合SameSite发挥最大效用的关键。兼容性所有现代浏览器都已支持SameSite。对于不支持的老旧浏览器该属性会被忽略Cookie会像以前一样被发送。因此SameSite应作为一道重要的增强防线而非唯一的防线需要与其他措施如CSRF Token结合形成纵深防御。3.4 第四层请求头校验与业务逻辑补充这一层是前面几层的补充和加固在特定场景下非常有效。检查Origin/Referer HeaderHTTP请求头中的Origin用于POST、CORS请求和Referer表示请求来源页面可以用来判断请求是否来自本站。服务器可以校验这些头部的值是否以白名单内的可信域名开头。优点实现简单。缺点Referer头可能被用户浏览器隐私设置禁用或篡改不可完全依赖。在HTTPS-HTTP的降级请求中浏览器不会发送Referer。判断逻辑需要小心处理避免因字符串匹配不严谨导致绕过。建议可作为辅助校验手段或用于防御一些简单的自动化扫描工具。关键操作增加二次确认对于转账、修改密码、删除账户等敏感操作强制要求用户在操作前再次输入密码或支付密码、短信验证码。这从业务逻辑上增加了攻击门槛。注意这个二次确认的接口本身也需要受到CSRF保护否则攻击者可以伪造一个包含正确密码的二次确认请求。使用自定义请求头让前端在所有非简单请求如POST、PUT中添加一个自定义的HTTP头例如X-Requested-With: XMLHttpRequest。服务器检查请求中是否存在该头。原理浏览器在发起跨域请求时对于非简单请求会先发OPTIONS预检请求。而通过form或img发起的传统CSRF攻击无法添加自定义头因此会被服务器拒绝。局限性这只对非简单请求有效。且如果网站本身支持CORS并配置了允许该自定义头攻击者理论上可以通过构造一个通过预检的AJAX请求来绕过尽管难度很大。通常结合其他方法使用。4. 不同技术栈下的实战配置示例理论需要落地。下面我以几个常见的技术栈为例展示如何具体实现CSRF Token防御。4.1 Spring Security (Java) 配置Spring Security提供了开箱即用的CSRF防护默认是开启的。Configuration EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http .csrf() // 启用CSRF防护默认使用HttpSessionCsrfTokenRepository .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()) // 关键使用Cookie方案允许JS读取 .and() .authorizeRequests() .anyRequest().authenticated() .and() .formLogin(); } }说明默认配置下Spring Security会为每个会话生成一个_csrfToken存储在Session中并在请求属性中暴露供Thymeleaf等模板引擎自动插入表单input typehidden name_csrf th:value${_csrf.token}/。上例中使用了CookieCsrfTokenRepository.withHttpOnlyFalse()这是为了适配前后端分离。它将Token放在名为XSRF-TOKEN的Cookie中HttpOnly为false前端需要读取这个Cookie并在每次请求的X-XSRF-TOKENHeader中带上它。对于纯API后端如果前端是移动App或桌面客户端它们不依赖浏览器Cookie可能需要禁用CSRFhttp.csrf().disable()但必须使用其他方式认证如OAuth2 Token、JWT并注意JWT本身不防CSRF需要妥善存储。4.2 Express.js csurf (Node.js) 中间件在Express中常用csurf中间件。const express require(express); const cookieParser require(cookie-parser); const csrf require(csurf); const bodyParser require(body-parser); const app express(); // 必须放在csurf之前 app.use(cookieParser()); app.use(bodyParser.urlencoded({ extended: false })); // 设置CSRF保护 const csrfProtection csrf({ cookie: true }); // 使用Cookie存储Token // 将Token暴露给视图 app.get(/form, csrfProtection, (req, res) { // 在模板中可以通过 req.csrfToken() 获取Token res.render(send, { csrfToken: req.csrfToken() }); }); // 保护POST端点 app.post(/process, csrfProtection, (req, res) { // 如果Token验证失败csurf会抛出错误可以通过错误处理中间件捕获 res.send(数据已处理); }); // 错误处理 app.use((err, req, res, next) { if (err.code ! EBADCSRFTOKEN) return next(err); // CSRF Token错误处理 res.status(403).send(表单已过期请刷新重试。); });注意事项cookie: true选项让csurf将Token存储在Cookie而非Session中更适合无状态或分布式场景。同样需要确保前端能访问并回传Token。对于API需要配置前端在请求头如X-CSRF-Token中传递Token并在服务端相应配置csurf从header读取。4.3 Django (Python) 内置防护Django的CSRF中间件默认是启用的为所有POST、PUT、DELETE等非安全方法提供保护。模板中插入Tokenform methodpost {% csrf_token %} !-- 这行会渲染成一个隐藏的input -- !-- 其他表单字段 -- input typesubmit value提交 /formAJAX请求处理 Django会将CSRF Token设置在一个名为csrftoken的Cookie中。你需要编写JavaScript代码来读取它并在AJAX请求中附加。// 使用jQuery示例 function getCookie(name) { let cookieValue null; if (document.cookie document.cookie ! ) { const cookies document.cookie.split(;); for (let i 0; i cookies.length; i) { const cookie cookies[i].trim(); if (cookie.substring(0, name.length 1) (name )) { cookieValue decodeURIComponent(cookie.substring(name.length 1)); break; } } } return cookieValue; } const csrftoken getCookie(csrftoken); $.ajax({ url: /api/endpoint/, type: POST, data: {...}, beforeSend: function(xhr) { xhr.setRequestHeader(X-CSRFToken, csrftoken); // 关键设置请求头 }, success: function(result) {...} });为特定视图豁免CSRF谨慎使用from django.views.decorators.csrf import csrf_exempt csrf_exempt def my_api_view(request): # 这个视图将不受CSRF保护 ...5. 高级场景、疑难杂症与渗透测试视角即使部署了防御也可能存在盲点。下面从攻击者和防御者双重角度分析一些高级场景。5.1 组合攻击与边缘案例XSS CSRF如果网站存在存储型XSS攻击者可以注入脚本该脚本运行在受害者的浏览器上下文下可以轻松读取到页面中的CSRF Token如果Token直接输出在DOM中或HttpOnly为false的Cookie从而构造出完美的伪造请求。防御的根本在于彻底杜绝XSS。JSON API与Content-Type绕过有些开发者认为只接受Content-Type: application/json的API端点不会受到CSRF攻击因为form提交的默认Content-Type是application/x-www-form-urlencoded。这是一个危险的误解攻击者可以使用JavaScript构造一个fetch或XMLHttpRequest来发送JSON数据并且通过form的enctypetext/plain也能发送类似JSON的文本。关键在于攻击者能否控制请求体。因此不能依赖Content-Type作为防御手段必须在请求体或头中校验Token。子域名接管与Cookie作用域如果主站设置为Domain.example.com那么所有子域名如attacker.example.com都能接收到这个Cookie。如果attacker这个子域名因过期未续费而被攻击者注册接管他就能在该子域下设置页面发起对主站的CSRF攻击。因此Cookie的Domain属性应尽可能设置精确。5.2 渗透测试中的CSRF漏洞挖掘作为一名安全测试人员如何寻找CSRF漏洞目标识别使用Burp Suite等工具爬取目标应用的所有功能点重点关注所有状态更改操作更新资料、修改密码、转账、添加用户、发布内容、注销等。请求分析拦截这些操作的HTTP请求观察是否使用了POST、PUT、DELETE等方法GET方法的直接报告请求中是否存在CSRF Token参数名称可能为csrf_token,_token,authenticity_token等是否存在自定义Header如X-Requested-With,X-CSRF-Token检查Cookie的SameSite属性。漏洞验证无Token/Header如果请求中没有任何CSRF防护凭证直接尝试使用Burp的“Generate CSRF PoC”功能生成一个HTML页面在已登录目标站点的浏览器中打开看操作是否成功。Token可预测/重复使用如果存在Token尝试使用同一个Token发起两次相同请求看是否都成功重放漏洞。分析Token的生成规律如时间戳、用户ID哈希等尝试预测其他用户的Token。检查Token是否与用户会话严格绑定尝试将用户A的Token用于用户B的会话。防护绕过尝试检查Origin/Referer尝试在请求中删除、修改或伪造Origin/Referer头看服务器是否校验。JSON端点尝试将Content-Type改为application/json但数据格式仍用表单格式或尝试用form的text/plain类型提交。同源策略绕过如果网站存在CORS配置错误如Access-Control-Allow-Origin: *且允许凭证攻击者可能通过AJAX直接读取数据或发起请求但这通常归类为CORS漏洞。5.3 我的防御配置清单在实际项目中我通常会采用一种组合拳策略以下是我的个人检查清单基础强制项所有项目[ ]设置会话Cookie为SameSiteLax(或Strict)。这是现代Web应用的第一道、也是最重要的防线。[ ]永远不使用GET方法执行任何会产生副作用的操作。这是HTTP语义和安全的双重要求。[ ]对所有的状态修改端点POST,PUT,PATCH,DELETE实施CSRF防护。传统Web应用服务端渲染[ ] 启用框架内置的CSRF保护如Spring Security, Django Middleware。[ ] 确保所有表单都正确插入了CSRF Token。[ ] 配置Token在验证后刷新防重放。前后端分离应用SPA API[ ] 方案A推荐采用“同步Token模式”的变体。提供安全的Token获取端点前端存储Token并在请求头中发送。API端校验头中的Token与Session中的是否匹配。[ ] 方案B谨慎采用“双重Cookie验证”。必须与严格的CORS策略和强化的XSS防御如CSP结合使用。[ ]无论哪种方案都必须设置SameSiteLaxCookie。纯API服务无浏览器客户端[ ] 可以考虑禁用CSRF防护http.csrf().disable()。[ ] 使用基于Token的认证如JWT、OAuth2 Access Token并确保Token不通过Cookie自动发送即不要用Cookie存Token而是由客户端显式地在Authorization头中携带。[ ]注意如果Token存储在localStorage或sessionStorage中需防范XSS如果存储在HttpOnlyCookie中则又回到了需要防CSRF的场景。这是一个安全权衡。持续监控与测试[ ] 将CSRF漏洞扫描纳入CI/CD流水线或定期安全测试。[ ] 使用自动化工具如OWASP ZAP和手动测试验证关键业务流。[ ] 关注依赖库如Spring Security,csurf的安全更新这些库的CSRF实现历史上也曾出现过漏洞。CSRF的防御不是一劳永逸的它需要开发者对Web安全基础有深刻的理解并根据应用架构做出恰当的选择。从设置SameSiteCookie这个简单的动作开始到为复杂SPA设计Token交换机制每一步都是在构建更稳固的安全边界。记住安全是一个过程而非一个状态。保持警惕持续学习才能让我们的应用在充满挑战的网络环境中屹立不倒。