一、什么是CSRF攻擊

CSRF攻擊的全稱為跨站腳本偽造，也稱為One Click Attack或者Session Eiding，通常縮寫為CSRF或者XSRF。CSRF通過偽裝來自受信任的用戶的請求來攻擊受信任的網(wǎng)站。與XSS相比，CSRF攻擊往往不太流行（因此對其進(jìn)行防范的資源也是相當(dāng)緊缺的）和難以防范的，所以被認(rèn)為比XSS更具危險(xiǎn)性。我們可以這么理解CSRF攻擊：首先攻擊者會先盜用你的身份，然后以你的名義進(jìn)行某些非法操作，甚至盜走你的賬戶購買的商品等。CSRF攻擊其值是利用web中用戶身份認(rèn)證驗(yàn)證的一個(gè)漏洞：簡答的身份驗(yàn)證僅僅可以保證請求發(fā)自某一個(gè)用戶的瀏覽器，卻無法保證請求本身是用戶資源發(fā)出的。

二、CSRF攻擊的流程

CSRF攻擊原理過程如下：

1、用戶C打開瀏覽器，訪問安全網(wǎng)站A,輸入用戶名和密碼請求登錄網(wǎng)站A.
2、在用戶信息通過驗(yàn)證后，網(wǎng)站A產(chǎn)生Cookie信息并返回給瀏覽器，此時(shí)用戶登錄A成功，可以正常發(fā)送請求到網(wǎng)站A。
3、用戶沒有退出A之前，在同一個(gè)瀏覽器中，打開一個(gè)Tab頁面來訪問網(wǎng)站B.
4、網(wǎng)站B接收到用戶的請求后，返回一些攻擊代碼，并且發(fā)出一個(gè)請求要求訪問第三方站點(diǎn)A.
5、瀏覽器在接收到這些攻擊性代碼后，根據(jù)網(wǎng)站B的請求，在用戶不知情的情況下攜帶Cookie信息，向網(wǎng)站A發(fā)出請求。網(wǎng)站A并不知道該請求其實(shí)是由B發(fā)出的，所以會根據(jù)用戶C的cookie信息以C的權(quán)限處理該請求，導(dǎo)致來自網(wǎng)站B的惡意代碼被執(zhí)行。

從上述的流程可以看出，想要達(dá)成CSRF攻擊，必須達(dá)成兩個(gè)基本條件。

1、登錄受信任網(wǎng)站A，并且在本地生成Cookie。
2、在不退出登錄網(wǎng)站A的前提下，訪問危險(xiǎn)網(wǎng)站B.

三、常見的CSRF攻擊

1、GET類型的CSRF

銀行站點(diǎn)A: 它以GET請求的方式來完畢銀行轉(zhuǎn)賬的工作：如http://www.mybank.com.Transfer.php?toBankId=11&money=1000
危險(xiǎn)站點(diǎn)B:其中存在一段html代碼為
首先你登錄了銀行站點(diǎn)A，然后訪問危險(xiǎn)站點(diǎn)B,這時(shí)你就會發(fā)現(xiàn)自己的銀行賬號少了1000元。為什么會這樣呢？原因是銀行站點(diǎn)A違反了HTTP規(guī)范，使用GET請求更新資源。在訪問危急站點(diǎn)B的之前，你已經(jīng)登錄了銀行站點(diǎn)A，而B中的 一個(gè)合法的請求，但這里被不法分子利用了）。所以你的瀏覽器會帶上你的銀行站點(diǎn)A的Cookie發(fā)出Get請求，去獲取資源以GET的方式請求第三方資源（這里的第三方就是指銀行站點(diǎn)了，原本這是http://www.mybank.com/Transfer.php?toBankId=11&money=1000 ，結(jié)果銀行站點(diǎn)服務(wù)器收到請求后，覺得這是一個(gè)更新資源操作（轉(zhuǎn)賬操作），所以就立馬進(jìn)行轉(zhuǎn)賬操作。

2、POST類型的CSRF

這種類型的CSRF危害沒有GET類型的大，利用起來通常使用的是一個(gè)自動(dòng)提交的表單，如

? ?

?
訪問該頁面后，表單會自動(dòng)提交，相當(dāng)于模擬用戶完成一次POSt操作。

四、CSRF測試

檢測CSRF漏洞是一項(xiàng)比較繁瑣的工作，最簡單的方法就是抓一個(gè)正常請求的數(shù)據(jù)包，去掉Referer字段后再重新提交，如果該提交還有效，那么基本可以確定存在CSRF漏洞。隨著對CSRF漏洞研究的不斷深入，不斷涌現(xiàn)一些專門針對CSRF漏洞進(jìn)行檢測的工具，比如CSRFTester，CSRF Request Builder等，以CSRF Tester工具為例，CSRF漏洞檢測工具的測試原理如下：使用CSRFTester進(jìn)行測試時(shí)，首先需要抓取我們在瀏覽器中訪問過的所有鏈接以及所有的表單等信息，然后通過在CSRFTester中修改相應(yīng)的表單等信息（比如說更改Referer字段的信息），重新提交，這相當(dāng)于一次偽造客戶端請求。如果修改后的測試請求成功被網(wǎng)站服務(wù)器接受，則說明存在CSRF漏洞，當(dāng)然此款工具也可以被用來進(jìn)行CSRF攻擊。

五、預(yù)防CSRF攻擊

5.1、驗(yàn)證HTTP Referer字段

還拿上述的銀行轉(zhuǎn)賬的例子來說，首先我們向銀行站點(diǎn)發(fā)出一個(gè)請求時(shí)，此時(shí)HTTP協(xié)議頭部會攜帶Referer字段，其中包含著請求該站點(diǎn)的域名，此時(shí)如果我們在訪問銀行站點(diǎn)時(shí)并且向銀行發(fā)出請求，此時(shí)攜帶的Referer就是mybank.com，如果此時(shí)我們從存在危險(xiǎn)的網(wǎng)站B向銀行站點(diǎn)發(fā)起請求，此時(shí)的Referer就是危險(xiǎn)網(wǎng)站B的域名。所以我們可以通過判斷Referer來進(jìn)行判斷是否可以執(zhí)行操作。這樣就會很簡單的就防止了CSRF，但是任然存在一些問題，比如說我們通過檢查Referer來判斷域名，這種決策權(quán)在瀏覽器，此時(shí)如果一些瀏覽器對于Referer的值是可改寫的，那么CSRF的攻擊任然有效。還存在一些用戶會禁用Referer字段，此時(shí)就會造成無法請求網(wǎng)站數(shù)據(jù)。

驗(yàn)證Referer方式總計(jì)：

優(yōu)點(diǎn)：使用方便，開發(fā)簡單，一定程度上能預(yù)防CSRF攻擊

缺點(diǎn)：這種機(jī)制完全依托于瀏覽器，Referer字段容易被故意篡改，或者被禁用。

5.2、添加token驗(yàn)證

我們可以當(dāng)用戶請求時(shí)，在安全站點(diǎn)A中生成一個(gè)SessionId，保存在服務(wù)器端，該值可以作為token傳遞給客戶端。客戶端可以設(shè)置一個(gè)隱藏的input框，其中的值為該token，當(dāng)我們進(jìn)行請求時(shí)，就會將該值傳入到站點(diǎn)A的服務(wù)器，此時(shí)在服務(wù)器端就可以進(jìn)行比較生成的token和保存的token是否一樣，如果一樣的話，就表示是從安全站點(diǎn)上發(fā)出的請求，就做出具體的相應(yīng)。在危險(xiǎn)網(wǎng)站B就無法拿到token，所以也就無法進(jìn)行正確的請求了。如果使用的是post請求，我們可以放入隱藏的input框中，如果要是get請求，則我們可以如下寫法。例如https://www.myBank.com?token=XXXXX。那么一個(gè)網(wǎng)站中存在很多請求，此時(shí)我們?nèi)绻恳粋€(gè)都設(shè)置token，則就會顯得非常的笨拙。此時(shí)我們可以遍歷全部的dom，獲取全部的a標(biāo)簽和form標(biāo)簽，進(jìn)行添加就行了。但是如果頁面的DOM是動(dòng)態(tài)生成的，則需要程序員自己編寫代碼將token放入。還存在一個(gè)問題就是：如何才能保證token不被攻擊者截獲。

添加token方式總結(jié)：

• 安全程度比Referer更高
• 實(shí)現(xiàn)方式上稍微復(fù)雜
• 需要保證token存儲的安全性

5.3、在HTTP頭中自定義屬性并驗(yàn)證

這種方法也是保存token,但是其實(shí)和上述不同的是，其在HTTP頭部保存token，我們可以一次性給訪問該網(wǎng)站的請求都加上該自定義字段，但是如何將數(shù)據(jù)存放在HTTP中呢？此時(shí)我們就需要另一個(gè)模塊，XHRHTTPRequest，當(dāng)我們使用該模塊時(shí)，存在另一個(gè)弊端，就是只能是異步請求。其他請求都是無法訪問的。另外，對于沒有進(jìn)行 CSRF防護(hù)的遺留系統(tǒng)來說，要采用這種方法來進(jìn)行防護(hù)，要把所有請求都改為 XMLHttpRequest 請求，這樣幾乎是要重寫整個(gè)網(wǎng)站，這代價(jià)無疑是不能接受的。

驗(yàn)證head方式總結(jié)：

1、使用方式簡單，不容易泄漏

2、使用地方局限。

補(bǔ)充：防火墻的架設(shè)是Web安全的重要保障，企業(yè)級防火墻的架設(shè)應(yīng)當(dāng)有兩級防火墻，Web服務(wù)器和部分應(yīng)用服務(wù)器可以架設(shè)在兩級防火墻之間的DMZ，而數(shù)據(jù)和資源服務(wù)器應(yīng)當(dāng)架設(shè)在第二級防火墻之后。

總結(jié)