如何分析Spring對CSRF的防范

這篇文章將為大家詳細講解有關(guān)如何分析Spring對CSRF的防范，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

什么是 CSRF

跨站請求偽造。經(jīng)典場景是：

1）受害者首先登錄了銀行網(wǎng)站

2）用戶沒有 longout 的情況下

3）用同一個瀏覽器訪問了“壞”網(wǎng)站

4）“壞”網(wǎng)站有一個向銀行網(wǎng)站提交業(yè)務(wù)請求的頁面

5）誘使用戶發(fā)送這個請求。

實際上利用有 XSS 漏洞，完全可以無需受害者參與利用 javascript 而自動觸發(fā)第 4 第 5 步。

這個場景背后的邏輯：

這里我們把瀏覽器等同于用戶，有些數(shù)據(jù)是用戶自己可見的，有些數(shù)據(jù)是瀏覽器自動處理、發(fā)送而用戶對這些數(shù)據(jù)是無感知的（比如 SessionId）。
銀行網(wǎng)站以 cookie 的形式把 sessionId 發(fā)送給瀏覽器（set-cookie），瀏覽器每次請求都會再自動帶上 cookie（cookie）。
上面場景第 5 步雖然“壞”表單不是源于銀行網(wǎng)站頁面而是在第三方網(wǎng)站的頁面上，但是瀏覽器發(fā)現(xiàn)目標地址是銀行網(wǎng)站，因此會自動帶上相應(yīng)的 cookie，比如 JSESSION 就會隨帶著被發(fā)送了。從服務(wù)器的角度看，來自第 4 步的數(shù)據(jù)與正常數(shù)據(jù)沒有任何差別，因為這個業(yè)務(wù)請求便會被執(zhí)行。

歸根結(jié)底，這種 CSRF 的問題是因為早期的cookie設(shè)計過于簡單，沒有和現(xiàn)代瀏覽器同源策略等安全機制同步造成的。

解決方案

一個是主流的“Synchronizer Token Pattern”方法，另一個是漸成主流的“SameSite Attribute”。

1）SameSite Attribute
這個方式實施和理解比較容易，我們先說。
服務(wù)端利用 cookie 的 SameSite 屬性可以禁止瀏覽器從外部站點發(fā)送請求時帶上 cookie。比如下面的 cookie 就不會被放在由在第三方網(wǎng)頁發(fā)起而目標是銀行網(wǎng)站的請求上。這就自然解決了上面的 CSRF 的問題。SameSite還可設(shè)為Strict。

Set-Cookie: JSESSIONID=randomid; Domain=bank.example.com; Secure; HttpOnly; SameSite=Lax

2）Synchronizer Token Pattern
這個解決辦法的原理是對來自瀏覽器的請求我們都回送一個隨機數(shù)，下次瀏覽器再請求業(yè)務(wù)時需要在 header 里或者表單里帶上這個隨機數(shù)。這個隨機數(shù)就是 csrf token。Spring Security就是采用的這個方式。
這個辦法之所以能防范 CSRF，是因為 sessionId 來自 cookie，而 csrf token 來自 header 或者 form。相當于分別在兩條不同的路徑上傳遞。

Spring Security 模塊生成 csrf token 后可放在兩個地方。Spring 默認的，隨機數(shù)與 sessionId 關(guān)聯(lián)，放在 session 里。另一個方式：隨機數(shù)放在 cookie 里。

a) 基于 Session 保存 csrf token

與 session 關(guān)聯(lián)比較容易理解，下次瀏覽器發(fā)送請求過來，服務(wù)端就可以從 header 或 form 里取出來的 csrf token 與 session 中的隨機數(shù)相比較來進行判斷。

b) 基于 Cookie 保存 csrf token

通過 cookie 保存 csrf 是怎么回事呢？如果 csrf token 通過 cookie 發(fā)送給瀏覽器，那這個隨機數(shù)不就跟 JSESSIONID 一樣了會被瀏覽器自動傳回到服務(wù)器了嗎？
是的，這個通過cookie傳給瀏覽器的 csrf token 一定會被瀏覽器傳回給服務(wù)器，我們也正是利用這一點“保存”了 csrf token。之所以使用基于 cookie 的方式，是因為要針對前后端分離的情形讓前端可以使用 javascript 獲得 csrf token，并把這個 token 作為下次請求的 header 參數(shù)或者 form 參數(shù)傳遞給服務(wù)端。服務(wù)端所要做的就是通過對比來自 cookie 和 header/form 這兩條路徑的 csrf token 來做出該請求是否為CSRF的判斷。

下面代碼設(shè)置使用 cookie 保存csrf token，使用 cookie 傳遞 token 需要把 cookie 的 HttpOnly 屬性設(shè)置為 false，以便讓 javascript 能讀到此值。

@EnableWebSecuritypublic class WebSecurityConfig extends        WebSecurityConfigurerAdapter {
    @Override    protected void configure(HttpSecurity http) {        http            .csrf(csrf -> csrf                .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())            );    }}

關(guān)于如何分析Spring對CSRF的防范就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。