如何在GAE應用程序中最好地防止CSRF攻擊？

那麼，爲GAE應用程序防止XSRF攻擊的最佳方法是什麼？想象一下以下內容：如何在GAE應用程序中最好地防止CSRF攻擊？

任何人都可以看到該用戶的公共對象，並且db.Model ID在請求中使用，以找出哪些對象顯示。惡意用戶現在擁有該ID。
惡意用戶創建自己的對象並檢出刪除表單。他們現在知道如何刪除具有特定ID的對象。
惡意用戶獲取無辜用戶提交該用戶對象的刪除請求。

我可以添加哪些步驟來防止＃3？請注意，當我說ID時，我正在使用密鑰的實際ID部分。我想到的一個想法是在刪除請求中使用完整的鍵值，但會阻止惡意用戶能夠解決這個問題嗎？據我所知，關鍵是模型類類型，應用程序ID和對象實例ID的一些組合，所以如果他們願意的話，他們可能會從ID中獲得密鑰。

還有其他想法嗎？ Jeff寫了a post about this，並提出了幾個方法 - 一個會在每個請求中改變的隱藏表單值，以及一個通過js寫入表單的cookie值。我不想排除非javascript用戶，所以cookie解決方案是不好的 - 對於隱藏的表單值，我將不得不在每個顯示可刪除對象的請求上執行數據存儲寫操作 - 這對於可伸縮性來說並不理想應用程序！

有沒有其他想法呢？

來源

2008-10-13 Chris Marasti-Georg

當您生成允許用戶刪除對象的頁面時，生成一個隨機標記並將其包含在隱藏表單域中。還要用該值設置僅HTTP cookie。當您收到刪除請求時，請檢查表單中的隨機標記和cookie中的值是否匹配。

您的隨機標記不應該只是一個隨機數。您應該對隨機數和用戶身份的組合進行加密，以使攻擊者難以僞造自己的令牌。您還應該使用不同的加密密鑰來存儲表單中存儲的值以及存儲在cookie中的值，因此如果其中一個令牌泄漏，攻擊者難以僞造另一個令牌。

此方法通過表單中存在的安全令牌來驗證刪除請求是否源自您的表單;並且不需要寫入數據存儲區。

這種方法仍然容易受到跨站腳本攻擊的攻擊，攻擊者可以從表單中檢索隱藏值或提交表單，從而徹底測試您的站點是否存在跨站點腳本漏洞。這種方法也容易受到攻擊。

來源

2009-05-25 23:16:50

簡單：檢查引薦者。如果它是空白的（某些代理和瀏覽器剝離查閱者）或從您自己的網站（或更具體地來自期望的源代碼）允許它（有意）不可能設置。否則，拒絕並記錄它。

編輯：Jeff用幾種方法寫了一個followup article來防止CSRF攻擊。

來源

2008-10-13 20:20:33

那麼，如果有人通過代理連接到我的網站，並遇到XSRF攻擊，他們將不受保護？另外，傑夫提到引用者很容易被欺騙。我知道，作爲一名用戶，我可以輕鬆做到這一點，但是網站能否以某種方式讓瀏覽器報告不同的推薦人？ – 2008-10-14 13:16:14

只有當代理或瀏覽器剝離引薦者時，他們纔會受到保護。很少這樣做，並且通過保護所有你能夠保護的人，你使得攻擊沒有吸引力。是的，引用者是可僞造的，但攻擊者無法通過任何代碼說服用戶在瀏覽器中執行代碼。 – 2008-10-14 18:22:00

不允許空白Referer標題！如果從HTTPS頁面請求HTTP頁面，則不會發送[Referer]（http://stackoverflow.com/a/1361720/691281）。因此，如果您的表單位於HTTP頁面上，攻擊者可以使得引用者在CSRF攻擊中變爲空白。即使您的表單位於HTTPS頁面上，我也會非常懷疑空白Referer標頭。 – 2013-04-06 17:37:22

在服務器的響應顯示錶單創建一個神奇的哈希（基於客戶端IP +日期/時間+隨機鹽，無論）。將其放入cookie並存儲在服務器上的某個位置。在提交操作處理期間，根據數據庫條目檢查cookie哈希。

如果沒有這樣的散列或者它不同，請拒絕提交。

成功提交後，您可以刪除哈希條目，將其狀態更改爲提交 - 無論適合您。

該方法應該在很多情況下保護你，但肯定仍然不是100％防彈。

搜索CSRF上的文章，也許你會發現這個Stack Overflow事情的一些很好的答案。 ;）

不要做任何引用者檢查或客戶端ip驗證 - 它太容易出錯（引用者信息可能被用戶代理，代理或用戶的首選項清除），客戶端的IP可能會在表單創建和提交 - 不要懲罰用戶進行動態IP地址分配。

來源

2008-10-15 14:38:52 macbirdie

如何在GAE應用程序中最好地防止CSRF攻擊？

回答

相關問題