我最近在閱讀有關 CSRF 攻擊以及 Rails 如何防御它們的文章，但有一些我不理解也找不到解釋的地方。
從我從Nvisium 的博客文章、官方指南和這段寶貴的視頻中了解到，Rails 通過以下方式防止 CSRF 攻擊：
- 將一個嵌入
authenticity_token到每個表單中 - 在處理 POST 請求時，將提交的令牌值與用戶會話中關聯的值進行比較。
但我不明白的是：由于這authenticity_token是一個公開可用的值，不能通過簡單地檢查網頁來訪問，當攻擊者可以簡單地復制這個值并將其插入到他的惡意形式中時，這種保護如何？ /她正在創作。
當然，我的直覺告訴我這比這更復雜，但我找不到任何關于如何避免上述情況的解釋。如果您有解釋或知道任何可以闡明這一點的來源，我將不勝感激
uj5u.com熱心網友回復：
在authenticity_token確保您的應用程式接收到任何提交的應用程式知道關于會話的匹配。它無助于對抗進行中間人攻擊的人，但有助于對抗那些通過提交隨意向您的應用發送垃圾郵件的人。它不會阻止合法但惡意的用戶向您的應用程式發送資料，只會阻止未遵循您的應用程式路徑的人。
基本上，這種保護是針對服務器的，而不是針對客戶端的。它絕不是針對攻擊的全面保護，但確實關閉了一種攻擊途徑。
uj5u.com熱心網友回復：
我認為 JohnP 提到的重要部分是它“僅阻止未遵循您的應用程式路徑的請求”。
因此，想象一下有人向您發送一封電子郵件，其中包含一個鏈接，可以為 Stackoverflow 帖子點贊，并附上類似Click here for money的描述。你點擊這個鏈接，如果沒有 CSRF，這個鏈接你實際上會為這篇文章點贊。但這不適用于 CSRF 預防，因為請求缺少隨機令牌并將被拒絕。
投票當然只是一個無害的例子，但它可能會泄漏資料、更改會話狀態或操縱最終用戶的帳戶。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/338828.html