CSRF：跨站點請求偽造

大致原理：

用戶A請求了正常的網(wǎng)站C，之后產(chǎn)生了cookie，之后用戶A又瀏覽的惡意網(wǎng)站B，網(wǎng)站B接收到用戶請求后，返回一些攻擊性代碼，并發(fā)出一個請求要求訪問第三方站點C，惡意網(wǎng)站B產(chǎn)生惡意的請求去請求網(wǎng)站C，結(jié)果C只能看到cookie是正確的，以為就是用戶A的行為，從而產(chǎn)生損失。

CSRF漏洞檢測：

???????檢測CSRF漏洞是一項比較繁瑣的工作，最簡單的方法就是抓取一個正常請求的數(shù)據(jù)包，去掉Referer字段后再重新提交，如果該提交還有效，那么基本上可以確定存在CSRF漏洞。

以CSRFTester工具為例，CSRF漏洞檢測工具的測試原理如下：使用CSRFTester進行測試時，首先需要抓取我們在瀏覽器中訪問過的所有鏈接以及所有的表單等信息，然后通過在CSRFTester中修改相應的表單等信息，重新提交，這相當于一次偽造客戶端請求。如果修改后的測試請求成功被網(wǎng)站服務器接受，則說明存在CSRF漏洞，當然此款工具也可以被用來進行CSRF攻擊。

???????目前防御 CSRF 攻擊主要有三種策略：驗證 HTTP Referer 字段；在請求地址中添加 token 并驗證；在 HTTP 頭中自定義屬性并驗證。

1）驗證HTTP Referer字段

Referer字段記錄了HTTP請求的來源地址

好處：簡單易行，不需要操心crsf漏洞，只需要對安全性要求比較高的請求統(tǒng)一增加一個攔截器，檢查referer的值。

問題：1.referer是由瀏覽器提供的，每個瀏覽器對referer的實現(xiàn)可能有差別，并不保證瀏覽器不存在安全漏洞。事實上對于一些瀏覽器比如 ie6或者ff2，就可以修改referer的值，如果網(wǎng)站支持這些瀏覽器，黑客就可以篡改這個字段，從而達到csrf攻擊的效果。2.就算有些瀏覽器不能篡改，但是一些用戶會認為這是侵犯了隱私，有些組織也擔心會把內(nèi)網(wǎng)的信息泄露到外網(wǎng)去，就會設置瀏覽器在發(fā)送請求的時候不再提供referer，這樣會被誤認為是csrf，拒絕了合理用戶的請求。

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

要防御，就是需要在請求中添加請求者無法偽造的信息?？梢栽贖TTP請求中以參數(shù)的形式加入一個隨機產(chǎn)生的token。服務器來攔截驗證這個token，如果不存在或者錯誤，則認為很可能是csrf。

token可以放入session傳入服務器，每次請求的時候再從session中拿出來比較，與請求中的token進行比較。

通常使用的方法就是在每次頁面加載時，使用 javascript 遍歷整個 dom 樹，對于 dom 中所有的 a 和 form 標簽后加入 token。這樣可以解決大部分的請求，但是對于在頁面加載之后動態(tài)生成的 html 代碼，這種方法就沒有作用，還需要程序員在編碼時手動添加 token。

問題：難以保證 token 本身的安全。1。黑客發(fā)在那些允許發(fā)表自己內(nèi)容的網(wǎng)站，這個鏈接也許會被加上token，黑客就可以進行攻擊。解決辦法是加上一個判斷，如果網(wǎng)站上的鏈接是鏈接到自己網(wǎng)站的就加上token，如果是鏈接到外網(wǎng)的就不需要加上。2.不過，即使這個 csrftoken 不以參數(shù)的形式附加在請求之中，黑客的網(wǎng)站也同樣可以通過 Referer 來得到這個 token 值以發(fā)動 CSRF 攻擊。這也是一些用戶喜歡手動關(guān)閉瀏覽器 Referer 功能的原因。

3）在http頭中自定義屬性并進行驗證

通過 XMLHttpRequest 這個類，可以一次性給所有該類請求加上 csrftoken 這個 HTTP 頭屬性，并把 token 值放入其中。

好處：1）解決了上種方法在請求中加入 token 的不便2）通過 XMLHttpRequest 請求的地址不會被記錄到瀏覽器的地址欄，也不用擔心 token 會透過 Referer 泄露到其他網(wǎng)站中去。

問題：1）并非所有請求都適應。2）這類請求得到的頁面瀏覽器無法記錄，不能前進后退，給用戶帶來不便。3）對于沒有進行 CSRF 防護的遺留系統(tǒng)來說，要采用這種方法來進行防護，要把所有請求都改為 XMLHttpRequest 請求，這樣幾乎是要重寫整個網(wǎng)站，這代價無疑是不能接受的。