目錄：

一、CSRF介紹

二、CSRF攻擊的危害

三、CSRF攻擊原理及過(guò)程

四、CSRF漏洞檢測(cè)

五、CSRF漏洞預(yù)防

六、最后聊聊xss

一、CSRF介紹

CSRF(Cross-site request forgery)

跨站請(qǐng)求偽造，也被稱(chēng)為“OneClick Attack”或者Session Riding，通?？s寫(xiě)為CSRF或者XSRF，是一種對(duì)網(wǎng)站的惡意利用。

 

 

上圖為CSRF攻擊的一個(gè)簡(jiǎn)單模型，用戶(hù)訪問(wèn)惡意網(wǎng)站B，惡意網(wǎng)站B返回給用戶(hù)的HTTP信息中要求用戶(hù)訪問(wèn)網(wǎng)站A，而由于用戶(hù)和網(wǎng)站A之間可能已經(jīng)有信任關(guān)系導(dǎo)致這個(gè)請(qǐng)求就像用戶(hù)真實(shí)發(fā)送的一樣會(huì)被執(zhí)行。

二、CSRF攻擊的危害

攻擊者盜用了你的身份，以你的名義發(fā)送惡意請(qǐng)求，對(duì)服務(wù)器來(lái)說(shuō)這個(gè)請(qǐng)求是完全合法的，但是卻完成了攻擊者所期望的一個(gè)操作，比如以你的名義發(fā)送郵件、發(fā)消息，盜取你的賬號(hào)，添加系統(tǒng)管理員，甚至于購(gòu)買(mǎi)商品、虛擬貨幣轉(zhuǎn)賬等。

如果CSRF發(fā)送的垃圾信息還帶有蠕蟲(chóng)鏈接的話，那些接收到這些有害信息的好友萬(wàn)一打開(kāi)私信中的連接就也成為了有害信息的散播著，這樣數(shù)以萬(wàn)計(jì)的用戶(hù)被竊取了資料種植了木馬。整個(gè)網(wǎng)站的應(yīng)用就可能在瞬間奔潰，用戶(hù)投訴，用戶(hù)流失，公司聲譽(yù)一落千丈甚至面臨倒閉。曾經(jīng)在MSN上，一個(gè)美國(guó)的19歲的小伙子Samy利用css的background漏洞幾小時(shí)內(nèi)讓100多萬(wàn)用戶(hù)成功的感染了他的蠕蟲(chóng)，雖然這個(gè)蠕蟲(chóng)并沒(méi)有破壞整個(gè)應(yīng)用，只是在每一個(gè)用戶(hù)的簽名后面都增加了一句“Samy 是我的偶像”，但是一旦這些漏洞被惡意用戶(hù)利用，后果將不堪設(shè)想，同樣的事情也曾經(jīng)發(fā)生在新浪微博上面。

如下：其中Web A為存在CSRF漏洞的網(wǎng)站，Web B為攻擊者構(gòu)建的惡意網(wǎng)站，User C為Web A網(wǎng)站的合法用戶(hù)。

三、CSRF攻擊原理及過(guò)程

 

 

1 、用戶(hù)C打開(kāi)瀏覽器，訪問(wèn)受信任網(wǎng)站A，輸入用戶(hù)名和密碼請(qǐng)求登錄網(wǎng)站A;

2、在用戶(hù)信息通過(guò)驗(yàn)證后，網(wǎng)站A產(chǎn)生Cookie信息并返回給瀏覽器，此時(shí)用戶(hù)登錄網(wǎng)站A成功，可以正常發(fā)送請(qǐng)求到網(wǎng)站A;

3、用戶(hù)未退出網(wǎng)站A之前，在同一瀏覽器中，打開(kāi)一個(gè)TAB頁(yè)訪問(wèn)網(wǎng)站B;

4、網(wǎng)站B接收到用戶(hù)請(qǐng)求后，返回一些攻擊性代碼，并發(fā)出一個(gè)請(qǐng)求要求訪問(wèn)第三方站點(diǎn)A;

5.、瀏覽器在接收到這些攻擊性代碼后，根據(jù)網(wǎng)站B的請(qǐng)求，在用戶(hù)不知情的情況下攜帶Cookie信息，向網(wǎng)站A發(fā)出請(qǐng)求。網(wǎng)站A并不知道該請(qǐng)求其實(shí)是由B發(fā)起的，所以會(huì)根據(jù)用戶(hù)C的Cookie信息以C的權(quán)限處理該請(qǐng)求，導(dǎo)致來(lái)自網(wǎng)站B的惡意代碼被執(zhí)行。

舉例：

簡(jiǎn)單版：

假如博客園有個(gè)加關(guān)注的GET接口，blogUserGuid參數(shù)很明顯是關(guān)注人Id，如下：

 

 

那我只需要在我的一篇博文內(nèi)容里面寫(xiě)一個(gè)img標(biāo)簽：

 

 

那么只要有人打開(kāi)我這篇博文，那就會(huì)自動(dòng)關(guān)注我。

升級(jí)版：

假如博客園還是有個(gè)加關(guān)注的接口，不過(guò)已經(jīng)限制了只獲取POST請(qǐng)求的數(shù)據(jù)。這個(gè)時(shí)候就做一個(gè)第三方的頁(yè)面，但里面包含form提交代碼，然后通過(guò)QQ、郵箱等社交工具傳播，誘惑用戶(hù)去打開(kāi)，那打開(kāi)過(guò)博客園的用戶(hù)就中招了。

在說(shuō)例子之前要糾正一個(gè)iframe問(wèn)題，有人會(huì)直接在第三方頁(yè)面這樣寫(xiě)。如下：

 

 

這樣是用問(wèn)題的，由于同源策略的原因，iframe內(nèi)容根本加載不出來(lái)，所以里面form提交當(dāng)然不會(huì)執(zhí)行。

PS：我嘗試了chrome、IE11、Firefox，情況都是這樣。

所以可以用嵌多一層頁(yè)面方式解決，如下：

第一個(gè)展示頁(yè)面(test):

 

 

第二個(gè)隱藏頁(yè)面(test2):

 

 

這樣就可以解決了，有人會(huì)問(wèn)為什么要加多一層iframe，因?yàn)椴磺秈frame頁(yè)面會(huì)重定向，這樣就降低了攻擊的隱蔽性。另外我們test頁(yè)面不使用XMLHTTPRequest發(fā)送POST請(qǐng)求，是因?yàn)橛锌缬虻膯?wèn)題，而form可以跨域post數(shù)據(jù)。

進(jìn)階版：

假如博客園還是有個(gè)加關(guān)注的接口，已經(jīng)限制POST，但博文內(nèi)容是直接貼進(jìn)HTML(未過(guò)濾)，那就遭受XSS攻擊。那么就可以直接把上面代碼嵌入博文，那么只要有人打開(kāi)我這篇博文，還是會(huì)自動(dòng)關(guān)注我，這組合攻擊方式稱(chēng)為XSRF。

四、CSRF漏洞檢測(cè)

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

隨著對(duì)CSRF漏洞研究的不斷深入，不斷涌現(xiàn)出一些專(zhuān)門(mén)針對(duì)CSRF漏洞進(jìn)行檢測(cè)的工具，如CSRFTester，CSRF Request Builder。

以CSRFTester工具為例，CSRF漏洞檢測(cè)工具的測(cè)試原理如下：

使用CSRFTester進(jìn)行測(cè)試時(shí)，首先需要抓取我們?cè)跒g覽器中訪問(wèn)過(guò)的所有鏈接以及所有的表單等信息，然后通過(guò)在CSRFTester中修改相應(yīng)的表單等信息，重新提交，這相當(dāng)于一次偽造客戶(hù)端請(qǐng)求。如果修改后的測(cè)試請(qǐng)求成功被網(wǎng)站服務(wù)器接受，則說(shuō)明存在CSRF漏洞，當(dāng)然此款工具也可以被用來(lái)進(jìn)行CSRF攻擊。

五、CSRF漏洞防御

目前防御 CSRF 攻擊主要有三種策略：驗(yàn)證 HTTP Referer 字段;在請(qǐng)求地址中添加 token 并驗(yàn)證;在 HTTP 頭中自定義屬性并驗(yàn)證。

1、盡量使用POST，限制GET

GET接口太容易被拿來(lái)做CSRF攻擊，看第一個(gè)示例就知道，只要構(gòu)造一個(gè)img標(biāo)簽，而img標(biāo)簽又是不能過(guò)濾的數(shù)據(jù)。

接口最好限制為POST使用，GET則無(wú)效，降低攻擊風(fēng)險(xiǎn)。

當(dāng)然POST并不是萬(wàn)無(wú)一失，攻擊者只要構(gòu)造一個(gè)form就可以，但需要在第三方頁(yè)面做，這樣就增加暴露的可能性。

2、瀏覽器Cookie策略

IE6、7、8、Safari會(huì)默認(rèn)攔截第三方本地Cookie(Third-party Cookie)的發(fā)送。

但是Firefox2、3、Opera、Chrome、Android等不會(huì)攔截，所以通過(guò)瀏覽器Cookie策略來(lái)防御CSRF攻擊不靠譜，只能說(shuō)是降低了風(fēng)險(xiǎn)。

PS：Cookie分為兩種

Session Cookie(在瀏覽器關(guān)閉后，就會(huì)失效，保存到內(nèi)存里)，

Third-party Cookie(即只有到了Exprie時(shí)間后才會(huì)失效的Cookie，這種Cookie會(huì)保存到本地)。

PS：另外如果網(wǎng)站返回HTTP頭包含P3P Header，那么將允許瀏覽器發(fā)送第三方Cookie。

3、加驗(yàn)證碼

驗(yàn)證碼，強(qiáng)制用戶(hù)必須與應(yīng)用進(jìn)行交互，才能完成最終請(qǐng)求。在通常情況下，驗(yàn)證碼能很好遏制CSRF攻擊。

但是出于用戶(hù)體驗(yàn)考慮，網(wǎng)站不能給所有的操作都加上驗(yàn)證碼。

因此驗(yàn)證碼只能作為一種輔助手段，不能作為主要解決方案。

4、Referer Check

Referer Check在Web最常見(jiàn)的應(yīng)用就是“防止圖片盜鏈”。

同理，Referer Check也可以被用于檢查請(qǐng)求是否來(lái)自合法的“源”(Referer值是否是指定頁(yè)面，或者網(wǎng)站的域)，如果都不是，那么就極可能是CSRF攻擊。

但是因?yàn)榉?wù)器并不是什么時(shí)候都能取到Referer，所以也無(wú)法作為CSRF防御的主要手段。

但是用Referer Check來(lái)監(jiān)控CSRF攻擊的發(fā)生，倒是一種可行的方法。

5 、Anti CSRF Token

現(xiàn)在業(yè)界對(duì)CSRF的防御，一致的做法是使用一個(gè)Token(Anti CSRF Token)。

例子：

1、用戶(hù)訪問(wèn)某個(gè)表單頁(yè)面。

2、 服務(wù)端生成一個(gè)Token，放在用戶(hù)的Session中，或者瀏覽器的Cookie中。

3、在頁(yè)面表單附帶上Token參數(shù)。

4、用戶(hù)提交請(qǐng)求后， 服務(wù)端驗(yàn)證表單中的Token是否與用戶(hù)Session(或Cookies)中的Token一致，一致為合法請(qǐng)求，不是則非法請(qǐng)求。

這個(gè)Token的值必須是隨機(jī)的，不可預(yù)測(cè)的。由于Token的存在，攻擊者無(wú)法再構(gòu)造一個(gè)帶有合法Token的請(qǐng)求實(shí)施CSRF攻擊。另外使用Token時(shí)應(yīng)注意Token的保密性，盡量把敏感操作由GET改為POST，以form或AJAX形式提交，避免Token泄露。

注意：

CSRF的Token僅僅用于對(duì)抗CSRF攻擊。當(dāng)網(wǎng)站同時(shí)存在XSS漏洞時(shí)候，那這個(gè)方案也是空談。

所以XSS帶來(lái)的問(wèn)題，應(yīng)該使用XSS的防御方案予以解決。

特別是在一些論壇之類(lèi)支持用戶(hù)自己發(fā)表內(nèi)容的網(wǎng)站，黑客可以在上面發(fā)布自己個(gè)人網(wǎng)站的地址。由于系統(tǒng)也會(huì)在這個(gè)地址后面加上 token，黑客可以在自己的網(wǎng)站上得到這個(gè) token，并馬上就可以發(fā)動(dòng) CSRF 攻擊。為了避免這一點(diǎn)，系統(tǒng)可以在添加 token 的時(shí)候增加一個(gè)判斷，如果這個(gè)鏈接是鏈到自己本站的，就在后面添加 token，如果是通向外網(wǎng)則不加。不過(guò)，即使這個(gè) csrftoken 不以參數(shù)的形式附加在請(qǐng)求之中，黑客的網(wǎng)站也同樣可以通過(guò) Referer 來(lái)得到這個(gè) token 值以發(fā)動(dòng) CSRF 攻擊。這也是一些用戶(hù)喜歡手動(dòng)關(guān)閉瀏覽器 Referer 功能的原因。

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

這種方法也是使用 token 并進(jìn)行驗(yàn)證，和上一種方法不同的是，這里并不是把 token 以參數(shù)的形式置于 HTTP 請(qǐng)求之中，而是把它放到 HTTP 頭中自定義的屬性里。通過(guò) XMLHttpRequest 這個(gè)類(lèi)，可以一次性給所有該類(lèi)請(qǐng)求加上 csrftoken 這個(gè) HTTP 頭屬性，并把 token 值放入其中。這樣解決了上種方法在請(qǐng)求中加入 token 的不便，同時(shí)，通過(guò) XMLHttpRequest 請(qǐng)求的地址不會(huì)被記錄到瀏覽器的地址欄，也不用擔(dān)心 token 會(huì)透過(guò) Referer 泄露到其他網(wǎng)站中去。

然而這種方法的局限性非常大。XMLHttpRequest 請(qǐng)求通常用于 Ajax 方法中對(duì)于頁(yè)面局部的異步刷新，并非所有的請(qǐng)求都適合用這個(gè)類(lèi)來(lái)發(fā)起，而且通過(guò)該類(lèi)請(qǐng)求得到的頁(yè)面不能被瀏覽器所記錄下，從而進(jìn)行前進(jìn)，后退，刷新，收藏等操作，給用戶(hù)帶來(lái)不便。另外，對(duì)于沒(méi)有進(jìn)行 CSRF 防護(hù)的遺留系統(tǒng)來(lái)說(shuō)，要采用這種方法來(lái)進(jìn)行防護(hù)，要把所有請(qǐng)求都改為 XMLHttpRequest 請(qǐng)求，這樣幾乎是要重寫(xiě)整個(gè)網(wǎng)站，這代價(jià)無(wú)疑是不能接受的。

六、最后聊聊XSS

惡意攻擊者往Web頁(yè)面里插入惡意Script代碼，當(dāng)用戶(hù)瀏覽該頁(yè)之時(shí)，嵌入其中Web里面的Script代碼會(huì)被執(zhí)行，從而達(dá)到惡意攻擊用戶(hù)的目的。

XSS攻擊分成兩類(lèi)

來(lái)自?xún)?nèi)部的攻擊：

主要指的是利用程序自身的漏洞，構(gòu)造跨站語(yǔ)句，如:dvbbs的showerror.asp存在的跨站漏洞。

來(lái)自外部的攻擊

主要指的自己構(gòu)造XSS跨站漏洞網(wǎng)頁(yè)或者尋找非目標(biāo)機(jī)以外的有跨站漏洞的網(wǎng)頁(yè)。如當(dāng)我們要滲透一個(gè)站點(diǎn)，我們自己構(gòu)造一個(gè)有跨站漏洞的網(wǎng)頁(yè)，然后構(gòu)造跨站語(yǔ)句，通過(guò)結(jié)合其它技術(shù)，如社會(huì)工程學(xué)等，欺騙目標(biāo)服務(wù)器的管理員打開(kāi)。

XSS分為：存儲(chǔ)型和反射型

存儲(chǔ)型XSS：

存儲(chǔ)型XSS，持久化，代碼是存儲(chǔ)在服務(wù)器中的，如在個(gè)人信息或發(fā)表文章等地方，加入代碼，如果沒(méi)有過(guò)濾或過(guò)濾不嚴(yán)，那么這些代碼將儲(chǔ)存到服務(wù)器中，用戶(hù)訪問(wèn)該頁(yè)面的時(shí)候觸發(fā)代碼執(zhí)行。這種XSS比較危險(xiǎn)，容易造成蠕蟲(chóng)，盜竊cookie(雖然還有種DOM型XSS，但是也還是包括在存儲(chǔ)型XSS內(nèi))。

反射型XSS：

非持久化，需要欺騙用戶(hù)自己去點(diǎn)擊鏈接才能觸發(fā)XSS代碼(服務(wù)器中沒(méi)有這樣的頁(yè)面和內(nèi)容)，一般容易出現(xiàn)在搜索頁(yè)面。