了解 CSRF 攻擊並鎖定 CSRF 漏洞
已發表: 2022-11-21Web 漏洞猖獗且不斷增加。 維護用戶的安全和隱私比以往任何時候都更加重要。 不解決 Web 漏洞可能會導致聲譽受損和監管機構的巨額罰款，並且您還會失去用戶的信任。
網站和 Web 應用程序容易受到惡意軟件、垃圾郵件和其他攻擊——本文重點介紹一種此類攻擊媒介——跨站點請求偽造 (CSRF) 攻擊。 CSRF 攻擊特別麻煩，因為它們可能在用戶不知情的情況下發生。 開發人員或網站所有者也很難檢測到它們，因為惡意請求看起來與真實請求非常相似。
本文探討了 CSRF 攻擊、它的工作原理，以及您可以採取的準備應對攻擊的步驟。
什麼是 CSRF 攻擊？
跨站點請求偽造攻擊，也稱為 CSRF 攻擊，通過在用戶不知情的情況下提交惡意請求，誘使經過身份驗證的用戶執行意外操作。
通常，CSRF 攻擊涉及狀態更改請求，因為攻擊者沒有收到響應。 此類請求的示例包括刪除記錄、更改密碼、購買產品或發送消息。 這些都可能在用戶不知情的情況下發生。
惡意攻擊者通常使用社會工程通過聊天或電子郵件向不知情的用戶發送鏈接。
當用戶點擊鏈接時，它會執行攻擊者設置的命令。
例如，點擊一個鏈接可以從用戶的賬戶中轉移資金。 或者，它可以更改用戶的電子郵件地址，阻止他們重新獲得帳戶訪問權限。
CSRF 攻擊如何運作？
讓用戶在登錄時發起狀態更改請求是 CSRF 攻擊的第一步，也是最關鍵的一步。 通過 CSRF 攻擊，攻擊者旨在讓經過身份驗證的用戶在不知不覺中向網站或 Web 應用程序提交惡意 Web 請求。 這些請求可以包含 cookie、URL 參數和其他對用戶來說正常的數據類型。
要使 CSRF 攻擊成功，必須滿足以下條件：
- 經過身份驗證的用戶必須登錄到使用 cookie 進行會話管理的 Web 應用程序。
- 攻擊者必須創建一個改變狀態的偽造請求。
- 目標服務器處理的真實請求不應包含不可預測的參數。 例如，在發起狀態更改請求之前，請求不應期望將密碼作為用於驗證目的的參數。
完成 CSRF 攻擊的最常見方法是在具有弱 SameSite cookie 策略的應用程序中使用 cookie。 Web 瀏覽器自動包含 cookie，並且通常是匿名的，它們會在用戶發送到該域的任何 Web 請求中保存該域使用的 cookie。
SameSite cookie 策略定義瀏覽器在跨站點瀏覽上下文中如何處理 cookie。 如果設置為嚴格，則 cookie 不會在跨站點瀏覽上下文中共享，從而防止 CSRF 攻擊。 如果設置為無，瀏覽器會在所有跨站點上下文中附加 cookie。 這使得應用程序容易受到 CSRF 攻擊。
當用戶在不知情的情況下通過 Web 瀏覽器提交惡意請求時，保存的 cookie 會導致該請求對服務器來說是合法的。 然後服務器通過更改用戶帳戶、更改會話狀態或返回請求的數據來響應請求。
讓我們仔細看看 CSRF 攻擊途徑的兩個示例，一個使用 GET 請求，另一個使用 POST 請求。
GET 請求的 CSRF
首先，考慮金融銀行 Web 應用程序使用的 GET 請求，其中攻擊利用 GET 請求和超鏈接傳遞。
假設轉賬的 GET 請求看起來像這樣：
GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1 在上面的真實請求中，用戶請求將 1,000 美元轉入547895的帳戶作為購買產品的付款。
雖然此請求明確、簡單且實用，但它會使帳戶持有人面臨 CSRF 攻擊。 那是因為該請求不需要攻擊者可能不知道的詳細信息。 因此，要發起攻擊，攻擊者只需更改此請求的參數（金額和帳號）即可創建可執行的偽造請求。
惡意請求將對銀行的任何用戶有效，只要他們正在進行 cookie 管理的會話。
下面是將 500 美元轉移到黑客帳戶（此處為號碼654585 ）的偽造請求的外觀。 請注意，以下示例是 CSRF 攻擊所涉及步驟的高度簡化版本，以供解釋。
GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1完成後，攻擊者必須想出一種方法來誘使用戶在登錄其在線銀行應用程序時發送此請求。 其中一種方法是創建一個無害的超鏈接來引起用戶的注意。 該鏈接可能如下所示：
<a href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>. 鑑於攻擊者已經找到了目標的正確電子郵件地址，他們可以通過電子郵件將其發送給許多銀行客戶。 那些在登錄時單擊該鏈接的人會觸發從登錄帳戶向攻擊者發送 500 美元的請求。
POST 請求的 CSRF
讓我們看看如果同一家金融機構只接受 POST 請求，他們將如何遇到 CSRF。 在這種情況下，GET 請求示例中使用的超鏈接傳遞將不起作用。 因此，成功的 CSRF 攻擊需要攻擊者創建 HTML 表單。 為購買的產品發送 1,000 美元的真實請求如下所示：
POST /online/transfer HTTP/1.1 Host: xymbank.com Content-Type: application/x-www-form-urlencoded Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg amount=1000 account=547895這個 POST 請求需要一個 cookie 來確定用戶的身份、他們希望發送的金額以及他們想要發送的帳戶。 攻擊者可以更改此請求以執行 CSRF 攻擊。
攻擊者必須只向偽造的請求添加真正的 cookie，以使服務器處理傳輸。 他們可以通過創建一個看起來無害的超鏈接來做到這一點，該超鏈接將用戶帶到如下所示的觸發網頁：
<html> <body> <form action="https://xymbank.com/online/transfer" method="POST"> <input type="hidden" name="amount" value="500"/> <input type="hidden" name="account" value="654585" /> </form> <script> document.forms[0].submit(); </script> </body> </html>我們已經在上面的表格中設置了金額和帳戶參數。 一旦經過身份驗證的用戶訪問該頁面，瀏覽器就會在將請求轉發到服務器之前添加會話 cookie。 服務器然後將 500 美元轉發到黑客的帳戶。
減輕 CSRF 攻擊的 3 種方法
有幾種方法可以防止和大大減輕對您的網站或 Web 應用程序的潛在 CSRF 攻擊，包括：
- 使用 CSRF 令牌
- 使用引用標頭
- 選擇以安全為中心的託管解決方案，例如 Kinsta
如何使用 CSRF 令牌防止 CSRF 攻擊
CSRF 安全網站為每個會話分配一個唯一的令牌，並與服務器端和客戶端瀏覽器共享。 每當瀏覽器發送敏感請求時，服務器都希望它包含分配的 CSRF 令牌。 如果它有錯誤的令牌，服務器會丟棄它。 出於安全目的，CSRF 令牌不會存儲在客戶端瀏覽器的會話 cookie 中。
CSRF 代幣的潛在漏洞
儘管 CSRF 令牌是一種出色的安全措施，但這種方法無法抵禦攻擊。 CSRF 令牌附帶的一些漏洞包括：
- 驗證繞過——一些應用程序如果找不到令牌則跳過驗證步驟。 如果攻擊者獲得對包含令牌的代碼的訪問權限，他們可以刪除該令牌並成功執行 CSRF 攻擊。 因此，如果對服務器的有效請求如下所示：
POST /change_password POST body: password=pass123&csrf_token=93j9d8eckke20d433攻擊者只需移除令牌並像這樣發送它即可執行攻擊：
POST /change_password POST body: password=pass123- 池化令牌——一些應用程序維護一個令牌池來驗證用戶會話，而不是為會話指定一個特定的令牌。 攻擊者只需獲取池中已有的令牌之一，即可冒充該站點的任何用戶。
攻擊者可以使用他們的帳戶登錄應用程序以獲得令牌，例如：
[application_url].com?csrf_token=93j9d8eckke20d433由於令牌被合併，攻擊者可以復制並使用相同的令牌登錄到不同的用戶帳戶，因為您將再次使用它：
- CSRF 可以被令牌複製到 cookie — 一些應用程序會將與令牌相關的參數複製到用戶的 cookie 中。 如果攻擊者獲得了對此類 cookie 的訪問權限，他們可以輕鬆創建另一個 cookie，將其放置在瀏覽器中，然後執行 CSRF 攻擊。
因此攻擊者可以使用他們的帳戶登錄應用程序並打開 cookie 文件以查看以下內容：
Csrf_token:93j9d8eckke20d433然後他們可以使用此信息創建另一個 cookie 來完成攻擊
- 無效令牌——某些應用程序不將 CSRF 令牌與用戶會話匹配。 在這種情況下，攻擊者可以真正登錄會話，獲取與上述類似的 CSRF 令牌，並使用它來編排對受害者會話的 CSRF 攻擊。
如何使用 Referrer 標頭防止 CSRF 攻擊
另一種防止 CSRF 攻擊的策略是使用引用標頭。 在 HTTP 中，引用標頭指示請求的來源。 它們通常用於執行分析、優化和日誌記錄。
您還可以在服務器端啟用檢查引用標頭以防止 CSRF 攻擊。 服務器端檢查請求的來源並確定請求的目標來源。 如果它們匹配，則請求被允許。 如果不匹配，服務器將丟棄請求。
使用 referrer 標頭比使用令牌容易得多，因為它不需要單獨的用戶標識。
Referrer 標頭的潛在漏洞
與 CSRF 令牌一樣，引用標頭也有一些重大漏洞。
首先，引薦來源標頭不是強制性的，有些網站會在沒有它們的情況下發送請求。 如果 CSRF 沒有處理無標頭請求的策略，攻擊者可以使用無標頭請求來執行狀態更改攻擊。
此外，隨著最近引入的推薦人政策，這種方法變得不那麼有效了。 此規範可防止 URL 洩漏到其他域，使用戶能夠更好地控制引用標頭中的信息。 他們可以選擇公開部分 referrer header 信息，或者通過在 HTML 頁面上添加元數據標籤來禁用它，如下所示：
<meta name="referrer" content="no-referrer">上面的代碼刪除了來自該頁面的所有請求的引用標頭。 這樣做會使依賴引用標頭的應用程序難以防止來自此類頁面的 CSRF 攻擊。
Kinsta 如何防止 CSRF 攻擊
除了使用引薦來源網址標頭和 CSRF 令牌之外，還有第三種更簡單的選擇：為您的網站和 Web 應用程序選擇像 Kinsta 這樣的安全託管服務，在攻擊者和您的用戶之間提供更強大和更安全的屏障。
除了自動備份、雙因素身份驗證和基於 SSH 協議的 SFTP 等關鍵安全功能之外，Kinsta 的 Cloudflare 集成還提供基於 IP 和防火牆保護的企業級保護。
具體來說，Kinsta 目前有大約 60 條自定義防火牆規則，以幫助防止惡意攻擊並處理插件和主題中嚴重的未經身份驗證的漏洞，包括尋找 CSRF 漏洞的特定漏洞。
概括
跨站點請求偽造 (CSRF) 是一種欺騙經過身份驗證的用戶無意中發起狀態更改請求的攻擊。 它們針對的是無法區分有效和偽造的狀態更改請求的應用程序。
CSRF 只能在依賴會話 cookie 來識別登錄用戶並且具有弱 SameSite cookie 策略的應用程序上成功。 他們還需要一個服務器來接受不包含未知參數（例如密碼）的請求。 黑客可以使用 GET 或 POST 發送惡意攻擊。
儘管使用 CSRF 令牌或強制執行引薦來源標頭驗證可以防止某些 CSRF 攻擊，但這兩種措施都有潛在的漏洞，如果您不小心，可能會使您的預防措施失效。
遷移到像 Kinsta 這樣的安全託管平台可以保護您的網站或 Web 應用程序免受 CSRF 攻擊。 此外，Kinsta 與 Cloudflare 的集成可防止特定的 CSRF 攻擊。