一、什么是CSRF攻擊

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

二、CSRF攻擊的流程

CSRF攻擊原理過(guò)程如下：

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

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

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

三、常見的CSRF攻擊

1、GET類型的CSRF

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

2、POST類型的CSRF

這種類型的CSRF危害沒(méi)有GET類型的大，利用起來(lái)通常使用的是一個(gè)自動(dòng)提交的表單，如
<form action=http://wooyun.org/csrf.php method=POST>
    <input type="text" name="xx" value="11" />
</form>
<script> document.forms[0].submit(); </script> 
訪問(wèn)該頁(yè)面后，表單會(huì)自動(dòng)提交，相當(dāng)于模擬用戶完成一次POSt操作。

四、CSRF測(cè)試

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

五、預(yù)防CSRF攻擊

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

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

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

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

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

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

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

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

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

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

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

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

1、使用方式簡(jiǎn)單，不容易泄漏

2、使用地方局限。

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

總結(jié)

到此這篇關(guān)于如何防范CSRF攻擊的文章就介紹到這了,更多相關(guān)防范CSRF攻擊內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論