介紹
Cookie 是管理使用者驗證狀態的便利機制。當會話 ID 儲存在 cookie 中時，瀏覽器會自動將其附加到針對該網域的傳出 HTTP 請求。
但是，此自動附件功能會被 跨站點請求偽造 (CSRF) 攻擊所利用。
儘管現代瀏覽器預設採用更安全的 cookie 行為（例如自動套用 SameSite=Lax），但開發人員必須了解 CSRF 防禦模式以防止嚴重的驗證漏洞。本文回顧 SameSite cookie 屬性和 CSRF 令牌驗證模式。
1. CSRF 攻擊如何運作
當惡意網站提示受害者的瀏覽器在使用者目前經過驗證的受信任應用程式上執行不需要的操作時，就會發生 CSRF 攻擊。
- 使用者登入銀行應用程式 (
bank.com)，伺服器將會話識別碼儲存在本機 cookie 中。 - 經過身份驗證後，使用者造訪惡意網站 (
evil.com)。 - 惡意網站執行一個腳本，將轉帳請求 (
POST /transfer) 傳送到銀行應用程式 (bank.com)。 - 由於請求的目標是
bank.com，瀏覽器會自動包含經過驗證的會話 cookie。 - 銀行伺服器將請求作為合法的、經過身份驗證的會話處理，並執行交易。
2.防禦一：SameSite Cookie 屬性
防止 CSRF 最有效的方法是將 SameSite 屬性套用至會話 cookie。此設定告訴瀏覽器是否應將 cookie 包含在源自第三方（跨網站）網域的請求中。
三種配置選項
Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Lax
| 設定 | 行為 |
|---|---|
| SameSite=嚴格 | 阻止瀏覽器在跨網站請求中傳送 cookie。即使用戶從外部搜尋引擎點擊直接連結到您的網站，他們也需要再次登錄，因為 cookie 已保留。 |
| SameSite=寬鬆 | 在跨網站請求上保留 cookie，但在使用者透過點擊連結（GET 請求）導航到您的網站時允許 cookie。這是 Web 應用程式的行業預設設定。 |
| SameSite=無 | 將 cookie 附加到所有跨站點請求，包括嵌入式 iframe 呼叫。設定 SameSite=None 需要 Secure 標誌（限制傳輸到 HTTPS 連線）。 |
SameSite=Lax 的重要限制
雖然大多數現代瀏覽器預設使用 SameSite=Lax，但僅依賴它會留下潛在的安全漏洞：
- 不正確的 HTTP 方法使用（GET 突變）：
如果您的應用程式透過 GET 請求（例如
GET /delete?id=5）執行狀態更改，SameSite=Lax將不會保護您，因為 Lax 允許在跨站點 GET 連結點擊時使用 cookie。對於狀態變更端點，請一律使用POST、PUT或DELETE。 - 舊版瀏覽器支援：
較舊的行動 WebView 環境和舊版桌面瀏覽器無法辨識
SameSite屬性。
3.防禦2：雙重提交Cookie模式
為了確保所有瀏覽器環境的安全性，應用程式應使用 CSRF 令牌 驗證機制。無狀態單頁應用程式 (SPA) 的常見模式是 雙提交 Cookie 模式。
它是如何運作的
- 當使用者進行身份驗證時，伺服器會產生一個隨機的加密安全性令牌（CSRF 令牌）並將其儲存為客戶端 cookie。
- 當 SPA 發出變更請求（
POST、PUT、DELETE）時，JavaScript 會讀取 cookie 值並將令牌附加到自訂 HTTP 標頭（例如X-CSRF-Token）。 - 後端伺服器驗證請求頭中的token與cookie中的token是否相符。
為什麼這是安全的
雖然惡意網站 (evil.com) 可以觸發自動包含應用程式 cookie 的表單提交，但瀏覽器的 同源原則 (SOP) 會阻止第三方 JavaScript 讀取您的 cookie 將令牌附加到自訂 HTTP 標頭。
結論
保護您的身分驗證管道免受 CSRF 的影響需要採用多層方法：
- **確保所有會話 cookie 均配置有
SameSite=Lax或Strict並包含HttpOnly標誌。 ** - **絕不允許透過 GET 請求發生狀態變更。 **
- **使用自訂 HTTP 標頭和雙重提交 Cookie 模式來保護突變端點。 **
實施這些準則將保護您的會話身份驗證並保護使用者免受劫持攻擊。