CSRF保護GET鏈接

我需要將CSRF保護添加到Web應用程序。CSRF保護GET鏈接

問題在於，應用程序嚴重依賴鏈接（GET請求）來更改數據庫。

鏈接是使用類生成的，所以我可以輕鬆地爲每個鏈接添加一個額外的CSRF令牌參數。

但是，我知道GET請求中的CSRF令牌可能不是一個足夠好的保護。

請注意，應用程序只能通過HTTPS使用，因此GET參數無法在客戶端/服務器通信期間暴露/被盜（但仍存在歷史盜取問題）。

可以在此設置中將GET CSRF令牌參數視爲「足夠安全」嗎？

如果不是，解決此問題的最佳方法是什麼？唯一讓我想到的是將每個鏈接都包裝到一個表單中（以太，或者使用JavaScript創建表單onSubmit）。

來源

2012-09-11 h9lpq0u

爲了能夠讀取對CSRF攻擊請求的響應，攻擊者需要讓受害者執行他的JavaScript代碼。所以，對於「GET」請求的CSRF幾乎沒有用處。這是假設你已經按照標準的「GET」請求不應修改任何數據和任何修改需要使用「POST」

使用基於Cookie的身份驗證和SSL應該讓你從一個人客場僅做誰試圖改變參數
您可能要推出基於時間戳一些簽約，以避免重放攻擊

也就是說，如果您有任何POST請求，你應該考慮的CSRF保護。

來源

2012-09-11 17:30:31 ddb

GET請求*被*用於修改數據，這是我的問題。重構停止使用GET請求進行數據修改不是一種選擇，所以我的問題是GET + csrf token + https是否「足夠安全」，或者我應該（以及如何）正確地將GET請求更改爲POST請求「。 – h9lpq0u

在您重構具有該級別的保護之前，它可能沒有問題。但它並不完全安全。您會發現，cookie中的csrf標記可以使用JavaScript代碼進行抽取，並且可以在用戶會話中用於錯誤執行。我不是100％自信這個..但檢查這兩個鏈接來決定 - http://stackoverflow.com/questions/2769992/replay-attacks-for-https-requests和https://www.owasp.org/的index.php /交叉Site_Request_Forgery_（CSRF）_Prevention_Cheat_Sheet＃Disclosure_of_Token_in_URL。我不知道任何將GET轉換爲POST的方式。 – ddb

感謝您的評論。關於將GET轉換爲POST，因爲我使用class Link創建鏈接，所以我可以在一個地方更改所有鏈接的格式。我腦海中有兩種方法。例如，我可以添加onclick javascript代碼，它可以創建表單，從GET鏈接添加所有參數，並提交表單。或者我可以將鏈接包裝在表單元素中，添加隱藏的參數並更改鏈接行爲，以便它只提交該表單。 – h9lpq0u

CSRF保護GET鏈接

回答

相關問題