什么是CSRF攻擊？

跨站請(qǐng)求偽造(Cross-Site Request Forgery, CSRF)，惡意網(wǎng)站通過(guò)腳本向當(dāng)前用戶(hù)瀏覽器打開(kāi)的其它頁(yè)面的 URL 發(fā)起惡意請(qǐng)求，由于同一瀏覽器進(jìn)程下 Cookie 可見(jiàn)性，導(dǎo)致用戶(hù)身份被盜用，完成惡意網(wǎng)站腳本中指定的操作。

盡管聽(tīng)起來(lái)跟XSS跨站腳本攻擊有點(diǎn)相似，但事實(shí)上CSRF與XSS差別很大，XSS利用的是站點(diǎn)內(nèi)的信任用戶(hù)，而CSRF則是通過(guò)偽裝來(lái)自受信任用戶(hù)的請(qǐng)求來(lái)利用受信任的網(wǎng)站。

你可以這么理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義向第三方網(wǎng)站發(fā)送惡意請(qǐng)求。CRSF能做的事情包括利用你的身份發(fā)郵件、發(fā)短信、進(jìn)行交易轉(zhuǎn)賬等，甚至盜取你的賬號(hào)。

CSRF攻擊原理

CSRF的攻擊原理如下圖所示。

首先用戶(hù)C瀏覽并登錄了受信任站點(diǎn)A；

登錄信息驗(yàn)證通過(guò)以后，站點(diǎn)A會(huì)在返回給瀏覽器的信息中帶上已登錄的cookie，cookie信息會(huì)在瀏覽器端保存一定時(shí)間（根據(jù)服務(wù)端設(shè)置而定）；

完成這一步以后，用戶(hù)在沒(méi)有登出（清除站點(diǎn)A的cookie）站點(diǎn)A的情況下，訪(fǎng)問(wèn)惡意站點(diǎn)B；

這時(shí)惡意站點(diǎn) B的某個(gè)頁(yè)面向站點(diǎn)A發(fā)起請(qǐng)求，而這個(gè)請(qǐng)求會(huì)帶上瀏覽器端所保存的站點(diǎn)A的cookie；

站點(diǎn)A根據(jù)請(qǐng)求所帶的cookie，判斷此請(qǐng)求為用戶(hù)C所發(fā)送的。

因此，站點(diǎn)A會(huì)報(bào)據(jù)用戶(hù)C的權(quán)限來(lái)處理惡意站點(diǎn)B所發(fā)起的請(qǐng)求，而這個(gè)請(qǐng)求可能以用戶(hù)C的身份發(fā)送 郵件、短信、消息，以及進(jìn)行轉(zhuǎn)賬支付等操作，這樣惡意站點(diǎn)B就達(dá)到了偽造用戶(hù)C請(qǐng)求站點(diǎn) A的目的。

「受害者只需要做下面兩件事情，攻擊者就能夠完成CSRF攻擊：」

登錄受信任站點(diǎn) A，并在本地生成cookie；

在不登出站點(diǎn)A（清除站點(diǎn)A的cookie）的情況下，訪(fǎng)問(wèn)惡意站點(diǎn)B。

很多情況下所謂的惡意站點(diǎn)，很有可能是一個(gè)存在其他漏洞（如XSS）的受信任且被很多人訪(fǎng)問(wèn)的站點(diǎn)，這樣，普通用戶(hù)可能在不知不覺(jué)中便成為了受害者。

CSRF防御

盡量使用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è)面做，這樣就增加暴露的可能性。

瀏覽器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。

加驗(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)證碼只能作為一種輔助手段，不能作為主要解決方案。

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ā)生，倒是一種可行的方法。

Anti CSRF Token

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

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

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

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

用戶(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的防御方案予以解決。
　　
責(zé)任編輯：中山網(wǎng)站建設(shè)
     【網(wǎng)訊網(wǎng)絡(luò)】國(guó)家高新技術(shù)企業(yè)》十二年專(zhuān)注軟件開(kāi)發(fā)，網(wǎng)站建設(shè)，網(wǎng)頁(yè)設(shè)計(jì)，APP開(kāi)發(fā)，小程序，微信公眾號(hào)開(kāi)發(fā)，定制各類(lèi)企業(yè)管理軟件（OA、CRM、ERP、OMS訂單管理系統(tǒng)、WMS進(jìn)銷(xiāo)存管理軟件等)！服務(wù)熱線(xiàn)：0760-88610046、13924923903，http://www.denorpool.com