CSRF防范

什么是CSER

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

CSRF 攻擊順序圖

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

攻擊過程分步解讀

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

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

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

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

<!-- 惡意網(wǎng)站B的頁(yè)面 -->
<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ā)送偽造請(qǐng)求

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

攻擊完成

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

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

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

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

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

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

Security的CSRF簡(jiǎn)介

根據(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）的請(qǐng)求。

Token 驗(yàn)證流程：

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

核心組件

• CsrfToken 接口：定義 Token 的生成規(guī)則，包含 token 值、參數(shù)名（_csrf）和請(qǐng)求頭名（X-CSRF-TOKEN）。
• CsrfTokenRepository：
• HttpSessionCsrfTokenRepository（默認(rèn)）：Token 存儲(chǔ)于 Session。
• CookieCsrfTokenRepository：Token 存儲(chǔ)于 Cookie，適用于前后端分離場(chǎng)景。

配置示例：

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

前端集成方式

表單頁(yè)面：通過模板引擎（如 Thymeleaf）自動(dòng)注入 Token：

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

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

// 從 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，限制跨域請(qǐng)求攜帶 Cookie（需瀏覽器支持）。
• 二次驗(yàn)證：對(duì)敏感操作（如轉(zhuǎn)賬）疊加驗(yàn)證碼或密碼確認(rèn)。

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

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

偽造用戶操作：

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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

詳細(xì)說(shuō)明

CSRF Token

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

失效條件：

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

SameSite Cookie

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

使用規(guī)則：

• SameSite=Strict：禁止跨域請(qǐng)求攜帶Cookie（適用于高敏感操作）。
• SameSite=Lax：允許安全跨域請(qǐng)求（如導(dǎo)航鏈接的GET請(qǐng)求）。
• 失效條件：遵循Cookie的過期策略（如會(huì)話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分鐘）。

引用來(lái)源

• 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ī)制 和 防御策略組合 來(lái)避免 CSRF 攻擊，以下是其核心實(shí)現(xiàn)邏輯及關(guān)鍵步驟：

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

生成與存儲(chǔ) Token

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

客戶端攜帶 Token

• 表單提交：

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

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

• AJAX 請(qǐng)求：

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

// 從 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 會(huì)攔截所有非安全 HTTP 方法（如 POST、PUT、DELETE），從請(qǐng)求中提取 Token，并與服務(wù)端存儲(chǔ)的 Token 對(duì)比。
• 若 Token 匹配，請(qǐng)求通過。
• 若 Token 缺失或不匹配，返回 403 Forbidden 錯(cuò)誤。

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

SameSite Cookie 屬性

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

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

 配置示例：

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

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

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

安全方法限制

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

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

啟用與禁用

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

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

http.csrf().disable();

前后端分離配置

• 后端配置 Cookie 存儲(chǔ) Token：

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

前端從 Cookie 讀取 Token 并添加到請(qǐng)求頭。

最佳實(shí)踐

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

總結(jié)

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

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

最新評(píng)論