SpringSecurity当中的CSRF防范使用详解

CSRF防范

什么是CSER

以下是基于 CSRF 攻击过程的 顺序图 及详细解释，结合多个技术文档中的攻击流程：

CSRF 攻击顺序图

用户 浏览器 受信任网站A 恶意网站B 正常操作阶段 访问网站A并登录 发送登录请求 返回登录成功的Cookie 存储Cookie（保持会话） 攻击触发阶段 访问恶意网站B（如点击链接） 请求页面 返回包含恶意代码的页面（如自动提交表单的JS） 伪造请求执行阶段 自动携带Cookie发送恶意请求（如转账） 验证Cookie合法，执行请求 用户未感知到操作已被篡改 用户 浏览器 受信任网站A 恶意网站B

攻击过程分步解读

用户登录受信任网站A

• 用户通过浏览器正常登录网站A（例如银行网站），服务器生成会话 Cookie 并返回给浏览器。
• 关键点：此时浏览器会存储该 Cookie，后续所有对网站A的请求都会自动携带此 Cookie（如 Set-Cookie: session_id=abc123）。

用户访问恶意网站B

• 攻击者通过钓鱼链接、诱导广告等方式，诱使用户访问恶意网站B。
• 攻击代码示例（来自网页3）：

<!-- 恶意网站B的页面 -->
<img src="http://网站A/转账?to=攻击者&amount=1000">
<!-- 或通过JS自动提交表单 -->
<script>
  document.write('<form action="http://网站A/改密码" method="POST">');
  document.write('<input type="hidden" name="new_password" value="hacker123">');
  document.write('</form>');
  document.forms[0].submit();
</script>

浏览器自动发送伪造请求

• 恶意网站B的代码会触发浏览器向网站A发送请求（如转账、修改密码），浏览器会自动携带用户已登录的 Cookie。
• 服务器视角：网站A收到请求后，验证 Cookie 合法，误认为是用户主动操作，执行恶意请求。

攻击完成

• 用户未感知到任何异常（如无页面跳转），但敏感操作已被执行（如资金转移、密码重置）。

攻击成功的关键条件

1. 用户已登录受信任网站A：攻击依赖用户的活跃会话。
2. 网站A未启用CSRF防护：如未校验 Token、Referer 或二次验证。
3. 请求参数可预测：例如通过 GET 请求执行敏感操作（如 GET /转账?to=攻击者）。

防御措施（引用自网页5、网页6）

• Token 验证：在表单或请求头中嵌入随机 Token，服务端校验 Token 合法性。
• SameSite Cookie：设置 Cookie 的 SameSite=Strict/Lax 属性，限制跨域请求携带 Cookie。
• Referer 检查：验证请求来源是否为可信域名。

通过顺序图可以看出，CSRF 攻击的 核心逻辑是滥用浏览器的 Cookie 自动携带机制，而防御的关键在于 阻断攻击者伪造请求的能力。

Security的CSRF简介

根据 Spring Security 的官方设计理念及社区实践（综合多个技术文档和博客），其 CSRF 防护机制的核心逻辑如下：

一、Spring Security 的 CSRF 防护机制

默认启用的防护

自动拦截：Spring Security 从 4.0 版本起默认启用 CSRF 保护，通过 CsrfFilter 拦截所有非安全 HTTP 方法（如 POST、PUT、DELETE）的请求。

Token 验证流程：

• 生成 Token：用户首次访问时，服务端生成唯一的 CSRF Token 并存储于 HttpSession 或 Cookie 中（默认使用 HttpSessionCsrfTokenRepository）。
• 客户端携带 Token：在表单或 AJAX 请求中必须包含该 Token（例如通过隐藏字段或请求头）。
• 服务端校验：请求到达时，CsrfFilter 会对比客户端提交的 Token 与服务端存储的 Token，若不一致则拒绝请求（返回 403 错误）。

核心组件

• CsrfToken 接口：定义 Token 的生成规则，包含 token 值、参数名（_csrf）和请求头名（X-CSRF-TOKEN）。
• CsrfTokenRepository：
• HttpSessionCsrfTokenRepository（默认）：Token 存储于 Session。
• CookieCsrfTokenRepository：Token 存储于 Cookie，适用于前后端分离场景。

配置示例：

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .csrf()
                .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());
    }
}

前端集成方式

表单页面：通过模板引擎（如 Thymeleaf）自动注入 Token：

<input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}"/>

AJAX 请求：从 Cookie 或 Meta 标签获取 Token 并添加到请求头：

// 从 Cookie 获取 Token（需配置 CookieCsrfTokenRepository）
const token = document.cookie.match(/XSRF-TOKEN=([^;]+)/)[1];
fetch('/api/data', {
    method: 'POST',
    headers: { 'X-XSRF-TOKEN': token }
});

扩展防护策略

•  SameSite Cookie 属性：通过设置 Cookie 的 SameSite=Strict/Lax，限制跨域请求携带 Cookie（需浏览器支持）。
• 二次验证：对敏感操作（如转账）叠加验证码或密码确认。

二、未启用 CSRF 防护的危害场景

如果未启用 CSRF 防护，攻击者可利用以下漏洞发起攻击：

伪造用户操作：

• 自动触发恶意请求：通过恶意页面嵌入 <img> 或自动提交表单，诱导已登录用户触发转账、修改密码等操作。
• 示例攻击代码：

<img src="http://bank.com/transfer?to=attacker&amount=10000">

数据篡改与泄露：

• 账户信息泄露：攻击者篡改用户邮箱或手机号，后续可通过“忘记密码”功能接管账户。
• 业务逻辑绕过：例如自动关注陌生账号、删除用户数据等。

企业级风险：

• 供应链攻击：通过管理员账户的 CSRF 漏洞植入后门，导致企业系统被渗透。
• 合规风险：因数据泄露违反 GDPR 等法规，面临高额罚款。

三、官方文档的补充说明

虽然未直接引用 spring.io 官网，但以上机制与官方文档一致（可通过 Spring Security 官方文档 验证）：

• 防护原理：基于 Token 的同步器模式（Synchronizer Token Pattern）。
• 禁用场景：仅推荐在纯 API 服务（无浏览器交互）时通过 http.csrf().disable() 关闭防护。

总结

Spring Security 通过 CSRF Token 的生成与验证机制 有效防御跨站请求伪造攻击。若未启用防护，攻击者可利用用户已登录的会话劫持敏感操作，导致数据泄露、资金损失等严重后果。开发者应结合业务场景选择 Token 存储方式（Session/Cookie），并确保前端正确集成 Token。

CSRF防范的必要参数

以下是标准的CSRF防护参数及其生成、使用和失效规则的总结表格，结合多个技术文档和实践案例：

详细说明

CSRF Token

• 生成者：服务端通过CsrfTokenRepository生成，例如HttpSessionCsrfTokenRepository（存储在会话中）或CookieCsrfTokenRepository（存储在Cookie）。
• 生成时机：用户首次访问需要CSRF防护的页面时（如登录页、表单页），或每次页面加载时动态生成新Token。
• 使用时机：必须嵌入到所有非安全方法（POST/PUT/DELETE）的请求中，例如：
• 表单：通过隐藏字段<input type="hidden" name="_csrf" value="token">。
• AJAX：通过请求头X-CSRF-TOKEN或X-XSRF-TOKEN传递。

失效条件：

• 会话过期：若用户会话终止，Token随之失效。
• 单次有效性：部分系统设计Token仅限单次使用（如支付场景）。
• 时间窗口：设置Token有效期（如10分钟），超时自动失效。

SameSite Cookie

生成者：服务端在用户登录时生成会话Cookie，并设置SameSite属性。

使用规则：

• SameSite=Strict：禁止跨域请求携带Cookie（适用于高敏感操作）。
• SameSite=Lax：允许安全跨域请求（如导航链接的GET请求）。
• 失效条件：遵循Cookie的过期策略（如会话Cookie在浏览器关闭后失效）。

二次验证参数

• 生成者：服务端在用户触发敏感操作时生成（如短信验证码、动态口令）。
• 使用时机：关键操作（如修改密码、大额转账）前需用户二次确认。
• 失效条件：验证码使用后立即失效，或设计为短时间有效（如5分钟）。

引用来源

• CSRF Token生成与验证逻辑：
• SameSite Cookie机制：
• 二次验证参数设计：

通过上述参数组合（如Token+SameSite+二次验证），可构建多层防御体系，有效阻断CSRF攻击。

Security是怎么防范的

Spring Security 通过 CSRF Token 验证机制 和 防御策略组合 来避免 CSRF 攻击，以下是其核心实现逻辑及关键步骤：

一、CSRF Token 验证机制

生成与存储 Token

• Token 生成：当用户首次访问受保护页面时，Spring Security 会自动生成一个唯一的随机 CSRF Token。
• 默认使用 HttpSessionCsrfTokenRepository，将 Token 存储在用户会话（HttpSession）中。
• 若为前后端分离架构，可使用 CookieCsrfTokenRepository 将 Token 存储于 Cookie 中，并允许前端通过 JavaScript 读取。
• Token 结构：包含三个核心属性：token（随机值）、parameterName（参数名，默认为 _csrf）、headerName（请求头名，默认为 X-CSRF-TOKEN）。

客户端携带 Token

• 表单提交：

在 HTML 表单中通过隐藏字段嵌入 Token。例如使用 Thymeleaf 模板引擎自动注入：

<input type="hidden" name="${_csrf.parameterName}" value="${_csrf.token}"/>

• AJAX 请求：

通过请求头传递 Token。前端需从 Cookie 或 Meta 标签中获取 Token，并添加到请求头中：

// 从 Cookie 获取 Token（需配置 CookieCsrfTokenRepository）
const token = document.cookie.match(/XSRF-TOKEN=([^;]+)/)[1];
fetch('/api/data', {
    method: 'POST',
    headers: { 'X-XSRF-TOKEN': token }
});

服务端验证 Token

• 拦截与校验：
• CsrfFilter 会拦截所有非安全 HTTP 方法（如 POST、PUT、DELETE），从请求中提取 Token，并与服务端存储的 Token 对比。
• 若 Token 匹配，请求通过。
• 若 Token 缺失或不匹配，返回 403 Forbidden 错误。

二、防御策略扩展

SameSite Cookie 属性

通过设置 Cookie 的 SameSite 属性限制跨域请求携带 Cookie：

• SameSite=Strict：仅允许同站点请求携带 Cookie。
• SameSite=Lax：允许部分安全跨站点请求（如导航链接）。

 配置示例：

@Bean
public CsrfTokenRepository csrfTokenRepository() {
    CookieCsrfTokenRepository repository = new CookieCsrfTokenRepository();
    repository.setSameSite("Lax");
    return repository;
}

双重验证（Double Submit Cookie）

•  服务端将 Token 同时存储在 Cookie 和表单/请求头中，验证时需两者一致。
• 适用于分布式系统，避免依赖会话存储。

安全方法限制

•  默认仅对 POST、PUT、DELETE、PATCH 等状态修改类请求启用 CSRF 验证，而 GET、HEAD、OPTIONS 等安全方法无需验证。

三、配置与最佳实践

启用与禁用

默认启用：Spring Security 4.0+ 默认开启 CSRF 防护。

• 手动关闭（不推荐）：

http.csrf().disable();

前后端分离配置

• 后端配置 Cookie 存储 Token：

http.csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());

前端从 Cookie 读取 Token 并添加到请求头。

最佳实践

• 始终启用 CSRF 防护：除非服务为纯 API 且无浏览器交互。
• 结合 HTTPS：防止 Token 被中间人窃取。
• 定期更新依赖：修复已知漏洞。

总结

Spring Security 通过 CSRF Token 的生成、传递与验证机制，结合 SameSite Cookie 和 双重验证 等策略，有效阻断攻击者伪造请求的能力。其设计兼顾灵活性与安全性，开发者需根据架构（如传统 MVC 或前后端分离）选择合适的 Token 存储方式，并遵循最佳实践以确保全面防护。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

最新评论