在Rails中使用HTTP GET請求進行CSRF保護

據我所知，默認情況下，Rails缺少對HTTP GET請求的CSRF保護，因爲它聲稱它們是冪等的。但是，有些敏感信息會從這些GET請求中返回給用戶，並且我不希望惡意網站檢索這些信息。在Rails中使用HTTP GET請求進行CSRF保護

什麼是最好的方式來保護HTTP GET請求從CSRF在Rails？

來源

2012-02-25 Aayush Kumar

當惡意方不CSRF攻擊，他們看不到請求的結果 - 唯一副作用是危險 – 2012-02-25 18:48:12

您通常通過cookie使用驗證了這種任務 – 2012-02-25 20:16:13

的@NikitaBeloglazov即使認證通過cookies ，當瀏覽器看到受害者網站的請求時，瀏覽器通常將cookie發送到受害者網站。這來自[維基百科文章]（http://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics）：「如果Bob的銀行將其認證信息保存在cookie中，並且cookie尚未過期，那麼Bob瀏覽器加載圖片的嘗試將提交他的cookie的提款表單，從而在未經Bob批准的情況下授權交易。「 – 2012-02-26 19:37:58

爲了能夠讀取對CSRF攻擊請求的響應，攻擊者需要讓受害者執行他的JavaScript代碼。在這種情況下，訪問將受到一些Same Origin Policy的限制。

假設攻擊請求真的cross origin，所述Same Origin Policy for DOM禁止經由DOM的訪問（例如，當使用iframe嵌入）和Cross-Origin Resource Sharing (CORS)經由XMLHttpRequest調節跨域請求如下：

如果該請求是一個simple cross-origin request，我。即simple method只有simple header fields，那麼這個請求將被髮送（這與基於HTML的CSRF類似）。但訪問簡單的跨源請求的響應取決於response allows resource sharing。

在發送實際請求之前，其他跨源請求需要所謂的preflight。該請求被髮送以檢查服務器是否允許來自發送預檢的來源的請求。只有預檢成功並且對實際請求的響應允許資源共享，才能訪問響應。

因此得出結論：除非您的服務器支持CORS並明確允許與任何其他來源（即Access-Control-Allow-Origin: *）共享，否則CSRF響應（如果請求被允許）將不會被攻擊站點讀取。

來源

2012-03-06 21:07:02 Gumbo

在Rails中使用HTTP GET請求進行CSRF保護

回答

相關問題