1. 项目概述为什么CSRF防护是Web安全的必修课如果你正在用Spring Security构建Web应用那么CSRF跨站请求伪造这个词你一定不陌生。它就像一个潜伏在暗处的“模仿者”攻击者可以诱导你的用户在不知情的情况下以他们的身份执行非预期的操作比如修改密码、转账、发表评论。听起来是不是有点后背发凉我见过太多项目安全配置看似齐全却在CSRF防护上栽了跟头要么是防护过度导致正常功能异常要么是防护缺失形同虚设。今天我们就抛开那些枯燥的理论文档直接进入实战。我会带你从攻击者的视角亲手复现一个CSRF漏洞然后再切换到防御者的角色用Spring Security一步步构建起坚固的防线。这不仅仅是配置几个参数更重要的是理解背后的“攻防博弈”逻辑让你在未来的开发中能清晰地判断何时该严防死守何时又该灵活放行。无论你是刚接触Spring Security的新手还是想深化安全理解的老兵这篇从原理到最佳实践的深度剖析都能让你对CSRF有一个全新的、立体的认识。2. CSRF攻击原理深度拆解攻击者是如何“借刀杀人”的在开始配置任何防护之前我们必须彻底搞清楚敌人是如何进攻的。很多开发者对CSRF的理解停留在“需要带Token”的层面这远远不够。只有洞悉攻击链的每一个环节你才能设计出真正有效的防御。2.1 CSRF攻击的核心逻辑与必要条件CSRF攻击能够成功依赖于几个关键的前提条件我们可以把它想象成一次“完美的身份冒用”用户已登录并保持会话这是攻击的基石。用户必须在目标网站例如bank.com完成了登录浏览器中保存了有效的会话Cookie如JSESSIONID。这个Cookie就是用户的“身份证”。目标站点存在可预测或未受保护的操作端点攻击者需要知道一个能执行敏感操作的URL比如POST /bank/transfer并且这个端点没有足够的CSRF防护措施。用户被诱骗访问恶意页面攻击者通过社交工程如发送一封伪装成优惠信息的邮件、评论中嵌入图片链接、或者被攻破的第三方网站让用户的浏览器去加载一个恶意构造的页面。攻击的本质在于浏览器在发起跨站请求时会自动携带该目标域名下的Cookie这是HTTP协议的同源策略Same-Origin Policy中的一个关键行为。同源策略限制了不同源之间的脚本互访但它并不阻止跨源请求的发送和接收响应。攻击者正是利用了“请求自动携带Cookie”这一机制实现了身份伪造。注意这里一定要区分“同源策略”和“CSRF防护”。同源策略是浏览器的一个安全基石它阻止了恶意网站读取另一个网站的DOM或Cookie。但CSRF攻击并不需要读取响应内容它只需要请求能被成功发送并执行。因此同源策略无法防御CSRF。2.2 一次完整的CSRF攻击实战模拟让我们用一个经典的银行转账场景来还原攻击过程。假设我们有一个简陋的银行应用它提供一个表单用于转账!-- bank.com 上的合法转账表单 -- form actionhttps://bank.com/transfer methodPOST input typehidden nametoAccount valuealice/ input typehidden nameamount value1000/ input typesubmit value转账给Alice/ /form这个表单没有任何CSRF Token。现在攻击者构造了一个恶意网站evil.com其页面内容如下!-- evil.com 上的恶意页面 -- body onloaddocument.forms[0].submit() form actionhttps://bank.com/transfer methodPOST input typehidden nametoAccount valueattacker/ input typehidden nameamount value10000/ /form h1恭喜你中奖了/h1 /body攻击流程拆解用户登录了bank.com会话Cookie有效。用户收到了攻击者发来的链接点击后访问了evil.com。浏览器加载evil.com的页面页面中的JavaScriptonload事件自动提交了隐藏的表单。浏览器向bank.com/transfer发起一个POST请求。关键点来了由于这是向bank.com发起的请求浏览器会自动附带上bank.com域名下的所有Cookie包括那个代表用户身份的JSESSIONID。bank.com的后端服务器收到请求检查Cookie中的JSESSIONID发现是有效的已登录会话于是认为这是用户本人发起的合法转账请求便执行了向“attacker”账户转账10000元的操作。攻击完成用户资金受损而用户本人可能完全不知情只看到一个“恭喜中奖”的页面。这个例子清晰地展示了攻击者完全不需要窃取你的密码或Cookie他只需要“借用”你浏览器里已有的身份凭证。这就是“跨站请求伪造”这个名字的由来——请求是从evil.com这个“跨站”伪造并发送到bank.com的。2.3 绕过常见“伪防护”的进阶攻击手法很多初级防护措施很容易被绕过了解这些有助于我们设计更健壮的防御。依赖Referer检查有些应用会检查HTTP请求头中的Referer字段判断请求来源是否是自己信任的域名。然而Referer可能被禁用部分用户或浏览器插件出于隐私考虑会禁止发送Referer。HTTPS到HTTP的Referer缺失从HTTPS页面链接到HTTP页面浏览器可能不发送Referer。攻击者可以构造请求通过一些技术手段如利用Flash、某些浏览器的漏洞或通过302跳转攻击者有可能部分控制或篡改Referer或者使其为空从而绕过检查。因此将Referer检查作为唯一防护手段是不可靠的。仅防护POST请求CSRF攻击并非只能通过表单POST发起。GET请求同样危险尤其是当应用使用GET方法来执行状态变更操作时这是一个糟糕的设计但现实中存在。攻击者只需在恶意页面嵌入一个图片标签img srchttps://bank.com/delete?id123用户加载页面时浏览器就会自动发起一个携带Cookie的GET请求。因此防护必须覆盖所有可能改变状态的HTTP方法POST PUT PATCH DELETE等。理解了攻击者的这些“套路”我们就能更有针对性地构建防御。接下来我们就看看Spring Security为我们提供了哪些“武器”。3. Spring Security CSRF防护机制全解析Spring Security的CSRF防护并非一个黑盒魔法它是一套基于“同步器令牌模式”Synchronizer Token Pattern的、可高度定制的安全框架。知其然更要知其所以然。3.1 默认防护的底层工作原理当你引入Spring Security依赖且未做任何CSRF配置时它默认是启用CSRF防护的。它的工作流程是一个经典的“挑战-响应”模型令牌生成与关联当服务器向客户端发送一个需要被防护的页面通常是包含表单的HTML时CsrfFilter会生成一个唯一的、不可预测的令牌Token。这个令牌会被做两件事放入当前HTTP会话Session中。作为一个属性默认为_csrf添加到HttpServletRequest中供视图层如Thymeleaf, JSP渲染到页面里通常是一个隐藏的表单字段input typehidden name_csrf value生成的令牌值/。令牌的提交与验证当客户端提交表单或发起其他受保护的请求时必须将这个令牌一并提交回来。提交方式有两种请求参数作为表单字段_csrf的值。请求头作为X-CSRF-TOKEN或X-XSRF-TOKEN头的值。 服务器端的CsrfFilter会拦截请求从请求中提取令牌并与当前会话中存储的令牌进行比较。验证决策匹配成功请求被认为是合法的放行。匹配失败或缺失请求被认为是潜在的CSRF攻击Spring Security会抛出AccessDeniedException通常会导致一个403Forbidden错误响应。这个机制之所以有效是因为攻击者无法预先知道或读取到当前用户会话中的那个唯一令牌。他构造的恶意请求中无法包含正确的令牌因此会被服务器拒绝。3.2 关键配置类与自定义扩展点Spring Security的CSRF配置主要通过HttpSecurity对象的csrf()方法进行。理解其背后的核心组件能让你在需要定制时得心应手。CsrfFilter这是防护的核心过滤器。它负责令牌的生成、存储、验证以及请求的拦截判断。我们很少直接操作它但它是所有行为的执行者。CsrfTokenRepository令牌仓库接口定义了令牌的加载、生成、保存行为。这是最常用的扩展点。HttpSessionCsrfTokenRepository默认实现。将令牌存储在HttpSession中。简单可靠适用于传统服务端渲染应用。CookieCsrfTokenRepository将令牌存储在Cookie中。这是一种适用于前后端分离架构如React, Vue, Angular的“双Cookie”或“Cookie-to-Header”模式。它通常将令牌写入一个Cookie如XSRF-TOKEN前端JavaScript需要读取这个Cookie的值并在后续请求中将其作为某个HTTP头如X-XSRF-TOKEN发送回来。这种方式避免了会话依赖更适配无状态API。LazyCsrfTokenRepository一个包装器可以延迟令牌的生成直到真正需要时如第一次渲染表单时有助于优化性能。CsrfTokenRequestHandler决定如何处理令牌的请求处理程序。例如XorCsrfTokenRequestAttributeHandler是默认处理器它支持将令牌进行XOR混淆后再输出到页面以应对一些特定的渗透测试扫描器。在Spring Security 6.x及更高版本中这个组件的角色变得更加重要。RequestMatcher用于定义哪些请求需要CSRF防护哪些不需要。这是配置防护范围的关键。3.3 防护范围的精确控制RequestMatcher策略并非所有请求都需要CSRF防护。对防护范围的精确控制既能保证安全又能避免对正常功能如API调用造成干扰。Spring Security允许我们通过RequestMatcher来定义这个范围。默认情况下CSRF防护会忽略以下请求GET,HEAD,TRACE,OPTIONS这些被认为是“安全”的、不改变资源状态的方法。匹配特定路径的请求在旧版本中如/logout的POST请求默认也被忽略但在新版本中需要显式配置。常见的自定义防护策略示例Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf(csrf - csrf // 1. 完全禁用CSRF防护极度不推荐用于Web应用 // .disable() // 2. 忽略特定API路径常用于纯后端API供移动端或第三方调用 .ignoringRequestMatchers(/api/public/**, /webhook/**) // 3. 使用自定义的RequestMatcher进行更复杂的匹配逻辑 .requireCsrfProtectionMatcher(new CustomCsrfRequestMatcher()) ) .authorizeHttpRequests(auth - auth .anyRequest().authenticated() ) .formLogin(withDefaults()); return http.build(); } // 自定义匹配器示例只对特定路径且非GET方法进行防护 static class CustomCsrfRequestMatcher implements RequestMatcher { private final AntPathRequestMatcher[] ignoredMatchers { new AntPathRequestMatcher(/api/**, HttpMethod.GET.name()), new AntPathRequestMatcher(/static/**), new AntPathRequestMatcher(/h2-console/**) // 忽略H2数据库控制台 }; Override public boolean matches(HttpServletRequest request) { // 如果请求匹配忽略列表则不需要CSRF防护 for (AntPathRequestMatcher matcher : ignoredMatchers) { if (matcher.matches(request)) { return false; } } // 默认情况下对所有非“安全”方法POST, PUT, PATCH, DELETE进行防护 return !List.of(GET, HEAD, TRACE, OPTIONS) .contains(request.getMethod()); } } }实操心得在定义忽略规则时务必谨慎。一个常见的错误是忽略了所有/api/**路径。如果你的API也通过浏览器调用例如前端是单页应用SPA那么这些API同样需要CSRF防护。只有当你的API是纯粹给非浏览器客户端如手机App、桌面客户端、其他服务调用时才考虑忽略其CSRF检查并转而使用其他认证方式如OAuth2、JWT。4. 前后端协作下的CSRF防护最佳实践理论讲完了现在进入最关键的实战环节。不同的技术架构CSRF防护的集成方式也不同。我将其分为两大类传统多页应用MPA和现代前后端分离应用SPA。4.1 场景一传统服务端渲染应用如Thymeleaf, JSP这是Spring Security默认防护模式最适配的场景。流程非常自动化。1. 确保表单包含CSRF令牌如果你使用Thymeleaf模板引擎并且表单在Spring Security的保护下Thymeleaf会自动为你添加CSRF令牌的隐藏字段只要你的表单使用th:action属性。!-- Thymeleaf 自动处理 -- form methodpost th:action{/transfer} !-- Thymeleaf会自动在此处插入 input typehidden name_csrf th:value${_csrf.token}/ -- input typetext nametoAccount/ input typenumber nameamount/ button typesubmit转账/button /form如果你使用JSP或者需要手动处理可以像这样获取令牌!-- JSP 手动处理 -- form action/transfer methodpost input typehidden name${_csrf.parameterName} value${_csrf.token}/ !-- 其他表单字段 -- /form2. 处理AJAX请求在现代Web应用中即使是非SPA也大量使用AJAX。你需要手动将CSRF令牌添加到AJAX请求的头部。首先在页面中获取令牌通常可以放在一个meta标签里meta name_csrf th:content${_csrf.token}/ meta name_csrf_header th:content${_csrf.headerName}/然后在全局的JavaScript中配置例如使用jQuery$(document).ajaxSend(function(event, xhr, options) { var token $(meta[name_csrf]).attr(content); var header $(meta[name_csrf_header]).attr(content); if (token header) { xhr.setRequestHeader(header, token); } });这样所有通过jQuery发起的AJAX请求都会自动带上CSRF令牌头。注意事项确保你的JavaScript代码在同一个页面上下文中运行能够访问到包含令牌的meta标签。如果页面是通过AJAX动态加载的需要重新获取或传递令牌。4.2 场景二前后端分离应用如React, Vue, Angular Spring Boot API这是目前更主流的架构。后端提供RESTful API前端是独立的单页应用。此时默认的Session存储令牌模式变得笨重因为API可能是无状态的。我们推荐使用CookieCsrfTokenRepository。后端配置Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf(csrf - csrf // 关键配置使用基于Cookie的CSRF令牌仓库 .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()) ) .authorizeHttpRequests(auth - auth .requestMatchers(/api/login).permitAll() .anyRequest().authenticated() ) // 使用基于JSON的登录而非表单登录 .formLogin(AbstractHttpConfigurer::disable) // 禁用默认表单登录 .httpBasic(AbstractHttpConfigurer::disable); // 禁用HTTP Basic return http.build(); } }CookieCsrfTokenRepository.withHttpOnlyFalse()解析它会创建一个名为XSRF-TOKEN的Cookie来存放CSRF令牌。withHttpOnlyFalse()意味着这个Cookie可以被客户端的JavaScript读取。这是必须的因为前端应用需要读取这个Cookie的值并将其作为请求头发送。服务器在验证时会同时检查请求头X-XSRF-TOKEN和Cookie中的令牌是否匹配。前端协作以Axios为例首次访问用户访问前端应用Spring Boot后端会在响应中设置XSRF-TOKENCookie。前端拦截器配置在前端HTTP客户端如Axios中配置一个请求拦截器从Cookie中读取XSRF-TOKEN的值并将其添加到后续所有“非安全”方法请求的头部。// 以Axios为例 import axios from axios; // 创建一个辅助函数来获取Cookie值 function getCookie(name) { const value ; ${document.cookie}; const parts value.split(; ${name}); if (parts.length 2) return parts.pop().split(;).shift(); } // 创建axios实例 const apiClient axios.create({ baseURL: /api, withCredentials: true, // 关键允许跨域请求携带Cookie }); // 请求拦截器为修改状态的请求添加CSRF Token头 apiClient.interceptors.request.use(config { const token getCookie(XSRF-TOKEN); const method config.method?.toUpperCase(); // 仅为非安全方法添加头 if (token method [POST, PUT, PATCH, DELETE].includes(method)) { config.headers[X-XSRF-TOKEN] token; } return config; }, error { return Promise.reject(error); }); export default apiClient;关键点说明withCredentials: true这是跨域请求时携带Cookie的必备设置。如果你的前端和后端部署在不同域名下后端也需要配置相应的CORS策略来允许凭证。安全方法判断我们只对可能改变状态的请求添加CSRF头这与Spring Security的默认忽略策略保持一致。Cookie安全虽然我们将XSRF-TOKENCookie设置为HttpOnlyfalse以便JS读取但这本身并不引入大的安全风险。因为这个Cookie只用于CSRF防护不包含会话身份信息。攻击者即使通过XSS漏洞获取了这个Cookie他也无法直接发起CSRF攻击因为CSRF攻击不依赖读取Cookie而是依赖自动携带。当然防范XSS永远是重要的。4.3 场景三混合应用与特殊端点处理有些应用是混合形态既有服务端渲染页面也提供API。或者有一些特殊的端点需要特别处理。/logout端点在Spring Security的默认表单登录中注销是通过POST请求到/logout完成的。这个请求也需要CSRF令牌。如果你使用Thymeleaf可以这样写form th:action{/logout} methodpost input typehidden th:name${_csrf.parameterName} th:value${_csrf.token}/ button typesubmit退出登录/button /form如果你希望简化可以配置一个GET方式的注销安全性稍低需权衡.logout(logout - logout .logoutRequestMatcher(new AntPathRequestMatcher(/logout, GET)) )文件上传如果表单包含文件上传enctypemultipart/form-dataCSRF令牌必须作为表单字段_csrf传递而不能放在URL参数中。因为multipart/form-data请求的头部处理方式特殊。确保你的前端表单正确包含了隐藏的CSRF字段。API Gateway/代理后的应用如果你的应用运行在反向代理如Nginx或API网关之后需要注意X-Forwarded-*头可能会影响请求的源判断。确保你的CSRF配置或底层的HttpServletRequest能正确识别客户端的真实IP和协议这通常与服务器和代理的配置有关而非Spring Security本身。5. 高级防护策略、问题排查与安全加固掌握了基础配置后我们来看看如何应对更复杂的情况以及当出现问题时如何快速定位。5.1 自定义令牌生成与验证逻辑绝大多数情况下默认实现已足够安全。但在极高安全要求的场景下你可能需要定制。自定义CsrfTokenRepository你可以实现自己的令牌仓库例如将令牌存储在分布式缓存如Redis中以适应集群部署环境确保所有节点都能验证同一个令牌。Bean public CsrfTokenRepository customTokenRepository() { return new CsrfTokenRepository() { Override public CsrfToken generateToken(HttpServletRequest request) { // 生成一个更复杂或带有业务标识的令牌 return new DefaultCsrfToken(X-CSRF-TOKEN, _csrf, UUID.randomUUID().toString() : System.currentTimeMillis()); } Override public void saveToken(CsrfToken token, HttpServletRequest request, HttpServletResponse response) { // 将令牌存入Rediskey可以为 sessionId “_csrf” if (token ! null) { String key request.getSession().getId() _csrf; redisTemplate.opsForValue().set(key, token.getToken(), 30, TimeUnit.MINUTES); } else { // 删除令牌 } // 同时仍然可以写入Cookie供前端使用 Cookie cookie new Cookie(XSRF-TOKEN, token ! null ? token.getToken() : ); response.addCookie(cookie); } Override public CsrfToken loadToken(HttpServletRequest request) { // 从Redis加载令牌 String key request.getSession().getId() _csrf; String tokenValue redisTemplate.opsForValue().get(key); return (tokenValue ! null) ? new DefaultCsrfToken(X-CSRF-TOKEN, _csrf, tokenValue) : null; } }; }自定义CsrfTokenRequestHandler在Spring Security 6中你可以通过自定义处理器来改变令牌的获取和验证行为例如支持从多个地方头、参数、属性提取令牌。5.2 常见问题排查清单在集成CSRF防护时你可能会遇到以下问题。这里是一个快速排查指南问题现象可能原因排查步骤与解决方案403 Forbidden (Invalid CSRF Token)1. 表单/请求中未包含CSRF令牌。2. 令牌已过期Session失效。3. 前端发送的令牌与后端存储的不匹配。4. 请求被错误的RequestMatcher匹配导致需要防护的请求被放行或反之。1.检查请求使用浏览器开发者工具的“网络”选项卡查看失败的请求。确认请求体Form Data中是否有_csrf参数或请求头中是否有X-XSRF-TOKEN。2.检查Session确认用户会话是否仍然有效。长时间无操作可能导致Session过期。3.检查配置确认CsrfTokenRepository配置正确。前后端分离应用检查CookieCsrfTokenRepository和withCredentials。4.检查忽略规则确认csrf().ignoringRequestMatchers(...)没有错误地忽略了本应防护的路径。前端无法读取XSRF-TOKENCookie1. Cookie未成功设置。2. Cookie被设置为HttpOnlytrueJS无法读取。3. 跨域问题前端域名与后端设置的Cookie域名不匹配。1.检查响应头在登录或首次GET请求的响应中查看Set-Cookie头是否包含XSRF-TOKEN。2.检查配置确保使用了CookieCsrfTokenRepository.withHttpOnlyFalse()。3.检查CORS确保后端CORS配置允许前端源allowedOrigins并且允许凭证allowCredentials(true)。注销后再次登录CSRF失败注销操作通常会使Session失效从而清除了旧的CSRF令牌。但前端可能还缓存着旧的令牌或Cookie。1.前端清理在注销后前端应主动清理或重置存储的CSRF令牌。2.重新获取登录成功后前端应触发一次不需要CSRF防护的GET请求如获取用户信息以从响应中获取新的CSRF令牌Cookie。文件上传失败CSRF令牌作为URL参数传递而不是表单字段。强制使用表单字段确保文件上传表单中有一个隐藏的input typehidden name_csrf value.../字段。不能依赖JavaScript将令牌添加到请求头因为multipart/form-data格式特殊。5.3 安全加固与纵深防御CSRF防护是重要的一环但绝不能是唯一的一环。真正的安全来自于纵深防御。关键操作二次验证对于转账、修改密码、修改邮箱等极高风险操作强制要求用户进行二次验证例如输入登录密码、短信验证码、或使用TOTP动态令牌。这样即使CSRF防护被某种未知手段绕过攻击者也无法完成操作。严格遵循RESTful规范使用正确的HTTP方法。GET请求只用于获取资源绝不用于执行修改操作。这能从设计上减少CSRF攻击面。设置合适的Cookie属性Secure仅通过HTTPS传输Cookie防止在明文HTTP中被窃听。SameSiteStrict/Lax现代浏览器广泛支持。设置为Strict或Lax可以很大程度上阻止第三方网站发起的跨站请求携带Cookie从浏览器层面缓解CSRF。对于会话CookieSameSiteLax是一个很好的平衡选择。// 在Spring Boot配置中可以通过 application.properties 全局设置 server.servlet.session.cookie.same-sitelax server.servlet.session.cookie.securetrue防范XSS跨站脚本攻击XSS漏洞可以让攻击者在你网站的上下文中执行恶意脚本从而有可能窃取到CSRF令牌如果令牌存储在可被JS访问的地方如Cookie或DOM中。因此对用户输入进行严格的过滤和转义设置安全的CSP内容安全策略头是防止CSRF令牌被窃取的关键。定期安全审计与依赖更新定期使用OWASP ZAP、Burp Suite等工具对你的应用进行CSRF漏洞扫描。同时保持Spring Security及相关依赖库更新到最新版本以获取安全补丁。CSRF防护不是一项“配置即忘”的任务。它需要你根据应用架构、用户交互模式和安全等级进行持续的思考和调整。从理解攻击原理开始到合理配置防护策略再到建立纵深防御体系每一步都至关重要。希望这篇结合原理与实战的剖析能让你在构建安全可靠的Spring Boot应用时多一份从容和自信。记住安全是一个过程而非一个状态。
Spring Security CSRF防护实战：从攻击原理到前后端最佳实践
发布时间：2026/7/6 8:58:00
1. 项目概述为什么CSRF防护是Web安全的必修课如果你正在用Spring Security构建Web应用那么CSRF跨站请求伪造这个词你一定不陌生。它就像一个潜伏在暗处的“模仿者”攻击者可以诱导你的用户在不知情的情况下以他们的身份执行非预期的操作比如修改密码、转账、发表评论。听起来是不是有点后背发凉我见过太多项目安全配置看似齐全却在CSRF防护上栽了跟头要么是防护过度导致正常功能异常要么是防护缺失形同虚设。今天我们就抛开那些枯燥的理论文档直接进入实战。我会带你从攻击者的视角亲手复现一个CSRF漏洞然后再切换到防御者的角色用Spring Security一步步构建起坚固的防线。这不仅仅是配置几个参数更重要的是理解背后的“攻防博弈”逻辑让你在未来的开发中能清晰地判断何时该严防死守何时又该灵活放行。无论你是刚接触Spring Security的新手还是想深化安全理解的老兵这篇从原理到最佳实践的深度剖析都能让你对CSRF有一个全新的、立体的认识。2. CSRF攻击原理深度拆解攻击者是如何“借刀杀人”的在开始配置任何防护之前我们必须彻底搞清楚敌人是如何进攻的。很多开发者对CSRF的理解停留在“需要带Token”的层面这远远不够。只有洞悉攻击链的每一个环节你才能设计出真正有效的防御。2.1 CSRF攻击的核心逻辑与必要条件CSRF攻击能够成功依赖于几个关键的前提条件我们可以把它想象成一次“完美的身份冒用”用户已登录并保持会话这是攻击的基石。用户必须在目标网站例如bank.com完成了登录浏览器中保存了有效的会话Cookie如JSESSIONID。这个Cookie就是用户的“身份证”。目标站点存在可预测或未受保护的操作端点攻击者需要知道一个能执行敏感操作的URL比如POST /bank/transfer并且这个端点没有足够的CSRF防护措施。用户被诱骗访问恶意页面攻击者通过社交工程如发送一封伪装成优惠信息的邮件、评论中嵌入图片链接、或者被攻破的第三方网站让用户的浏览器去加载一个恶意构造的页面。攻击的本质在于浏览器在发起跨站请求时会自动携带该目标域名下的Cookie这是HTTP协议的同源策略Same-Origin Policy中的一个关键行为。同源策略限制了不同源之间的脚本互访但它并不阻止跨源请求的发送和接收响应。攻击者正是利用了“请求自动携带Cookie”这一机制实现了身份伪造。注意这里一定要区分“同源策略”和“CSRF防护”。同源策略是浏览器的一个安全基石它阻止了恶意网站读取另一个网站的DOM或Cookie。但CSRF攻击并不需要读取响应内容它只需要请求能被成功发送并执行。因此同源策略无法防御CSRF。2.2 一次完整的CSRF攻击实战模拟让我们用一个经典的银行转账场景来还原攻击过程。假设我们有一个简陋的银行应用它提供一个表单用于转账!-- bank.com 上的合法转账表单 -- form actionhttps://bank.com/transfer methodPOST input typehidden nametoAccount valuealice/ input typehidden nameamount value1000/ input typesubmit value转账给Alice/ /form这个表单没有任何CSRF Token。现在攻击者构造了一个恶意网站evil.com其页面内容如下!-- evil.com 上的恶意页面 -- body onloaddocument.forms[0].submit() form actionhttps://bank.com/transfer methodPOST input typehidden nametoAccount valueattacker/ input typehidden nameamount value10000/ /form h1恭喜你中奖了/h1 /body攻击流程拆解用户登录了bank.com会话Cookie有效。用户收到了攻击者发来的链接点击后访问了evil.com。浏览器加载evil.com的页面页面中的JavaScriptonload事件自动提交了隐藏的表单。浏览器向bank.com/transfer发起一个POST请求。关键点来了由于这是向bank.com发起的请求浏览器会自动附带上bank.com域名下的所有Cookie包括那个代表用户身份的JSESSIONID。bank.com的后端服务器收到请求检查Cookie中的JSESSIONID发现是有效的已登录会话于是认为这是用户本人发起的合法转账请求便执行了向“attacker”账户转账10000元的操作。攻击完成用户资金受损而用户本人可能完全不知情只看到一个“恭喜中奖”的页面。这个例子清晰地展示了攻击者完全不需要窃取你的密码或Cookie他只需要“借用”你浏览器里已有的身份凭证。这就是“跨站请求伪造”这个名字的由来——请求是从evil.com这个“跨站”伪造并发送到bank.com的。2.3 绕过常见“伪防护”的进阶攻击手法很多初级防护措施很容易被绕过了解这些有助于我们设计更健壮的防御。依赖Referer检查有些应用会检查HTTP请求头中的Referer字段判断请求来源是否是自己信任的域名。然而Referer可能被禁用部分用户或浏览器插件出于隐私考虑会禁止发送Referer。HTTPS到HTTP的Referer缺失从HTTPS页面链接到HTTP页面浏览器可能不发送Referer。攻击者可以构造请求通过一些技术手段如利用Flash、某些浏览器的漏洞或通过302跳转攻击者有可能部分控制或篡改Referer或者使其为空从而绕过检查。因此将Referer检查作为唯一防护手段是不可靠的。仅防护POST请求CSRF攻击并非只能通过表单POST发起。GET请求同样危险尤其是当应用使用GET方法来执行状态变更操作时这是一个糟糕的设计但现实中存在。攻击者只需在恶意页面嵌入一个图片标签img srchttps://bank.com/delete?id123用户加载页面时浏览器就会自动发起一个携带Cookie的GET请求。因此防护必须覆盖所有可能改变状态的HTTP方法POST PUT PATCH DELETE等。理解了攻击者的这些“套路”我们就能更有针对性地构建防御。接下来我们就看看Spring Security为我们提供了哪些“武器”。3. Spring Security CSRF防护机制全解析Spring Security的CSRF防护并非一个黑盒魔法它是一套基于“同步器令牌模式”Synchronizer Token Pattern的、可高度定制的安全框架。知其然更要知其所以然。3.1 默认防护的底层工作原理当你引入Spring Security依赖且未做任何CSRF配置时它默认是启用CSRF防护的。它的工作流程是一个经典的“挑战-响应”模型令牌生成与关联当服务器向客户端发送一个需要被防护的页面通常是包含表单的HTML时CsrfFilter会生成一个唯一的、不可预测的令牌Token。这个令牌会被做两件事放入当前HTTP会话Session中。作为一个属性默认为_csrf添加到HttpServletRequest中供视图层如Thymeleaf, JSP渲染到页面里通常是一个隐藏的表单字段input typehidden name_csrf value生成的令牌值/。令牌的提交与验证当客户端提交表单或发起其他受保护的请求时必须将这个令牌一并提交回来。提交方式有两种请求参数作为表单字段_csrf的值。请求头作为X-CSRF-TOKEN或X-XSRF-TOKEN头的值。 服务器端的CsrfFilter会拦截请求从请求中提取令牌并与当前会话中存储的令牌进行比较。验证决策匹配成功请求被认为是合法的放行。匹配失败或缺失请求被认为是潜在的CSRF攻击Spring Security会抛出AccessDeniedException通常会导致一个403Forbidden错误响应。这个机制之所以有效是因为攻击者无法预先知道或读取到当前用户会话中的那个唯一令牌。他构造的恶意请求中无法包含正确的令牌因此会被服务器拒绝。3.2 关键配置类与自定义扩展点Spring Security的CSRF配置主要通过HttpSecurity对象的csrf()方法进行。理解其背后的核心组件能让你在需要定制时得心应手。CsrfFilter这是防护的核心过滤器。它负责令牌的生成、存储、验证以及请求的拦截判断。我们很少直接操作它但它是所有行为的执行者。CsrfTokenRepository令牌仓库接口定义了令牌的加载、生成、保存行为。这是最常用的扩展点。HttpSessionCsrfTokenRepository默认实现。将令牌存储在HttpSession中。简单可靠适用于传统服务端渲染应用。CookieCsrfTokenRepository将令牌存储在Cookie中。这是一种适用于前后端分离架构如React, Vue, Angular的“双Cookie”或“Cookie-to-Header”模式。它通常将令牌写入一个Cookie如XSRF-TOKEN前端JavaScript需要读取这个Cookie的值并在后续请求中将其作为某个HTTP头如X-XSRF-TOKEN发送回来。这种方式避免了会话依赖更适配无状态API。LazyCsrfTokenRepository一个包装器可以延迟令牌的生成直到真正需要时如第一次渲染表单时有助于优化性能。CsrfTokenRequestHandler决定如何处理令牌的请求处理程序。例如XorCsrfTokenRequestAttributeHandler是默认处理器它支持将令牌进行XOR混淆后再输出到页面以应对一些特定的渗透测试扫描器。在Spring Security 6.x及更高版本中这个组件的角色变得更加重要。RequestMatcher用于定义哪些请求需要CSRF防护哪些不需要。这是配置防护范围的关键。3.3 防护范围的精确控制RequestMatcher策略并非所有请求都需要CSRF防护。对防护范围的精确控制既能保证安全又能避免对正常功能如API调用造成干扰。Spring Security允许我们通过RequestMatcher来定义这个范围。默认情况下CSRF防护会忽略以下请求GET,HEAD,TRACE,OPTIONS这些被认为是“安全”的、不改变资源状态的方法。匹配特定路径的请求在旧版本中如/logout的POST请求默认也被忽略但在新版本中需要显式配置。常见的自定义防护策略示例Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf(csrf - csrf // 1. 完全禁用CSRF防护极度不推荐用于Web应用 // .disable() // 2. 忽略特定API路径常用于纯后端API供移动端或第三方调用 .ignoringRequestMatchers(/api/public/**, /webhook/**) // 3. 使用自定义的RequestMatcher进行更复杂的匹配逻辑 .requireCsrfProtectionMatcher(new CustomCsrfRequestMatcher()) ) .authorizeHttpRequests(auth - auth .anyRequest().authenticated() ) .formLogin(withDefaults()); return http.build(); } // 自定义匹配器示例只对特定路径且非GET方法进行防护 static class CustomCsrfRequestMatcher implements RequestMatcher { private final AntPathRequestMatcher[] ignoredMatchers { new AntPathRequestMatcher(/api/**, HttpMethod.GET.name()), new AntPathRequestMatcher(/static/**), new AntPathRequestMatcher(/h2-console/**) // 忽略H2数据库控制台 }; Override public boolean matches(HttpServletRequest request) { // 如果请求匹配忽略列表则不需要CSRF防护 for (AntPathRequestMatcher matcher : ignoredMatchers) { if (matcher.matches(request)) { return false; } } // 默认情况下对所有非“安全”方法POST, PUT, PATCH, DELETE进行防护 return !List.of(GET, HEAD, TRACE, OPTIONS) .contains(request.getMethod()); } } }实操心得在定义忽略规则时务必谨慎。一个常见的错误是忽略了所有/api/**路径。如果你的API也通过浏览器调用例如前端是单页应用SPA那么这些API同样需要CSRF防护。只有当你的API是纯粹给非浏览器客户端如手机App、桌面客户端、其他服务调用时才考虑忽略其CSRF检查并转而使用其他认证方式如OAuth2、JWT。4. 前后端协作下的CSRF防护最佳实践理论讲完了现在进入最关键的实战环节。不同的技术架构CSRF防护的集成方式也不同。我将其分为两大类传统多页应用MPA和现代前后端分离应用SPA。4.1 场景一传统服务端渲染应用如Thymeleaf, JSP这是Spring Security默认防护模式最适配的场景。流程非常自动化。1. 确保表单包含CSRF令牌如果你使用Thymeleaf模板引擎并且表单在Spring Security的保护下Thymeleaf会自动为你添加CSRF令牌的隐藏字段只要你的表单使用th:action属性。!-- Thymeleaf 自动处理 -- form methodpost th:action{/transfer} !-- Thymeleaf会自动在此处插入 input typehidden name_csrf th:value${_csrf.token}/ -- input typetext nametoAccount/ input typenumber nameamount/ button typesubmit转账/button /form如果你使用JSP或者需要手动处理可以像这样获取令牌!-- JSP 手动处理 -- form action/transfer methodpost input typehidden name${_csrf.parameterName} value${_csrf.token}/ !-- 其他表单字段 -- /form2. 处理AJAX请求在现代Web应用中即使是非SPA也大量使用AJAX。你需要手动将CSRF令牌添加到AJAX请求的头部。首先在页面中获取令牌通常可以放在一个meta标签里meta name_csrf th:content${_csrf.token}/ meta name_csrf_header th:content${_csrf.headerName}/然后在全局的JavaScript中配置例如使用jQuery$(document).ajaxSend(function(event, xhr, options) { var token $(meta[name_csrf]).attr(content); var header $(meta[name_csrf_header]).attr(content); if (token header) { xhr.setRequestHeader(header, token); } });这样所有通过jQuery发起的AJAX请求都会自动带上CSRF令牌头。注意事项确保你的JavaScript代码在同一个页面上下文中运行能够访问到包含令牌的meta标签。如果页面是通过AJAX动态加载的需要重新获取或传递令牌。4.2 场景二前后端分离应用如React, Vue, Angular Spring Boot API这是目前更主流的架构。后端提供RESTful API前端是独立的单页应用。此时默认的Session存储令牌模式变得笨重因为API可能是无状态的。我们推荐使用CookieCsrfTokenRepository。后端配置Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf(csrf - csrf // 关键配置使用基于Cookie的CSRF令牌仓库 .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()) ) .authorizeHttpRequests(auth - auth .requestMatchers(/api/login).permitAll() .anyRequest().authenticated() ) // 使用基于JSON的登录而非表单登录 .formLogin(AbstractHttpConfigurer::disable) // 禁用默认表单登录 .httpBasic(AbstractHttpConfigurer::disable); // 禁用HTTP Basic return http.build(); } }CookieCsrfTokenRepository.withHttpOnlyFalse()解析它会创建一个名为XSRF-TOKEN的Cookie来存放CSRF令牌。withHttpOnlyFalse()意味着这个Cookie可以被客户端的JavaScript读取。这是必须的因为前端应用需要读取这个Cookie的值并将其作为请求头发送。服务器在验证时会同时检查请求头X-XSRF-TOKEN和Cookie中的令牌是否匹配。前端协作以Axios为例首次访问用户访问前端应用Spring Boot后端会在响应中设置XSRF-TOKENCookie。前端拦截器配置在前端HTTP客户端如Axios中配置一个请求拦截器从Cookie中读取XSRF-TOKEN的值并将其添加到后续所有“非安全”方法请求的头部。// 以Axios为例 import axios from axios; // 创建一个辅助函数来获取Cookie值 function getCookie(name) { const value ; ${document.cookie}; const parts value.split(; ${name}); if (parts.length 2) return parts.pop().split(;).shift(); } // 创建axios实例 const apiClient axios.create({ baseURL: /api, withCredentials: true, // 关键允许跨域请求携带Cookie }); // 请求拦截器为修改状态的请求添加CSRF Token头 apiClient.interceptors.request.use(config { const token getCookie(XSRF-TOKEN); const method config.method?.toUpperCase(); // 仅为非安全方法添加头 if (token method [POST, PUT, PATCH, DELETE].includes(method)) { config.headers[X-XSRF-TOKEN] token; } return config; }, error { return Promise.reject(error); }); export default apiClient;关键点说明withCredentials: true这是跨域请求时携带Cookie的必备设置。如果你的前端和后端部署在不同域名下后端也需要配置相应的CORS策略来允许凭证。安全方法判断我们只对可能改变状态的请求添加CSRF头这与Spring Security的默认忽略策略保持一致。Cookie安全虽然我们将XSRF-TOKENCookie设置为HttpOnlyfalse以便JS读取但这本身并不引入大的安全风险。因为这个Cookie只用于CSRF防护不包含会话身份信息。攻击者即使通过XSS漏洞获取了这个Cookie他也无法直接发起CSRF攻击因为CSRF攻击不依赖读取Cookie而是依赖自动携带。当然防范XSS永远是重要的。4.3 场景三混合应用与特殊端点处理有些应用是混合形态既有服务端渲染页面也提供API。或者有一些特殊的端点需要特别处理。/logout端点在Spring Security的默认表单登录中注销是通过POST请求到/logout完成的。这个请求也需要CSRF令牌。如果你使用Thymeleaf可以这样写form th:action{/logout} methodpost input typehidden th:name${_csrf.parameterName} th:value${_csrf.token}/ button typesubmit退出登录/button /form如果你希望简化可以配置一个GET方式的注销安全性稍低需权衡.logout(logout - logout .logoutRequestMatcher(new AntPathRequestMatcher(/logout, GET)) )文件上传如果表单包含文件上传enctypemultipart/form-dataCSRF令牌必须作为表单字段_csrf传递而不能放在URL参数中。因为multipart/form-data请求的头部处理方式特殊。确保你的前端表单正确包含了隐藏的CSRF字段。API Gateway/代理后的应用如果你的应用运行在反向代理如Nginx或API网关之后需要注意X-Forwarded-*头可能会影响请求的源判断。确保你的CSRF配置或底层的HttpServletRequest能正确识别客户端的真实IP和协议这通常与服务器和代理的配置有关而非Spring Security本身。5. 高级防护策略、问题排查与安全加固掌握了基础配置后我们来看看如何应对更复杂的情况以及当出现问题时如何快速定位。5.1 自定义令牌生成与验证逻辑绝大多数情况下默认实现已足够安全。但在极高安全要求的场景下你可能需要定制。自定义CsrfTokenRepository你可以实现自己的令牌仓库例如将令牌存储在分布式缓存如Redis中以适应集群部署环境确保所有节点都能验证同一个令牌。Bean public CsrfTokenRepository customTokenRepository() { return new CsrfTokenRepository() { Override public CsrfToken generateToken(HttpServletRequest request) { // 生成一个更复杂或带有业务标识的令牌 return new DefaultCsrfToken(X-CSRF-TOKEN, _csrf, UUID.randomUUID().toString() : System.currentTimeMillis()); } Override public void saveToken(CsrfToken token, HttpServletRequest request, HttpServletResponse response) { // 将令牌存入Rediskey可以为 sessionId “_csrf” if (token ! null) { String key request.getSession().getId() _csrf; redisTemplate.opsForValue().set(key, token.getToken(), 30, TimeUnit.MINUTES); } else { // 删除令牌 } // 同时仍然可以写入Cookie供前端使用 Cookie cookie new Cookie(XSRF-TOKEN, token ! null ? token.getToken() : ); response.addCookie(cookie); } Override public CsrfToken loadToken(HttpServletRequest request) { // 从Redis加载令牌 String key request.getSession().getId() _csrf; String tokenValue redisTemplate.opsForValue().get(key); return (tokenValue ! null) ? new DefaultCsrfToken(X-CSRF-TOKEN, _csrf, tokenValue) : null; } }; }自定义CsrfTokenRequestHandler在Spring Security 6中你可以通过自定义处理器来改变令牌的获取和验证行为例如支持从多个地方头、参数、属性提取令牌。5.2 常见问题排查清单在集成CSRF防护时你可能会遇到以下问题。这里是一个快速排查指南问题现象可能原因排查步骤与解决方案403 Forbidden (Invalid CSRF Token)1. 表单/请求中未包含CSRF令牌。2. 令牌已过期Session失效。3. 前端发送的令牌与后端存储的不匹配。4. 请求被错误的RequestMatcher匹配导致需要防护的请求被放行或反之。1.检查请求使用浏览器开发者工具的“网络”选项卡查看失败的请求。确认请求体Form Data中是否有_csrf参数或请求头中是否有X-XSRF-TOKEN。2.检查Session确认用户会话是否仍然有效。长时间无操作可能导致Session过期。3.检查配置确认CsrfTokenRepository配置正确。前后端分离应用检查CookieCsrfTokenRepository和withCredentials。4.检查忽略规则确认csrf().ignoringRequestMatchers(...)没有错误地忽略了本应防护的路径。前端无法读取XSRF-TOKENCookie1. Cookie未成功设置。2. Cookie被设置为HttpOnlytrueJS无法读取。3. 跨域问题前端域名与后端设置的Cookie域名不匹配。1.检查响应头在登录或首次GET请求的响应中查看Set-Cookie头是否包含XSRF-TOKEN。2.检查配置确保使用了CookieCsrfTokenRepository.withHttpOnlyFalse()。3.检查CORS确保后端CORS配置允许前端源allowedOrigins并且允许凭证allowCredentials(true)。注销后再次登录CSRF失败注销操作通常会使Session失效从而清除了旧的CSRF令牌。但前端可能还缓存着旧的令牌或Cookie。1.前端清理在注销后前端应主动清理或重置存储的CSRF令牌。2.重新获取登录成功后前端应触发一次不需要CSRF防护的GET请求如获取用户信息以从响应中获取新的CSRF令牌Cookie。文件上传失败CSRF令牌作为URL参数传递而不是表单字段。强制使用表单字段确保文件上传表单中有一个隐藏的input typehidden name_csrf value.../字段。不能依赖JavaScript将令牌添加到请求头因为multipart/form-data格式特殊。5.3 安全加固与纵深防御CSRF防护是重要的一环但绝不能是唯一的一环。真正的安全来自于纵深防御。关键操作二次验证对于转账、修改密码、修改邮箱等极高风险操作强制要求用户进行二次验证例如输入登录密码、短信验证码、或使用TOTP动态令牌。这样即使CSRF防护被某种未知手段绕过攻击者也无法完成操作。严格遵循RESTful规范使用正确的HTTP方法。GET请求只用于获取资源绝不用于执行修改操作。这能从设计上减少CSRF攻击面。设置合适的Cookie属性Secure仅通过HTTPS传输Cookie防止在明文HTTP中被窃听。SameSiteStrict/Lax现代浏览器广泛支持。设置为Strict或Lax可以很大程度上阻止第三方网站发起的跨站请求携带Cookie从浏览器层面缓解CSRF。对于会话CookieSameSiteLax是一个很好的平衡选择。// 在Spring Boot配置中可以通过 application.properties 全局设置 server.servlet.session.cookie.same-sitelax server.servlet.session.cookie.securetrue防范XSS跨站脚本攻击XSS漏洞可以让攻击者在你网站的上下文中执行恶意脚本从而有可能窃取到CSRF令牌如果令牌存储在可被JS访问的地方如Cookie或DOM中。因此对用户输入进行严格的过滤和转义设置安全的CSP内容安全策略头是防止CSRF令牌被窃取的关键。定期安全审计与依赖更新定期使用OWASP ZAP、Burp Suite等工具对你的应用进行CSRF漏洞扫描。同时保持Spring Security及相关依赖库更新到最新版本以获取安全补丁。CSRF防护不是一项“配置即忘”的任务。它需要你根据应用架构、用户交互模式和安全等级进行持续的思考和调整。从理解攻击原理开始到合理配置防护策略再到建立纵深防御体系每一步都至关重要。希望这篇结合原理与实战的剖析能让你在构建安全可靠的Spring Boot应用时多一份从容和自信。记住安全是一个过程而非一个状态。
