概述

CSRF(Cross-site request forgery,跨站請求偽造)。

它是指攻擊者利用了用戶的身份信息，執行了用戶非本意的操作。

它首先引導用戶訪問一個危險網站，當用戶訪問網站后，網站會發送請求到被攻擊的站點，這次請求會攜帶用戶的cookie發送，因此就利用了用戶的身份信息完成攻擊。

防御方式

SameSite

SameSite 是一個與 HTTP 狀態碼和響應頭相關的屬性，用于定義瀏覽器如何處理跨站點請求。這個屬性主要用于防止跨站點請求偽造（CSRF，Cross-Site Request Forgery）攻擊，它允許服務器要求某些類型的 cookie 在跨站點請求中不被發送。

以下是 SameSite 屬性的幾種取值及其含義：

1. Strict: 這種模式下，cookie 將不會被包含在任何跨站點請求中。也就是說，只有在請求的域與設置 cookie 的域完全一致時，cookie 才會被發送。

2. Lax: 這種模式下，cookie 將被包含在頂層導航請求中，但不會在跨站點請求中被發送。例如，如果你從一個網站鏈接到另一個網站，瀏覽器會發送 cookie，但如果你嘗試通過 JavaScript 發起一個跨站點請求，cookie 則不會被發送。get 請求會攜帶 cookie，但是 post 請求不攜帶。

3. None: 這種模式下，cookie 將被包含在跨站點請求中。如果你想讓 cookie 在跨站點請求中被發送，就需要將 SameSite 設置為 None，并且同時設置 Secure 屬性，以確保 cookie 只在 HTTPS 上傳輸。

從 Chrome 80 開始，默認的 SameSite 變更為 SameSite=Lax，這意味著如果你的服務器沒有明確設置 SameSite 屬性，那么瀏覽器將默認以 Lax 模式處理 cookie。

為了確保跨站點請求能夠正確地攜帶 cookie，你需要：

• 設置 SameSite=None。
• 設置 Secure 屬性，確保 cookie 只在 HTTPS 上傳輸。

示例代碼：

Set-Cookie: key=value; SameSite=None; Secure

使用 CSRF Token

CSRF Token 是一種常見的防御機制，它要求每個請求都必須包含一個由服務器生成的、隨機的、唯一的 token。服務器在處理請求時會驗證這個 token 是否有效。具體步驟如下：

1. 生成 Token: 當用戶登錄后，服務器生成一個 CSRF Token 并將其存儲在服務器端的會話中。
2. 發送 Token: 服務器將 Token 發送給客戶端，并要求客戶端在后續的請求中包含這個 Token。
3. 驗證 Token: 當客戶端發起請求時，服務器會檢查請求中是否包含 Token，并且驗證 Token 是否與服務器端存儲的 Token 匹配。

這種方法的關鍵在于，攻擊者無法預測 Token 的值，因此即使他們能夠誘導用戶點擊鏈接或提交表單，由于 Token 不匹配，請求也會被服務器拒絕。

比如這里我打開某網站，他就是使用的 csrfToken。

什么是CSRF？為什么CSRF Token寫在COOKIE里面？_csrf cookie-CSDN博客

使用 Referer 檢查

Referer 是 HTTP 請求頭中的一個字段，用于指示請求是從哪個頁面發起的。服務器可以通過檢查 Referer 來防御 CSRF 攻擊：

1. 檢查 Referer: 服務器在處理請求時，檢查請求的 Referer 頭部，確認請求是否來自可信的來源。
2. 驗證來源: 如果 Referer 頭部指向的是攻擊者的域名，服務器可以拒絕處理請求。

然而，這種方法有幾個局限性：

• 用戶可能禁用了 Referer 頭部，或者瀏覽器設置可能導致 Referer 頭部不被發送。
• 攻擊者可以構造請求，使其 Referer 頭部指向合法的來源。
• 不能訪問 base64 編碼