一、簡(jiǎn)介

跨站請(qǐng)求偽造攻擊，英文全稱(chēng)是Cross-site request forgery，簡(jiǎn)稱(chēng)為CSRF。

攻擊者誘導(dǎo)用戶(hù)進(jìn)入一個(gè)第三方網(wǎng)站，然后該網(wǎng)站向被攻擊網(wǎng)站發(fā)送跨站請(qǐng)求。如果用戶(hù)在被攻擊網(wǎng)站中保存了登錄狀態(tài)，那么攻擊者就可以利用這個(gè)登錄狀態(tài)，繞過(guò)后臺(tái)的用戶(hù)驗(yàn)證，冒充用戶(hù)向服務(wù)器執(zhí)行一些操作。

CSRF 攻擊的本質(zhì)：本質(zhì)是利用 cookie 會(huì)在同源請(qǐng)求中攜帶發(fā)送給服務(wù)器的特點(diǎn)，以此來(lái)實(shí)現(xiàn)用戶(hù)的冒充。

如何攻擊

從簡(jiǎn)介中我們得知，攻擊者需要誘導(dǎo)用戶(hù)進(jìn)入一個(gè)第三方網(wǎng)站。

• 受害者登錄a.com，并保留了登錄憑證（Cookie）。

• 攻擊者引誘受害者訪(fǎng)問(wèn)了b.com。

• b.com 向 a.com 發(fā)送了一個(gè)請(qǐng)求：a.com/act=xx。瀏覽器會(huì)默認(rèn)攜帶a.com的Cookie。

• a.com接收到請(qǐng)求后，對(duì)請(qǐng)求進(jìn)行驗(yàn)證，并確認(rèn)是受害者的憑證，誤以為是受害者自己發(fā)送的請(qǐng)求。

• a.com以受害者的名義執(zhí)行了act=xx。

• 攻擊完成，攻擊者在受害者不知情的情況下，冒充受害者，讓a.com執(zhí)行了自己定義的操作。

從總結(jié)中可以看出，若想完成CSRF攻擊，要同時(shí)滿(mǎn)足2各條件

1. 登錄成功網(wǎng)站A,并本地產(chǎn)生了Cookie

2. 未退出A網(wǎng)站的同時(shí)，訪(fǎng)問(wèn)危險(xiǎn)的B.com

總結(jié)來(lái)說(shuō)天時(shí)地利人和。

二、CSRF攻擊分類(lèi)

2.1 GET 類(lèi)型的 CSRF

GET 類(lèi)型的 CSRF 利用非常簡(jiǎn)單，只需要一個(gè) HTTP 請(qǐng)求，一般這樣使用

假設(shè)：網(wǎng)站A,銀行賬戶(hù)轉(zhuǎn)行，通過(guò)GET請(qǐng)求來(lái)完成

危險(xiǎn)網(wǎng)站B,其中有一段代碼

<img src="http://mybank.example/transfer?account=ying&for=hacker&money=10000">

若這時(shí)候訪(fǎng)問(wèn)了網(wǎng)站B,黑客將轉(zhuǎn)賬的請(qǐng)求接口隱藏在 img 標(biāo)簽內(nèi)，欺騙瀏覽器這是一張圖片資源。當(dāng)該頁(yè)面被加載時(shí)，瀏覽器會(huì)自動(dòng)發(fā)起 img 的資源請(qǐng)求，如果服務(wù)器沒(méi)有對(duì)該請(qǐng)求做判斷的話(huà)，那么服務(wù)器就會(huì)認(rèn)為該請(qǐng)求是一個(gè)轉(zhuǎn)賬請(qǐng)求，于是用戶(hù)賬戶(hù)上的 10000 就被轉(zhuǎn)移到黑客的賬戶(hù)上去了。

2.2 POST類(lèi)型的 CSRF

還以上面的轉(zhuǎn)賬為例子進(jìn)行說(shuō)明

<form action="http://mybank.example/transfer" method=POST>   
<input type="hidden" name="account" value="ying" />   
<input type="hidden" name="amount" value="10000" />   
<input type="hidden" name="for" value="hacker" /> </form>  
<script>   document.forms[0].submit(); </script>

若訪(fǎng)問(wèn)了該頁(yè)面，表單會(huì)自定提交。相當(dāng)于進(jìn)行了一次POST請(qǐng)求。

POST類(lèi)型的攻擊通常比GET要求更加嚴(yán)格一點(diǎn)，但仍并不復(fù)雜。任何個(gè)人網(wǎng)站、博客，被黑客上傳頁(yè)面的網(wǎng)站都有可能是發(fā)起攻擊的來(lái)源，后端接口不能將安全寄托在僅允許POST上面。

2.3 鏈接類(lèi)型的CSRF

這點(diǎn)通俗來(lái)說(shuō)，就是點(diǎn)擊了危險(xiǎn)網(wǎng)站的鏈接。通常是在論壇中發(fā)布的圖片中嵌入惡意鏈接，或者以廣告的形式誘導(dǎo)用戶(hù)中招。

<a href="http://mybank.example/transfer?account=ying&for=hacker&money=10000" taget="_blank">   驚喜驚喜，快來(lái)領(lǐng)取！！   <a/>

三、防御

3.1 同源檢測(cè)

CSRF大多來(lái)自第三方網(wǎng)站，那么我們就直接禁止外域（或者不受信任的域名）對(duì)我們發(fā)起請(qǐng)求。

在HTTP協(xié)議中，每一個(gè)異步請(qǐng)求都會(huì)攜帶兩個(gè)Header，用于標(biāo)記來(lái)源域名：

• Origin Header

• Referer Header

這兩個(gè)Header在瀏覽器發(fā)起請(qǐng)求時(shí)，大多數(shù)情況會(huì)自動(dòng)帶上，并且不能由前端自定義內(nèi)容。 服務(wù)器可以通過(guò)解析這兩個(gè)Header中的域名，確定請(qǐng)求的來(lái)源域。

使用Origin Header確定來(lái)源域名

在部分與CSRF有關(guān)的請(qǐng)求中，請(qǐng)求的Header中會(huì)攜帶Origin字段。字段內(nèi)包含請(qǐng)求的域名（不包含path及query），如果Origin存在，那么直接使用Origin中的字段確認(rèn)來(lái)源域名就可以。

但是會(huì)有2種特殊情況，Origin是不存在的：

• IE11同源策略： IE 11 不會(huì)在跨站CORS請(qǐng)求上添加Origin標(biāo)頭，Referer頭將仍然是唯一的標(biāo)識(shí)。最根本原因是因?yàn)镮E 11對(duì)同源的定義和其他瀏覽器有不同。

• 302重定向： 在302重定向之后Origin不包含在重定向的請(qǐng)求中，因?yàn)镺rigin可能會(huì)被認(rèn)為是其他來(lái)源的敏感信息。對(duì)于302重定向的情況來(lái)說(shuō)都是定向到新的服務(wù)器上的URL，因此瀏覽器不想將Origin泄漏到新的服務(wù)器上。

使用Referer Header確定來(lái)源域名

根據(jù)HTTP協(xié)議，在HTTP頭中有一個(gè)字段叫Referer，記錄了該HTTP請(qǐng)求的來(lái)源地址。

這種方法并非萬(wàn)無(wú)一失，Referer的值是由瀏覽器提供的，雖然HTTP協(xié)議上有明確的要求，但是每個(gè)瀏覽器對(duì)于Referer的具體實(shí)現(xiàn)可能有差別，并不能保證瀏覽器自身沒(méi)有安全漏洞。使用驗(yàn)證 Referer 值的方法，就是把安全性都依賴(lài)于第三方（即瀏覽器）來(lái)保障，從理論上來(lái)講，這樣并不是很安全。在部分情況下，攻擊者可以隱藏，甚至修改自己請(qǐng)求的Referer。

在以下情況下Referer沒(méi)有或者不可信：

1. IE6、7下使用window.location.href=url進(jìn)行界面的跳轉(zhuǎn)，會(huì)丟失Referer。

2. IE6、7下使用window.open，也會(huì)缺失Referer。

3. HTTPS頁(yè)面跳轉(zhuǎn)到HTTP頁(yè)面，所有瀏覽器Referer都丟失。

4. 點(diǎn)擊Flash上到達(dá)另外一個(gè)網(wǎng)站的時(shí)候，Referer的情況就比較雜亂，不太可信

因此，服務(wù)器的策略是優(yōu)先判斷 Origin，如果請(qǐng)求頭中沒(méi)有包含 Origin 屬性，再根據(jù)實(shí)際情況判斷是否使用 Referer 值，從而增加攻擊難度。

無(wú)法確認(rèn)來(lái)源域名情況

如果 Origin 和 Referer 都不存在，建議直接進(jìn)行阻止，特別是如果您沒(méi)有使用隨機(jī) CSRF Token（參考下方）作為第二次檢查。

如何阻止外域請(qǐng)求

通過(guò)Header的驗(yàn)證，我們可以知道發(fā)起請(qǐng)求的來(lái)源域名，這些來(lái)源域名可能是網(wǎng)站本域，或者子域名，或者有授權(quán)的第三方域名，又或者來(lái)自不可信的未知域名。

我們已經(jīng)知道了請(qǐng)求域名是否是來(lái)自不可信的域名，我們直接阻止掉這些的請(qǐng)求，就能防御CSRF攻擊了嗎？

且慢！當(dāng)一個(gè)請(qǐng)求是頁(yè)面請(qǐng)求（比如網(wǎng)站的主頁(yè)），而來(lái)源是搜索引擎的鏈接（例如百度的搜索結(jié)果），也會(huì)被當(dāng)成疑似CSRF攻擊。所以在判斷的時(shí)候需要過(guò)濾掉頁(yè)面請(qǐng)求情況，通常Header符合以下情況：

Accept: text/html Method: GET

但相應(yīng)的，頁(yè)面請(qǐng)求就暴露在了CSRF的攻擊范圍之中。如果你的網(wǎng)站中，在頁(yè)面的GET請(qǐng)求中對(duì)當(dāng)前用戶(hù)做了什么操作的話(huà)，防范就失效了。

例如，下面的頁(yè)面請(qǐng)求：

GET https://example.com/addComment?comment=XXX&dest=orderId

注：這種嚴(yán)格來(lái)說(shuō)并不一定存在CSRF攻擊的風(fēng)險(xiǎn)，但仍然有很多網(wǎng)站經(jīng)常把主文檔GET請(qǐng)求掛上參數(shù)來(lái)實(shí)現(xiàn)產(chǎn)品功能，但是這樣做對(duì)于自身來(lái)說(shuō)是存在安全風(fēng)險(xiǎn)的。

另外，前面說(shuō)過(guò)，CSRF大多數(shù)情況下來(lái)自第三方域名，但并不能排除本域發(fā)起。如果攻擊者有權(quán)限在本域發(fā)布評(píng)論（含鏈接、圖片等，統(tǒng)稱(chēng)UGC），那么它可以直接在本域發(fā)起攻擊，這種情況下同源策略無(wú)法達(dá)到防護(hù)的作用。

綜上所述：同源驗(yàn)證是一個(gè)相對(duì)簡(jiǎn)單的防范方法，能夠防范絕大多數(shù)的CSRF攻擊。但這并不是萬(wàn)無(wú)一失的，對(duì)于安全性要求較高，或者有較多用戶(hù)輸入內(nèi)容的網(wǎng)站，我們就要對(duì)關(guān)鍵的接口做額外的防護(hù)措施。

3.2 CSRF Token

CSRF攻擊之所以能夠成功，是因?yàn)榉?wù)器誤把攻擊者發(fā)送的請(qǐng)求當(dāng)成了用戶(hù)自己的請(qǐng)求。那么我們可以要求所有的用戶(hù)請(qǐng)求都攜帶一個(gè)CSRF攻擊者無(wú)法獲取到的Token。服務(wù)器通過(guò)校驗(yàn)請(qǐng)求是否攜帶正確的Token，來(lái)把正常的請(qǐng)求和攻擊的請(qǐng)求區(qū)分開(kāi)，也可以防范CSRF的攻擊。

CSRF Token 原理

1. 將CSRF Token輸出到頁(yè)面中

2. 頁(yè)面提交的請(qǐng)求攜帶這個(gè)Token

3. 服務(wù)器驗(yàn)證Token是否正確

我們需要知道的是：

1. Token的值必須是隨機(jī)生成的

2. 開(kāi)發(fā)人員只需為當(dāng)前會(huì)話(huà)生成一次Token。在初始生成此 Token 之后，該值將存儲(chǔ)在會(huì)話(huà)中，并用于每個(gè)后續(xù)請(qǐng)求，直到會(huì)話(huà)過(guò)期。

3. 當(dāng)最終用戶(hù)發(fā)出請(qǐng)求時(shí)，服務(wù)器端必須驗(yàn)證請(qǐng)求中 Token 的存在性和有效性，與會(huì)話(huà)中找到的 Token 相比較。如果在請(qǐng)求中找不到Token，或者提供的值與會(huì)話(huà)中的值不匹配，則應(yīng)中止請(qǐng)求，應(yīng)重置 Token 并將事件記錄為正在進(jìn)行的潛在 CSRF 攻擊。

3.3 雙重 Cookie 認(rèn)證

• 流程：

• 步驟1：在用戶(hù)訪(fǎng)問(wèn)網(wǎng)站頁(yè)面時(shí)，向請(qǐng)求域名注入一個(gè)Cookie，內(nèi)容為隨機(jī)字符串（例如csrfcookie=v8g9e4ksfhw1213）

• 步驟2：在前端向后端發(fā)起請(qǐng)求時(shí)，取出Cookie，并添加到URL的參數(shù)中（ www.a.com/comment?csr…

• 步驟3：后端接口驗(yàn)證Cookie中的字段與URL參數(shù)中的字段是否一致，不一致則拒絕。

• 優(yōu)點(diǎn)：

• 無(wú)需使用Session，適用面更廣，易于實(shí)施。

• Token儲(chǔ)存于客戶(hù)端中，不會(huì)給服務(wù)器帶來(lái)壓力。

• 相對(duì)于Token，實(shí)施成本更低，可以在前后端統(tǒng)一攔截校驗(yàn)，而不需要一個(gè)個(gè)接口和頁(yè)面添加。

• 缺點(diǎn)：

• Cookie中增加了額外的字段。

• 如果有其他漏洞（例如XSS），攻擊者可以注入Cookie，那么該防御方式失效。

• 難以做到子域名的隔離。

• 為了確保Cookie傳輸安全，采用這種防御方式的最好確保用整站HTTPS的方式，如果還沒(méi)切HTTPS的使用這種方式也會(huì)有風(fēng)險(xiǎn)。

3.4 Samesite Cookie 屬性

Google起草了一份草案來(lái)改進(jìn)HTTP協(xié)議，那就是為Set-Cookie響應(yīng)頭新增Samesite屬性，它用來(lái)標(biāo)明這個(gè) Cookie是個(gè)“同站 Cookie”，同站Cookie只能作為第一方Cookie，不能作為第三方Cookie，Samesite 有兩個(gè)屬性值，Strict 為任何情況下都不可以作為第三方 Cookie ，Lax 為可以作為第三方 Cookie , 但必須是Get請(qǐng)求

參考：

• www.ruanyifeng.com/blog/2019/0…

• developer.mozilla.org/zh-CN/docs/…

3.5 其他方法

驗(yàn)證碼和密碼被認(rèn)為是對(duì)抗CSRF攻擊最簡(jiǎn)潔而有效的防御方法。

四、總結(jié)

4.1 CSRF攻擊特點(diǎn)

• 攻擊一般發(fā)起在第三方網(wǎng)站，而不是被攻擊的網(wǎng)站。被攻擊的網(wǎng)站無(wú)法防止攻擊發(fā)生。

• 攻擊利用受害者在被攻擊網(wǎng)站的登錄憑證，冒充受害者提交操作；而不是直接竊取數(shù)據(jù)。

• 整個(gè)過(guò)程攻擊者并不能獲取到受害者的登錄憑證，僅僅是“冒用”。

• 跨站請(qǐng)求可以用各種方式：圖片URL、超鏈接、CORS、Form提交等等。部分請(qǐng)求方式可以直接嵌入在第三方論壇、文章中，難以進(jìn)行追蹤

CSRF通常是跨域的，因?yàn)橥庥蛲ǔ８菀妆还粽哒瓶亍５侨绻居蛳掠腥菀妆焕玫墓δ埽热缈梢园l(fā)圖和鏈接的論壇和評(píng)論區(qū)，攻擊可以直接在本域下進(jìn)行，而且這種攻擊更加危險(xiǎn)。

• 點(diǎn)擊鏈接查看xxx

• 指定的是本站某個(gè)用戶(hù)關(guān)注的請(qǐng)求

4.2 與XSS的區(qū)別

本質(zhì)來(lái)說(shuō):

• xss是代碼注入的問(wèn)題

• csrf是HTTP問(wèn)題