一、簡介

跨站請求偽造攻擊，英文全稱是Cross-site request forgery，簡稱為CSRF。

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

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

如何攻擊

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

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

• 攻擊者引誘受害者訪問了b.com。

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

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

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

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

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

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

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

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

二、CSRF攻擊分類

2.1 GET 類型的 CSRF

GET 類型的 CSRF 利用非常簡單，只需要一個 HTTP 請求，一般這樣使用

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

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

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

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

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

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

2.3 鏈接類型的CSRF

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

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

三、防御

3.1 同源檢測

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

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

• Origin Header

• Referer Header

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

使用Origin Header確定來源域名

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

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

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

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

使用Referer Header確定來源域名

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

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

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

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

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

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

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

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

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

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

如何阻止外域請求

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

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

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

Accept: text/html Method: GET

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

例如，下面的頁面請求：

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

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

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

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

3.2 CSRF Token

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

CSRF Token 原理

1. 將CSRF Token輸出到頁面中

2. 頁面提交的請求攜帶這個Token

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

我們需要知道的是：

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

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

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

3.3 雙重 Cookie 認(rèn)證

• 流程：

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

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

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

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

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

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

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

• 缺點(diǎn)：

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

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

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

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

3.4 Samesite Cookie 屬性

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

參考：

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

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

3.5 其他方法

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

四、總結(jié)

4.1 CSRF攻擊特點(diǎn)

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

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

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

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

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

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

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

4.2 與XSS的區(qū)別

本質(zhì)來說:

• xss是代碼注入的問題

• csrf是HTTP問題