CSRF防范

什么是CSER

以下是基于 CSRF 攻擊過程的 順序圖 及詳細(xì)解釋，結(jié)合多個(gè)技術(shù)文檔中的攻擊流程：

CSRF 攻擊順序圖

用戶 瀏覽器 受信任網(wǎng)站A 惡意網(wǎng)站B 正常操作階段 訪問網(wǎng)站A并登錄 發(fā)送登錄請求 返回登錄成功的Cookie 存儲Cookie（保持會話） 攻擊觸發(fā)階段 訪問惡意網(wǎng)站B（如點(diǎn)擊鏈接） 請求頁面 返回包含惡意代碼的頁面（如自動(dòng)提交表單的JS） 偽造請求執(zhí)行階段 自動(dòng)攜帶Cookie發(fā)送惡意請求（如轉(zhuǎn)賬） 驗(yàn)證Cookie合法，執(zhí)行請求 用戶未感知到操作已被篡改 用戶 瀏覽器 受信任網(wǎng)站A 惡意網(wǎng)站B

攻擊過程分步解讀

用戶登錄受信任網(wǎng)站A

• 用戶通過瀏覽器正常登錄網(wǎng)站A（例如銀行網(wǎng)站），服務(wù)器生成會話 Cookie 并返回給瀏覽器。
• 關(guān)鍵點(diǎn)：此時(shí)瀏覽器會存儲該 Cookie，后續(xù)所有對網(wǎng)站A的請求都會自動(dòng)攜帶此 Cookie（如 Set-Cookie: session_id=abc123）。

用戶訪問惡意網(wǎng)站B

• 攻擊者通過釣魚鏈接、誘導(dǎo)廣告等方式，誘使用戶訪問惡意網(wǎng)站B。
• 攻擊代碼示例（來自網(wǎng)頁3）：

<!-- 惡意網(wǎng)站B的頁面 -->
<img src="http://網(wǎng)站A/轉(zhuǎn)賬?to=攻擊者&amount=1000">
<!-- 或通過JS自動(dòng)提交表單 -->
<script>
  document.write('<form action="http://網(wǎng)站A/改密碼" method="POST">');
  document.write('<input type="hidden" name="new_password" value="hacker123">');
  document.write('</form>');
  document.forms[0].submit();
</script>

瀏覽器自動(dòng)發(fā)送偽造請求

• 惡意網(wǎng)站B的代碼會觸發(fā)瀏覽器向網(wǎng)站A發(fā)送請求（如轉(zhuǎn)賬、修改密碼），瀏覽器會自動(dòng)攜帶用戶已登錄的 Cookie。
• 服務(wù)器視角：網(wǎng)站A收到請求后，驗(yàn)證 Cookie 合法，誤認(rèn)為是用戶主動(dòng)操作，執(zhí)行惡意請求。

攻擊完成

• 用戶未感知到任何異常（如無頁面跳轉(zhuǎn)），但敏感操作已被執(zhí)行（如資金轉(zhuǎn)移、密碼重置）。

攻擊成功的關(guān)鍵條件

1. 用戶已登錄受信任網(wǎng)站A：攻擊依賴用戶的活躍會話。
2. 網(wǎng)站A未啟用CSRF防護(hù)：如未校驗(yàn) Token、Referer 或二次驗(yàn)證。
3. 請求參數(shù)可預(yù)測：例如通過 GET 請求執(zhí)行敏感操作（如 GET /轉(zhuǎn)賬?to=攻擊者）。

防御措施（引用自網(wǎng)頁5、網(wǎng)頁6）

• Token 驗(yàn)證：在表單或請求頭中嵌入隨機(jī) Token，服務(wù)端校驗(yàn) Token 合法性。
• SameSite Cookie：設(shè)置 Cookie 的 SameSite=Strict/Lax 屬性，限制跨域請求攜帶 Cookie。
• Referer 檢查：驗(yàn)證請求來源是否為可信域名。

通過順序圖可以看出，CSRF 攻擊的 核心邏輯是濫用瀏覽器的 Cookie 自動(dòng)攜帶機(jī)制，而防御的關(guān)鍵在于 阻斷攻擊者偽造請求的能力。

Security的CSRF簡介

根據(jù) Spring Security 的官方設(shè)計(jì)理念及社區(qū)實(shí)踐（綜合多個(gè)技術(shù)文檔和博客），其 CSRF 防護(hù)機(jī)制的核心邏輯如下：

一、Spring Security 的 CSRF 防護(hù)機(jī)制

默認(rèn)啟用的防護(hù)

自動(dòng)攔截：Spring Security 從 4.0 版本起默認(rèn)啟用 CSRF 保護(hù)，通過 CsrfFilter 攔截所有非安全 HTTP 方法（如 POST、PUT、DELETE）的請求。

Token 驗(yàn)證流程：

• 生成 Token：用戶首次訪問時(shí)，服務(wù)端生成唯一的 CSRF Token 并存儲于 HttpSession 或 Cookie 中（默認(rèn)使用 HttpSessionCsrfTokenRepository）。
• 客戶端攜帶 Token：在表單或 AJAX 請求中必須包含該 Token（例如通過隱藏字段或請求頭）。
• 服務(wù)端校驗(yàn)：請求到達(dá)時(shí)，CsrfFilter 會對比客戶端提交的 Token 與服務(wù)端存儲的 Token，若不一致則拒絕請求（返回 403 錯(cuò)誤）。

核心組件

• CsrfToken 接口：定義 Token 的生成規(guī)則，包含 token 值、參數(shù)名（_csrf）和請求頭名（X-CSRF-TOKEN）。
• CsrfTokenRepository：
• HttpSessionCsrfTokenRepository（默認(rèn)）：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）自動(dòng)注入 Token：

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

AJAX 請求：從 Cookie 或 Meta 標(biāo)簽獲取 Token 并添加到請求頭：

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

擴(kuò)展防護(hù)策略

•  SameSite Cookie 屬性：通過設(shè)置 Cookie 的 SameSite=Strict/Lax，限制跨域請求攜帶 Cookie（需瀏覽器支持）。
• 二次驗(yàn)證：對敏感操作（如轉(zhuǎn)賬）疊加驗(yàn)證碼或密碼確認(rèn)。

二、未啟用 CSRF 防護(hù)的危害場景

如果未啟用 CSRF 防護(hù)，攻擊者可利用以下漏洞發(fā)起攻擊：

偽造用戶操作：

• 自動(dòng)觸發(fā)惡意請求：通過惡意頁面嵌入 <img> 或自動(dòng)提交表單，誘導(dǎo)已登錄用戶觸發(fā)轉(zhuǎn)賬、修改密碼等操作。
• 示例攻擊代碼：

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

數(shù)據(jù)篡改與泄露：

• 賬戶信息泄露：攻擊者篡改用戶郵箱或手機(jī)號，后續(xù)可通過“忘記密碼”功能接管賬戶。
• 業(yè)務(wù)邏輯繞過：例如自動(dòng)關(guān)注陌生賬號、刪除用戶數(shù)據(jù)等。

企業(yè)級風(fēng)險(xiǎn)：

• 供應(yīng)鏈攻擊：通過管理員賬戶的 CSRF 漏洞植入后門，導(dǎo)致企業(yè)系統(tǒng)被滲透。
• 合規(guī)風(fēng)險(xiǎn)：因數(shù)據(jù)泄露違反 GDPR 等法規(guī)，面臨高額罰款。

三、官方文檔的補(bǔ)充說明

雖然未直接引用 spring.io 官網(wǎng)，但以上機(jī)制與官方文檔一致（可通過 Spring Security 官方文檔 驗(yàn)證）：

• 防護(hù)原理：基于 Token 的同步器模式（Synchronizer Token Pattern）。
• 禁用場景：僅推薦在純 API 服務(wù)（無瀏覽器交互）時(shí)通過 http.csrf().disable() 關(guān)閉防護(hù)。

總結(jié)

Spring Security 通過 CSRF Token 的生成與驗(yàn)證機(jī)制 有效防御跨站請求偽造攻擊。若未啟用防護(hù)，攻擊者可利用用戶已登錄的會話劫持敏感操作，導(dǎo)致數(shù)據(jù)泄露、資金損失等嚴(yán)重后果。開發(fā)者應(yīng)結(jié)合業(yè)務(wù)場景選擇 Token 存儲方式（Session/Cookie），并確保前端正確集成 Token。

CSRF防范的必要參數(shù)

以下是標(biāo)準(zhǔn)的CSRF防護(hù)參數(shù)及其生成、使用和失效規(guī)則的總結(jié)表格，結(jié)合多個(gè)技術(shù)文檔和實(shí)踐案例：

詳細(xì)說明

CSRF Token

• 生成者：服務(wù)端通過CsrfTokenRepository生成，例如HttpSessionCsrfTokenRepository（存儲在會話中）或CookieCsrfTokenRepository（存儲在Cookie）。
• 生成時(shí)機(jī)：用戶首次訪問需要CSRF防護(hù)的頁面時(shí)（如登錄頁、表單頁），或每次頁面加載時(shí)動(dòng)態(tài)生成新Token。
• 使用時(shí)機(jī)：必須嵌入到所有非安全方法（POST/PUT/DELETE）的請求中，例如：
• 表單：通過隱藏字段<input type="hidden" name="_csrf" value="token">。
• AJAX：通過請求頭X-CSRF-TOKEN或X-XSRF-TOKEN傳遞。

失效條件：

• 會話過期：若用戶會話終止，Token隨之失效。
• 單次有效性：部分系統(tǒng)設(shè)計(jì)Token僅限單次使用（如支付場景）。
• 時(shí)間窗口：設(shè)置Token有效期（如10分鐘），超時(shí)自動(dòng)失效。

SameSite Cookie

生成者：服務(wù)端在用戶登錄時(shí)生成會話Cookie，并設(shè)置SameSite屬性。

使用規(guī)則：

• SameSite=Strict：禁止跨域請求攜帶Cookie（適用于高敏感操作）。
• SameSite=Lax：允許安全跨域請求（如導(dǎo)航鏈接的GET請求）。
• 失效條件：遵循Cookie的過期策略（如會話Cookie在瀏覽器關(guān)閉后失效）。

二次驗(yàn)證參數(shù)

• 生成者：服務(wù)端在用戶觸發(fā)敏感操作時(shí)生成（如短信驗(yàn)證碼、動(dòng)態(tài)口令）。
• 使用時(shí)機(jī)：關(guān)鍵操作（如修改密碼、大額轉(zhuǎn)賬）前需用戶二次確認(rèn)。
• 失效條件：驗(yàn)證碼使用后立即失效，或設(shè)計(jì)為短時(shí)間有效（如5分鐘）。

引用來源

• CSRF Token生成與驗(yàn)證邏輯：
• SameSite Cookie機(jī)制：
• 二次驗(yàn)證參數(shù)設(shè)計(jì)：

通過上述參數(shù)組合（如Token+SameSite+二次驗(yàn)證），可構(gòu)建多層防御體系，有效阻斷CSRF攻擊。

Security是怎么防范的

Spring Security 通過 CSRF Token 驗(yàn)證機(jī)制 和 防御策略組合 來避免 CSRF 攻擊，以下是其核心實(shí)現(xiàn)邏輯及關(guān)鍵步驟：

一、CSRF Token 驗(yàn)證機(jī)制

生成與存儲 Token

• Token 生成：當(dāng)用戶首次訪問受保護(hù)頁面時(shí)，Spring Security 會自動(dòng)生成一個(gè)唯一的隨機(jī) CSRF Token。
• 默認(rèn)使用 HttpSessionCsrfTokenRepository，將 Token 存儲在用戶會話（HttpSession）中。
• 若為前后端分離架構(gòu)，可使用 CookieCsrfTokenRepository 將 Token 存儲于 Cookie 中，并允許前端通過 JavaScript 讀取。
• Token 結(jié)構(gòu)：包含三個(gè)核心屬性：token（隨機(jī)值）、parameterName（參數(shù)名，默認(rèn)為 _csrf）、headerName（請求頭名，默認(rèn)為 X-CSRF-TOKEN）。

客戶端攜帶 Token

• 表單提交：

在 HTML 表單中通過隱藏字段嵌入 Token。例如使用 Thymeleaf 模板引擎自動(dòng)注入：

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

• AJAX 請求：

通過請求頭傳遞 Token。前端需從 Cookie 或 Meta 標(biāo)簽中獲取 Token，并添加到請求頭中：

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

服務(wù)端驗(yàn)證 Token

• 攔截與校驗(yàn)：
• CsrfFilter 會攔截所有非安全 HTTP 方法（如 POST、PUT、DELETE），從請求中提取 Token，并與服務(wù)端存儲的 Token 對比。
• 若 Token 匹配，請求通過。
• 若 Token 缺失或不匹配，返回 403 Forbidden 錯(cuò)誤。

二、防御策略擴(kuò)展

SameSite Cookie 屬性

通過設(shè)置 Cookie 的 SameSite 屬性限制跨域請求攜帶 Cookie：

• SameSite=Strict：僅允許同站點(diǎn)請求攜帶 Cookie。
• SameSite=Lax：允許部分安全跨站點(diǎn)請求（如導(dǎo)航鏈接）。

 配置示例：

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

雙重驗(yàn)證（Double Submit Cookie）

•  服務(wù)端將 Token 同時(shí)存儲在 Cookie 和表單/請求頭中，驗(yàn)證時(shí)需兩者一致。
• 適用于分布式系統(tǒng)，避免依賴會話存儲。

安全方法限制

•  默認(rèn)僅對 POST、PUT、DELETE、PATCH 等狀態(tài)修改類請求啟用 CSRF 驗(yàn)證，而 GET、HEAD、OPTIONS 等安全方法無需驗(yàn)證。

三、配置與最佳實(shí)踐

啟用與禁用

默認(rèn)啟用：Spring Security 4.0+ 默認(rèn)開啟 CSRF 防護(hù)。

• 手動(dòng)關(guān)閉（不推薦）：

http.csrf().disable();

前后端分離配置

• 后端配置 Cookie 存儲 Token：

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

前端從 Cookie 讀取 Token 并添加到請求頭。

最佳實(shí)踐

• 始終啟用 CSRF 防護(hù)：除非服務(wù)為純 API 且無瀏覽器交互。
• 結(jié)合 HTTPS：防止 Token 被中間人竊取。
• 定期更新依賴：修復(fù)已知漏洞。

總結(jié)

Spring Security 通過 CSRF Token 的生成、傳遞與驗(yàn)證機(jī)制，結(jié)合 SameSite Cookie 和 雙重驗(yàn)證 等策略，有效阻斷攻擊者偽造請求的能力。其設(shè)計(jì)兼顧靈活性與安全性，開發(fā)者需根據(jù)架構(gòu)（如傳統(tǒng) MVC 或前后端分離）選擇合適的 Token 存儲方式，并遵循最佳實(shí)踐以確保全面防護(hù)。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。