一、什么是CSRF攻擊

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

二、CSRF攻擊的流程

CSRF攻擊原理過程如下：

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

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

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

三、常見的CSRF攻擊

1、GET類型的CSRF

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

2、POST類型的CSRF

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

四、CSRF測試

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

五、預防CSRF攻擊

5.1、驗證HTTP Referer字段

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

驗證Referer方式總計：

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

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

5.2、添加token驗證

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

添加token方式總結：

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

5.3、在HTTP頭中自定義屬性并驗證

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

驗證head方式總結：

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

2、使用地方局限。

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

總結

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

最新評論