禁用CSRF保護有時是合理的嗎？

根據其性質，登錄表單阻止對任意輸入動作 - 沒有一個有效的用戶名和密碼，你只會得到反彈。有什麼理由甚至需要添加authenticity_token或類似的跨站點請求僞造保護？

我很好奇，如果登錄表單是一個例子CSRF甚至可能是通常是不可取：

鑑於匿名客戶端，它應該被允許與網站接觸的第一點是張貼有效的登錄憑據。 CSRF通過首先要求客戶端執行GET來建立一個匿名會話cookie來防止這種直接交互，該cookie用作其authenticity_token的基礎。然後必須使用登錄憑證回傳令牌。當這裏的實際目標是驗證沒有會話到達並且正在嘗試給出憑證的用戶時，額外的預先步驟似乎毫無意義。

我在這種情況下缺少一些安全考慮因素嗎？

來源

2011-04-08 Andrew Vit

如果沒有XSRF保護，攻擊者可能會將用戶登錄到惡意帳戶，以便用戶跟蹤其活動。這在Robust Defenses for Cross-Site Request Forgery中討論。

我不明白爲什麼客戶端應該能夠將登錄憑據作爲第一聯繫人。對於Web界面，在大多數實際情況下，客戶端必須通過GET登錄頁來檢索表單。

來源

2011-10-02 00:28:01 Gelatin

感謝您的鏈接，這是很好的閱讀。我認爲在提交證書前，Web服務API是一個合理的地方，客戶端不必首先獲取登錄頁面。 – 2011-10-02 03:14:17

如果它是一個Web服務，並且您只是在響應（未設置Cookie）中爲將來的請求發送令牌（這不應該成爲問題），因爲它不會對用戶造成任何副作用。 – Gelatin 2011-10-02 10:56:19

非常好的問題！它讓我撓了一會頭。

攻擊者已通過其他方式獲取受害者密碼但自己無法訪問網站的情況如何？他的技巧他的受害者到去www.evil.com並有此初始頁面上：

<image src="http://portal.internal/login.php?user=root&password=hunter2"/>

這說服受害者的瀏覽器到受害者身份驗證的網站。然後，www.evil.com的另一頁上，還有另外一個形象標籤：

<image src="http://portal.internal/deleteEverything.php/>

在這種情況下，攻擊者必須使用 CSRF來訪問內部站點，因爲他沒有別的辦法訪問它。此外，請注意，此CSRF攻擊不需要在系統中實際擁有帳戶的用戶上執行，而只需要對網站具有網絡訪問權限的用戶執行。

來源

2011-04-09 03:29:48

這樣的行爲不應該首先被http GET請求訪問，尤其是破壞性的：這是一個比我認爲的CSRF更大的問題。 – 2011-04-11 19:31:56

是的。但是，再假設像GET這樣的行爲不存在就更糟。 – 2011-04-12 02:58:55

對於Rails應用程序，特別是Rails 3應用程序，這通常是一個好的假設，遵循標準的Rails約定。 – yfeldblum 2011-10-02 02:44:48

禁用CSRF保護有時是合理的嗎？

回答

相關問題