CSRF 背景與介紹

CSRF定義： 跨站請求偽造（英語：Cross-site request forgery），也被稱為 one-click attack 或者 session riding，通常縮寫為 CSRF 或者 XSRF， 是一種挾制用戶在當前已登錄的Web應用程序上執行非本意的操作的攻擊方法。

簡單地說，是攻擊者通過一些技術手段欺騙用戶的瀏覽器去訪問一個自己曾經認證過的網站并執行一些操作（如發郵件，發消息，甚至財產操作如轉賬和購買商品）。由于瀏覽器曾經認證過，所以被訪問的網站會認為是真正的用戶操作而去執行。這利用了web中用戶身份驗證的一個漏洞：簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求本身是用戶自愿發出的。

CSRF地位：是一種網絡攻擊方式，是互聯網重大安全隱患之一，NYTimes.com（紐約時報）、Metafilter，YouTube、Gmail和百度HI都受到過此類攻擊。

對比XSS：跟跨網站腳本（XSS）相比，XSS 利用的是用戶對指定網站的信任，CSRF 利用的是網站對用戶網頁瀏覽器的信任。

CSRF 攻擊實例

daguanren（大官人）在銀行有一筆存款，輸入用戶名密碼登錄銀行網銀后發送請求進行個人名下賬戶轉賬 ：

http://www.bank.example/withdraw?account=daguanren1amount=999for=daguanren2

將daguanren1中的999塊轉到了daguanren2賬號中。通常用戶登錄后，系統會保存用戶登錄的session值（可能是用戶手機號、賬號等）。但如果這時daguanren不小心新開一個tab頁面進入了一個黑客jinlian（金蓮）的網站，而金蓮網站的頁面中嵌有如下html標簽：

!DOCTYPE html>
html>
  !--其他頁面元素-->

  img src=http://www.bank.example/withdraw?account=daguanren1amount=888for=jinlian width='0' height='0'>

  !--其他頁面元素-->
/html>

這個請求就會附帶上daguanren的session值，成功將大官人的888元轉至jinlian的賬戶上。但如果daguanren之前沒有登錄網銀，而是直接打開jinlian的網站，則由于沒有session值，不會被攻擊。以上示例雖然是get請求，post請求提交的表單同樣會被攻擊。

iframe style="display:none" name="csrf-frame">/iframe>
form method='POST' action='http://www.bank.example/withdraw' target="csrf-frame" id="csrf-form">
 input type='hidden' name='account' value='daguanren1'>
 input type='hidden' name='amount' value='888'>
 input type='hidden' name='for' value='jinlian'>
 input type='submit' value='submit'>
/form>
script>document.getElementById("csrf-form").submit()/script>

所以要被CSRF攻擊，必須同時滿足兩個條件：
1.登錄受信任網站A，并在本地生成Cookie。
2.在不登出A的情況下，訪問危險網站B。

CSRF 攻擊的對象

在討論如何抵御 CSRF 之前，先要明確 CSRF 攻擊的對象，也就是要保護的對象。從以上的例子可知，CSRF 攻擊是黑客借助受害者的 cookie（session） 騙取服務器的信任，但是黑客并不能拿到 cookie，也看不到 cookie 的內容。另外，對于服務器返回的結果，由于瀏覽器同源策略的限制，黑客也無法進行解析。因此，黑客無法從返回的結果中得到任何東西，他所能做的就是給服務器發送請求，以執行請求中所描述的命令，在服務器端直接改變數據的值，而非竊取服務器中的數據。所以，我們要保護的對象是那些可以直接產生數據改變的服務，而對于讀取數據的服務，則不需要進行 CSRF 的保護。比如銀行系統中轉賬的請求會直接改變賬戶的金額，會遭到 CSRF 攻擊，需要保護。而查詢余額是對金額的讀取操作，不會改變數據，CSRF 攻擊無法解析服務器返回的結果，無需保護。

故：增刪改需要防范CSRF攻擊，而讀無需防范。

當前防御 CSRF 的幾種策略

在業界目前防御 CSRF 攻擊主要有四種策略：
- 驗證 HTTP Referer 字段；
- 在請求地址中添加 token 并驗證；
- 在 HTTP 頭中自定義屬性并驗證；
- Chrome瀏覽器端啟用SameSite cookie

1、驗證 HTTP Referer 字段

什么是HTTP Referer？下面GIF圖是由百度跳轉到QQ郵箱頁面的Referer查看示意：

可以看出Referer為

Referer：https://www.baidu.com/

根據 HTTP 協議，在 HTTP 頭（request 的 header）中有一個字段叫 Referer，它記錄了該 HTTP 請求的來源地址。如果黑客要對銀行網站實施 CSRF 攻擊，當用戶通過黑客的網站發送請求到銀行時，該請求的 Referer 值是指向黑客的網站而不是用戶的網站。因此，要防御 CSRF 攻擊，銀行網站只需要對于每一個轉賬請求驗證其 Referer 值，如果是以 www.bank.example開頭的域名，則說明該請求是來自銀行網站自己的請求，是合法的。如果 Referer 是其他網站的話，則有可能是黑客的 CSRF 攻擊，拒絕該請求。

這種方法的顯而易見的好處就是簡單易行，網站的普通開發人員不需要操心 CSRF 的漏洞，只需要在最后給所有安全敏感的請求統一增加一個攔截器來檢查 Referer 的值就可以。特別是對于當前現有的系統，不需要改變當前系統的任何已有代碼和邏輯。

然而，這種方法并非萬無一失。Referer 的值是由瀏覽器提供的，雖然 HTTP 協議上有明確的要求，但是每個瀏覽器對于 Referer 的具體實現可能有差別，并不能保證瀏覽器自身沒有安全漏洞。使用驗證 Referer 值的方法，就是把安全性都依賴于第三方（即瀏覽器）來保障，從理論上來講，這樣并不安全。事實上，對于某些瀏覽器，比如 IE6 或 FF2，目前已經有一些方法可以篡改 Referer 值。如果 www.bank.example網站支持 IE6 瀏覽器，黑客完全可以把用戶瀏覽器的 Referer 值設為以 www.bank.example域名開頭的地址，這樣就可以通過驗證，從而進行 CSRF 攻擊。

即便是使用最新的瀏覽器，黑客無法篡改 Referer 值，這種方法仍然有問題。因為 Referer 值會記錄下用戶的訪問來源，有些用戶認為這樣會侵犯到他們自己的隱私權，特別是有些組織擔心 Referer 值會把組織內網中的某些信息泄露到外網中。因此，用戶自己可以設置瀏覽器使其在發送請求時不再提供 Referer。當他們正常訪問銀行網站時，網站會因為請求沒有 Referer 值而認為是 CSRF 攻擊，拒絕合法用戶的訪問。

另外，如果Referer的判斷邏輯寫的不嚴密的話，也容易被攻破，例如

const referer = request.headers.referer;
if (referer.indexOf('www.bank.example') > -1) {
 // pass
}

如果黑客的網站是www.bank.example.hack.com，則referer檢查無效。

2、在請求地址中添加 token 并驗證

CSRF 攻擊之所以能夠成功，是因為黑客可以完全偽造用戶的請求，該請求中所有的用戶驗證信息都是存在于 cookie 中，因此黑客可以在不知道這些驗證信息的情況下直接利用用戶的 cookie 來通過安全驗證。要抵御 CSRF，關鍵在于在請求中放入黑客所不能偽造的信息，并且該信息不存在于 cookie 之中。可以在 HTTP 請求中以參數的形式加入一個隨機產生的 token，并在服務器端建立一個攔截器來驗證這個 token，如果請求中沒有 token 或者 token 內容不正確，則認為可能是 CSRF 攻擊而拒絕該請求。

這種方法要比檢查 Referer 要安全一些，token 可以在用戶登陸后產生并放于 session 之中，然后在每次請求時把 token 從 session 中拿出，與請求中的 token 進行比對，但這種方法的難點在于如何把 token 以參數的形式加入請求。對于 GET 請求，token 將附在請求地址之后，這樣 URL 就變成

http://url?csrftoken=tokenvalue

而對于 POST 請求來說，要在 form 的最后加上

 input type="hidden" name="csrftoken" value="tokenvalue"/>

該方法有一個缺點是難以保證 token 本身的安全。特別是在一些論壇之類支持用戶自己發表內容的網站，黑客可以在上面發布自己個人網站的地址。由于系統也會在這個地址后面加上 token，黑客可以在自己的網站上得到這個 token，并馬上就可以發動 CSRF 攻擊。為了避免這一點，系統可以在添加 token 的時候增加一個判斷，如果這個鏈接是鏈到自己本站的，就在后面添加 token，如果是通向外網則不加。不過，即使這個 csrftoken 不以參數的形式附加在請求之中，黑客的網站也同樣可以通過 Referer 來得到這個 token 值以發動 CSRF 攻擊。這也是一些用戶喜歡手動關閉瀏覽器 Referer 功能的原因。

3、在 HTTP 頭中自定義屬性并驗證

這種方法也是使用 token 并進行驗證，和上一種方法不同的是，這里并不是把 token 以參數的形式置于 HTTP 請求之中，而是把它放到 HTTP 頭中自定義的屬性里。通過 XMLHttpRequest 這個類，可以一次性給所有該類請求加上 csrftoken 這個 HTTP 頭屬性，并把 token 值放入其中。這樣解決了上種方法在請求中加入 token 的不便，同時，通過 XMLHttpRequest 請求的地址不會被記錄到瀏覽器的地址欄，也不用擔心 token 會透過 Referer 泄露到其他網站中去。

然而這種方法的局限性非常大。XMLHttpRequest 請求通常用于 Ajax 方法中對于頁面局部的異步刷新，并非所有的請求都適合用這個類來發起，而且通過該類請求得到的頁面不能被瀏覽器所記錄下，從而進行前進，后退，刷新，收藏等操作，給用戶帶來不便。另外，對于沒有進行 CSRF 防護的遺留系統來說，要采用這種方法來進行防護，要把所有請求都改為 XMLHttpRequest 請求，這樣幾乎是要重寫整個網站，這代價無疑是不能接受的。

4、Chrome瀏覽器端啟用SameSite cookie

下面介紹如何啟用SameSite cookie的設置，很簡單。

原本的 Cookie 的 header 設置是長這樣：

Set-Cookie: session_id=esadfas325

需要在尾部增加 SameSite 就好：

Set-Cookie: session_id=esdfas32e5; SameSite

SameSite 有兩種模式，Lax跟Strict模式，默認啟用Strict模式，可以自己指定模式：

Set-Cookie: session_id=esdfas32e5; SameSite=StrictSet-Cookie: foo=bar; SameSite=Lax

Strict模式規定 cookie 只允許相同的site使用，不應該在任何的 cross site request 被加上去。即a標簽、form表單和XMLHttpRequest提交的內容，只要是提交到不同的site去，就不會帶上cookie。

但也存在不便，例如朋友發送過來我已經登陸過的一個頁面鏈接，我點開后，該頁面仍然需要重新登錄。

有兩種處理辦法，第一種是與Amazon一樣，準備兩組不同的cookie，第一組用于維持登錄狀態不設定SameSite，第二組針對的是一些敏感操作會用到（例如購買、支付、設定賬戶等）嚴格設定SameSite。

基于這個思路，就產生了 SameSite 的另一一種模式：Lax模式。

Lax 模式打開了一些限制，例如

a>
link rel="prerender">
form method="GET">

這些都會帶上cookie。但是 POST 方法 的 form，或是只要是 POST, PUT, DELETE 這些方法，就不會帶cookie。
但一定注意將重要的請求方式改成POST，否則GET仍然會被攻擊。
PS：該方式目前僅Chrome支持。

后記

方式1通過驗證HTTP Referer頭信息來防止跨站請求偽造csrf，在java中可以通過filter來實現。方式2和方式3都是通過在請求中添加token來進行安全校驗的，spring security 提供的csrf防護就是采用這樣的方式，而且從spring security 4.0開始csrf防護是默認開啟的。對于一個新項目，可以幾種方式都用上，這樣更加安全。如果是一個已經完備的web程序，還是使用方式1修改起來方便，不然每個請求都加上csrfToken改動很大。關于spring security csrf可參考我的博文：https://www.jb51.net/article/157547.htm

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家