一、簡介

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

攻擊者誘導用戶進入一個第三方網站，然后該網站向被攻擊網站發送跨站請求。如果用戶在被攻擊網站中保存了登錄狀態，那么攻擊者就可以利用這個登錄狀態，繞過后臺的用戶驗證，冒充用戶向服務器執行一些操作。

CSRF 攻擊的本質：本質是利用 cookie 會在同源請求中攜帶發送給服務器的特點，以此來實現用戶的冒充。

如何攻擊

從簡介中我們得知，攻擊者需要誘導用戶進入一個第三方網站。

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

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

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

• a.com接收到請求后，對請求進行驗證，并確認是受害者的憑證，誤以為是受害者自己發送的請求。

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

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

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

1. 登錄成功網站A,并本地產生了Cookie

2. 未退出A網站的同時，訪問危險的B.com

總結來說天時地利人和。

二、CSRF攻擊分類

2.1 GET 類型的 CSRF

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

假設：網站A,銀行賬戶轉行，通過GET請求來完成

危險網站B,其中有一段代碼

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

若這時候訪問了網站B,黑客將轉賬的請求接口隱藏在 img 標簽內，欺騙瀏覽器這是一張圖片資源。當該頁面被加載時，瀏覽器會自動發起 img 的資源請求，如果服務器沒有對該請求做判斷的話，那么服務器就會認為該請求是一個轉賬請求，于是用戶賬戶上的 10000 就被轉移到黑客的賬戶上去了。

2.2 POST類型的 CSRF

還以上面的轉賬為例子進行說明

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

若訪問了該頁面，表單會自定提交。相當于進行了一次POST請求。

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

2.3 鏈接類型的CSRF

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

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

三、防御

3.1 同源檢測

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

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

• Origin Header

• Referer Header

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

使用Origin Header確定來源域名

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

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

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

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

使用Referer Header確定來源域名

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

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

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

1. IE6、7下使用window.location.href=url進行界面的跳轉，會丟失Referer。

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

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

4. 點擊Flash上到達另外一個網站的時候，Referer的情況就比較雜亂，不太可信

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

無法確認來源域名情況

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

如何阻止外域請求

通過Header的驗證，我們可以知道發起請求的來源域名，這些來源域名可能是網站本域，或者子域名，或者有授權的第三方域名，又或者來自不可信的未知域名。

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

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

Accept: text/html Method: GET

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

例如，下面的頁面請求：

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

注：這種嚴格來說并不一定存在CSRF攻擊的風險，但仍然有很多網站經常把主文檔GET請求掛上參數來實現產品功能，但是這樣做對于自身來說是存在安全風險的。

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

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

3.2 CSRF Token

CSRF攻擊之所以能夠成功，是因為服務器誤把攻擊者發送的請求當成了用戶自己的請求。那么我們可以要求所有的用戶請求都攜帶一個CSRF攻擊者無法獲取到的Token。服務器通過校驗請求是否攜帶正確的Token，來把正常的請求和攻擊的請求區分開，也可以防范CSRF的攻擊。

CSRF Token 原理

1. 將CSRF Token輸出到頁面中

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

3. 服務器驗證Token是否正確

我們需要知道的是：

1. Token的值必須是隨機生成的

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

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

3.3 雙重 Cookie 認證

• 流程：

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

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

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

• 優點：

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

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

• 相對于Token，實施成本更低，可以在前后端統一攔截校驗，而不需要一個個接口和頁面添加。

• 缺點：

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

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

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

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

3.4 Samesite Cookie 屬性

Google起草了一份草案來改進HTTP協議，那就是為Set-Cookie響應頭新增Samesite屬性，它用來標明這個 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 其他方法

驗證碼和密碼被認為是對抗CSRF攻擊最簡潔而有效的防御方法。

四、總結

4.1 CSRF攻擊特點

• 攻擊一般發起在第三方網站，而不是被攻擊的網站。被攻擊的網站無法防止攻擊發生。

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

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

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

CSRF通常是跨域的，因為外域通常更容易被攻擊者掌控。但是如果本域下有容易被利用的功能，比如可以發圖和鏈接的論壇和評論區，攻擊可以直接在本域下進行，而且這種攻擊更加危險。

• 點擊鏈接查看xxx

• 指定的是本站某個用戶關注的請求

4.2 與XSS的區別

本質來說:

• xss是代碼注入的問題

• csrf是HTTP問題