一、簡(jiǎn)介

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

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

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

如何攻擊

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

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

• 攻擊者引誘受害者訪問了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í)滿足2各條件

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

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

總結(jié)來說天時(shí)地利人和。

二、CSRF攻擊分類

2.1 GET 類型的 CSRF

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

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

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

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

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

2.2 POST類型的 CSRF

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

<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>

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

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

2.3 鏈接類型的CSRF

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

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

三、防御

3.1 同源檢測(cè)

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

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

• Origin Header

• Referer Header

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

使用Origin Header確定來源域名

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

但是會(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)為是其他來源的敏感信息。對(duì)于302重定向的情況來說都是定向到新的服務(wù)器上的URL，因此瀏覽器不想將Origin泄漏到新的服務(wù)器上。

使用Referer Header確定來源域名

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

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

在以下情況下Referer沒有或者不可信：

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

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

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

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

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

無法確認(rèn)來源域名情況

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

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

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

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

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

Accept: text/html Method: GET

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

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

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

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

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

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

3.2 CSRF Token

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

CSRF Token 原理

1. 將CSRF Token輸出到頁面中

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

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

我們需要知道的是：

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

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

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

3.3 雙重 Cookie 認(rèn)證

• 流程：

• 步驟1：在用戶訪問網(wǎng)站頁面時(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)：

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

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

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

• 缺點(diǎn)：

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

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

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

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

3.4 Samesite Cookie 屬性

Google起草了一份草案來改進(jìn)HTTP協(xié)議，那就是為Set-Cookie響應(yīng)頭新增Samesite屬性，它用來標(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)站無法防止攻擊發(fā)生。

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

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

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

CSRF通常是跨域的，因?yàn)橥庥蛲ǔ８菀妆还粽哒瓶?。但是如果本域下有容易被利用的功能，比如可以發(fā)圖和鏈接的論壇和評(píng)論區(qū)，攻擊可以直接在本域下進(jìn)行，而且這種攻擊更加危險(xiǎn)。

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

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

4.2 與XSS的區(qū)別

本質(zhì)來說:

• xss是代碼注入的問題

• csrf是HTTP問題