CSRF在Rails應用程序中提供HTML併爲其他客戶端（如iOS）提供API

Question

Ruby On Rails框架包含的功能可以輕鬆構建公開Web服務API的服務器應用程序。例如，控制器執行以下操作：您在Web瀏覽器

respond_to :html, :json, :xml 

def show 
    @thing = Thing.find(params[:id]) 
    respond_with @thing 
end 

...將負責「秀」的行動，再次提供HTML，也渲染請求項目「@thing」爲JSON或XML是指定這種數據格式。

在此特定示例中，基於GET的「顯示」操作不涉及任何特殊的安全措施。現在考慮一個類似於上述情況的例子，但是對於諸如「創建」或「更新」之類的操作 - 由（模擬）PUT或（實際）POST請求激活的事情。現在CSRF保護起作用。

• http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf

這裏，可悲的是Rails的似乎只有被設計爲應對來自JavaScript代碼「API調用」（非HTML格式的響應）同一個域的網頁內執行，對任何可將HTML內容提供給Web瀏覽器客戶端的控制器，其中CSRF保護是強制性的。 JavaScript代碼可以查找Rails包含的魔術'meta'標籤，讀取CSRF令牌並將其提交回XHR調用，調用基於POST的操作或類似的服務器。

• http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails/

但對於外部呼叫者？如果我們的Rails支持一個網站，但是我們想要創建一個原生的iOS或Android應用程序來與同一個頭端進行對話，該怎麼辦？該應用程序將進行服務調用 - 很好，Rails使這一切變得簡單 - 但是任何修改服務器數據的嘗試都會失敗，因爲我們沒有CSRF令牌。 我們不能僅僅繞過CSRF保護，因爲相同的控制器代碼處理Web瀏覽器以及「純API」客戶端。

與Rails和API調用有關的CSRF問題的所有答案似乎假設你將有這種情況下不同的控制器。但這很愚蠢 - 如果只能用於網頁中的JavaScript代碼，那麼所有「將應用程序作爲服務公開」這一點很容易，除非您在使用CSRF的特殊控制器中重複使用一堆代碼允許非Web客戶端？這種額外的控制器只會增加攻擊面。

有沒有人知道推薦的「正確」模式來處理Rails應用程序中的CSRF保護，這些應用程序可能由Web瀏覽器或非Web瀏覽器客戶端（如本機iOS或Android應用程序）「調用」？諸如「respond_with（...）」之類的內置東西不會像總是生成一個JSON/XML對象那樣有用，它將CSRF標記作爲一個無所不在的字段。我能想到的最好的辦法就是自己去做，例如渲染「@thing」爲：

{ 
    csrf: "abcdef...7890", 
    object: { ...JSON representation of @thing... } 
} 

...但是這似乎是一個黑客位，相當多的工作的，它似乎繞過CSRF世界+狗宣佈在每一個最近的令牌無論如何請求。有必須是:-)

Answer 1

嗯一個更好的方式，docs說是

打開請求僞造保護。請記住只檢查非GET，HTML/JavaScript請求。

表明對JSON和XML repsonses的請求已經不會被csrf檢查了，這是我認爲你的目標是什麼？它實際上不是那樣工作嗎？

您也可以在您的控制器中重寫verify_authenticity_token以擁有自定義邏輯以確定何時實際執行驗證;這是一個非常簡單的方法，可以調用其他實際工作人員方法進行驗證，如果未驗證，則可以進行響應，因此如果這是您需要的，則可以在某些情況下僅覆蓋驗證檢查。或者不要覆蓋，只需根據相同的想法編寫自己的before_filter，然後在過濾之前調用自己的代碼 - 查看源代碼，幾乎全部是protect_from_forgery，請將verify_authenticity_token作爲before_filter添加。儘管做這些事情可能會或可能不會向前兼容。

啊，我看note you linked to宣佈CSRF保護髮生的「所有非GET請求」，所以我想這文件說這是隻針對HTML請求是過時的 - 但是，這讓我想到，是什麼是這種變化的原因嗎？ （該公告沒有準確記錄漏洞的性質，而且我也沒有去尋找差異）。你當然可以成功地以這樣或那樣的方式解決這個問題，並且不再檢查CSRF的XML/JSON請求 - 但是你會重新引入任何漏洞3.0.4打算補丁，這對你的應用程序會起作用嗎？我不知道。