CSRF攻擊

CSRF攻擊是什麼

CSRF是跨站請求僞造的縮寫，也被稱爲XSRF， 是一種挾制用戶在當前已登陸的Web應用程序上執行非本意的操做的攻擊方法。
跟跨網站腳本（XSS）相比，XSS利用的是用戶對指定網站的信任，CSRF利用的是網站對用戶網頁瀏覽器的信任。
由於CSRF攻擊利用的是衝着瀏覽器分不清發起請求是否是真正的用戶本人。，也就是說，簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求自己是用戶自願發出的。

CSRF攻擊基本原理

最簡單的CSRF攻擊

1. 用戶Alice登陸和訪問某銀行網站A，保留cookie。
2. Alice被某些信息誘導訪問危險網站B。
3. 危險網站B上有一個<img>標籤：<img src="http://www.examplebank.com/account=Alice&amount=1000&payfor=Badman" >
4. 這個標籤的src不指向一張圖片，而是一個http請求，這個請求向銀行要求將Alice的1000元轉給Badman，因爲Alice的瀏覽器上有cookie，這樣瀏覽器發出的這個請求就能獲得響應執行。
5. 這樣Alice的錢就被偷了。

進階攻擊

危險網站能夠僞造一個表單並隱藏，並在本身網站的onload事件中，觸發這個表單的提交事件，就能夠改GET攻擊爲POST攻擊

CSRF攻擊的對象與防範思路

咱們要防範它，先要知道它的目標，而後設法保護這些目標。
咱們要明白，僅僅靠發起CSRF攻擊的話，黑客只能藉助受害者的cookie騙取服務器的信任，可是黑客並不能憑藉拿到cookie，也看不到 cookie的內容。另外，對於服務器返回的結果，因爲瀏覽器同源策略的限制，黑客也沒法進行解析。
這就告訴咱們，咱們要保護的對象是那些能夠直接產生數據改變的服務，而對於讀取數據的服務，則不須要進行CSRF的保護。
而保護的關鍵，是在請求中放入黑客所不能僞造的信息。

防範手段

最基本的手段：涉及敏感操做的請求改成POST請求

這個方法的確能夠防範一些CSRF攻擊，可是對於進階攻擊就無能爲力了——POST請求同樣能夠僞造。
因此這個方法不夠安全。只能提升攻擊的門檻。

通常手段

用戶操做限制——驗證碼機制

方法：添加驗證碼來識別是否是用戶主動去發起這個請求，因爲必定強度的驗證碼機器沒法識別，所以危險網站不能僞造一個完整的請求。
優勢：簡單粗暴，低成本，可靠，能防範99.99%的攻擊者。
缺點：對用戶不友好。

請求來源限制——驗證 HTTP Referer 字段

方法：在HTTP請求頭中有一個字段叫Referer，它記錄了請求的來源地址。 服務器須要作的是驗證這個來源地址是否合法，若是是來自一些不受信任的網站，則拒絕響應。
優勢：零成本，簡單易實現。
缺點：因爲這個方法嚴重依賴瀏覽器自身，所以安全性全看瀏覽器。

1. 兼容性很差：每一個瀏覽器對於Referer的具體實現可能有差異。
2. 並不必定可靠：在一些古老的垃圾瀏覽器中，Referer能夠被篡改。
3. 對用戶不友好：Referer值會記錄下用戶的訪問來源，有些用戶認爲這樣會侵犯到他們本身的隱私權。所以有些用戶可能會開啓瀏覽器防止跟蹤功能，不提供Referer，從而致使正經常使用戶請求被拒絕。

額外驗證機制——token的使用

方法：使用token來代替驗證碼驗證。因爲黑客並不能拿到和看到cookie裏的內容，因此沒法僞造一個完整的請求。基本思路以下：

1. 服務器隨機產生token（好比把cookie hash化生成），存在session中，放在cookie中或者以ajax的形式交給前端。
2. 前端發請求的時候，解析cookie中的token，放到請求url裏或者請求頭中。
3. 服務器驗證token，因爲黑客沒法獲得或者僞造token，因此能防範csrf

更進一步的增強手段（不須要session）：

1. 服務器隨機產生token，而後以token爲密鑰散列生成一段密文
2. 把token和密文都隨cookie交給前端
3. 前端發起請求時把密文和token都交給後端
4. 後端對token和密文進行正向散列驗證，看token能不能生成一樣的密文
5. 這樣即便黑客拿到了token 也沒法拿到密文。

優勢：

1. 安全性：極大地提升了破解成本（固然仍是有辦法破解），可是99%的攻擊者看到散列的時候就已經望而生畏了。
2. 易用性：很是容易實現。
3. 友好性：對用戶來講十分友好。

缺點：

1. 性能擔心：須要hash計算，增長性能上的成本
2. cookie臃腫：更加依賴網絡的狀況
3. 並不絕對安全：
   1. 一些論壇之類支持用戶本身發表內容，因爲系統也會在這個地址後面加上token，這樣黑客能夠在本身的網站上獲得這個 token，並立刻就能夠發動CSRF攻擊。（進一步增強法能夠防範，或者驗證連接是不是鏈到本身本站的，是就在後面添加 token，若是是通向外網則不加）
   2. 其餘攻擊方式如XSS攻擊能拿到cookie和token，固然這不在本文的討論範圍以內。
4. 對於POST請求，難以將token附在請求中。（能夠經過框架和庫解決）

曲線救國——在HTTP頭中自定義屬性並驗證

方法：這種方法也是使用token並進行驗證，和上一種方法不一樣的是把它放到HTTP頭中自定義的屬性裏。

優勢：

1. 這樣解決了上種方法在請求中加入 token 的不便
2. 經過 XMLHttpRequest 請求的地址不會被記錄到瀏覽器的地址欄，安全性較高

缺點：

1. 侷限性很是大：XMLHttpRequest請求一般用於Ajax，並不是全部的請求都適合用這個類來發起，並且經過該類請求獲得的頁面不能被瀏覽器所記錄下，形成不便。
2. 對於舊網站，要把全部請求都改成XMLHttpRequest請求，這樣幾乎是要重寫整個網站，這代價無疑是不能接受的。

總結

由於CSRF攻擊利用的是衝着瀏覽器分不清發起請求是否是真正的用戶本人，因此防範的關鍵在於在請求中放入黑客所不能僞造的信息。從而防止黑客僞造一個完整的請求欺騙服務器。

原文連接：https://www.imooc.com/article/13552