CSRF防范

什么是CSER

以下是基于 CSRF 攻擊過程的 順序圖 及詳細解釋，結合多個技術文檔中的攻擊流程：

CSRF 攻擊順序圖

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

攻擊過程分步解讀

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

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

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

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

<!-- 惡意網(wǎng)站B的頁面 -->
<img src="http://網(wǎng)站A/轉賬?to=攻擊者&amount=1000">
<!-- 或通過JS自動提交表單 -->
<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>

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

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

攻擊完成

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

攻擊成功的關鍵條件

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

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

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

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

Security的CSRF簡介

根據(jù) Spring Security 的官方設計理念及社區(qū)實踐（綜合多個技術文檔和博客），其 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 的生成規(guī)則，包含 token 值、參數(shù)名（_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 防護，攻擊者可利用以下漏洞發(fā)起攻擊：

偽造用戶操作：

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

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

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

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

企業(yè)級風險：

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

三、官方文檔的補充說明

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

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

總結

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

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

以下是標準的CSRF防護參數(shù)及其生成、使用和失效規(guī)則的總結表格，結合多個技術文檔和實踐案例：

詳細說明

CSRF Token

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

失效條件：

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

SameSite Cookie

生成者：服務端在用戶登錄時生成會話Cookie，并設置SameSite屬性。

使用規(guī)則：

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

二次驗證參數(shù)

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

引用來源

• CSRF Token生成與驗證邏輯：
• SameSite Cookie機制：
• 二次驗證參數(shù)設計：

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

Security是怎么防范的

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

一、CSRF Token 驗證機制

生成與存儲 Token

• Token 生成：當用戶首次訪問受保護頁面時，Spring Security 會自動生成一個唯一的隨機 CSRF Token。
• 默認使用 HttpSessionCsrfTokenRepository，將 Token 存儲在用戶會話（HttpSession）中。
• 若為前后端分離架構，可使用 CookieCsrfTokenRepository 將 Token 存儲于 Cookie 中，并允許前端通過 JavaScript 讀取。
• Token 結構：包含三個核心屬性：token（隨機值）、parameterName（參數(shù)名，默認為 _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 和表單/請求頭中，驗證時需兩者一致。
• 適用于分布式系統(tǒng)，避免依賴會話存儲。

安全方法限制

•  默認僅對 POST、PUT、DELETE、PATCH 等狀態(tài)修改類請求啟用 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 和 雙重驗證 等策略，有效阻斷攻擊者偽造請求的能力。其設計兼顧靈活性與安全性，開發(fā)者需根據(jù)架構（如傳統(tǒng) MVC 或前后端分離）選擇合適的 Token 存儲方式，并遵循最佳實踐以確保全面防護。

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

最新評論