淺談對CSRF的認識，以及一些應對措施

CSRF

CSRF（Cross Site Request Forgery, 跨站域請求僞造）的定義，相信你們都不陌生。它是指攻擊者經過誘導用戶，打開已精心設計好的頁面後，發送請求到某個網站執行某個操做(修改數據)的過程。這裏有如下三個前提：

一、用戶已登陸某可信網站(A站，如下所提到的A站都指這裏的某可信網站)

二、A站存在某個請求，能夠修改或保存信息(例如：/saveinfo)

三、用戶在A站Session過時前打開攻擊者設計好的的頁面，並自動或觸發發送請求(/saveinfo)

看起來要求聽苛刻的，但的確存在這種狀況。「即使是大名鼎鼎的 Gmail, 在 2007 年末也存在着 CSRF 漏洞，從而被黑客攻擊而使 Gmail 的用戶形成巨大的損失。」

想要了解怎麼應對CSRF，先來看看攻擊者幹些什麼。

攻擊者能幹什麼

由於受同源策略限制，攻擊者並不能拿到A站的任何信息（Cookies）和響應信息，他只能利用發送請求時，會帶上cookies去校驗登陸信息或權限的特性，去修改用戶的數據，來達到攻擊目的。所以，通常用於獲取信息而不涉及到修改信息的請求(Get)就不用擔憂會有CSRF危險了，重要的是能修改信息的請求。固然，若是你用Get去修改信息，那就須要考慮防範CSRF了。but這樣作自己就違背了HTTP method設定的初衷，同時Get的攻擊方式更爲簡單，一個Img標籤加上JavaScript就能觸發。因此不建議這麼作

CRSF預防措施

正所謂兵來將擋，水來土掩。瞭解了攻擊者利用的一些原理，就對應的能夠找到一些對應措施

一、在服務端驗證HTTP的Referer字段。

此方法成本較小，只須要在服務端攔截請求，判斷Referer是否來自於同一域名，若是不是或者不存在CSRF的話，則認爲有多是CSRF攻擊，直接過濾。但這種方法也有弊端，那就是當有些人會擔憂Referer會泄露我的信息時（畢竟像服務器發送了本身的來源地址）。這些人會嘗試去關閉Referer。這樣當這些用戶發起請求時就不會帶上Referer，這個請求就會被判成有可能的CSRF攻擊，由於按照上述過濾規則，請求頭中無Referer的有可能會是CSRF攻擊。

二、在請求地址中添加 token 並驗證

此方法的核心思想就是，構形成什麼樣的信息，來辨別請求是從用戶手中發出，仍是被攻擊者利用而發出的，很顯然Cookie不能作到，由於用戶和攻擊者都能將一樣的Cookie帶到服務器上。

答案就是token(令牌)，它由服務端經過必定算法生成，每當用戶請求頁面的時候，則向用戶返回的頁面中帶上一個全新的token。下次用戶在發送請求的時候，就帶上該token與服務器的token進行對比。但這token要放在哪裏呢？

三種狀況：
1 對於Get請求，在Url後面動態加上token。 此方法也有必定約束，頁面有不少連接，一個一個加太麻煩，就須要在document加載完之後，經過js來輔助完成了。但這個方法對於動態生成的內容，就無能爲力了。

2 Post請求 在form錶帶中加上
<pre>< input type=」hidden」 name=token value=」tokenvalue」/></pre>

（查看PC淘寶的我的中心，其修改資料就是用的此方法）因爲同源策略，攻擊者是拿不到表單裏的數據的。此方法也跟Get請求有一樣的問題，那就是對於多連接和動態生成的內容，js批量加上token的辦法就不行了，只能手動添加。

三、對於Ajax請求，若是跨域，則默認不會帶上A站的cookie。所以，從某些方面來講，是相對安全的。可是根據w3c對Ajax的一個屬性的描述

4.6.4 The withCredentials attribute

client . withCredentials

True when user credentials are to be included in a cross-origin request. False when they are to be excluded in a cross-origin request and when cookies are to be ignored in its response. Initially false.

大概說的意思是，若是withCredentials爲true，則存在跨域請求的時候，用戶的credentials(包括cookie，我是這麼理解的，若有錯歡迎指正)會被帶上。

若是將withCredentials設爲true，這樣也會存在上述的安全問題，由於Cookies在發送請求的同時也被戴上了。

總結

一、攻擊者是利用用戶登陸過信任網站後，在會話未過時以前誘導用戶打開有問題的網站而達到攻擊目的的

二、常見的防護措施有校驗請求頭的referer，以及新增攻擊者沒法獲取的隨機數token(令牌)來達到防護目的的。

三、token存放的地方有多種，對於POST請求，則構造hideen的input標籤；對於Get則在連接後添加token；對於ajax，則在cookie中添加token。

四、我的以爲相對安全的作法就是既驗證referer，同時也校驗token。如涉及到更隱祕的操做，則須要經過驗證碼或者手動輸入密碼來作防範了。

參考文章：
https://www.w3.org/TR/2014/WD...
https://www.ibm.com/developer...
https://en.wikipedia.org/wiki...

第一次寫Post，過程如此之多，小到markdown語法；大到發現問題、探索分析問題、查閱資料並自測驗證。最後通篇檢查，是否存在有問題的地方。整個過程雖然比較難，但這讓本身對於CRSF有了更深入的認識。在團隊完成分享後竭盡全力整理的一篇，相信之後會更好。