ruby-on-rails - Rails 应用程序中的 CSRF 服务于 HTML 并为其他客户端(例如 iOS)公开 API

Question

Ruby On Rails 框架包含一些功能，可让您轻松构建公开网络服务 API 的服务器应用程序。例如， Controller 执行以下操作:

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 格式响应)，适用于任何可能为 Web 浏览器提供 HTML 内容的 Controller 客户端，其中 CSRF 保护是强制性的。 JavaScript 代码可以查找 Rails 包含的神奇“元”标记，读取 CSRF token 并将其提交回 XHR 调用，在服务器上调用基于 POST 的操作或类似操作。

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

但是外部调用者呢？如果我们有 Rails 支持一个网站，但我们想制作一个与同一个头端对话的原生 iOS 或 Android 应用程序怎么办？该应用程序将进行服务调用 - 很好，Rails 使这很容易 - 但任何修改服务器上数据的尝试都会失败，因为我们没有 CSRF token 。 我们不能绕过 CSRF 保护，因为相同的 Controller 代码可以处理网络浏览器和“纯 API”客户端。

所有与 Rails 和 API 调用的 CSRF 问题相关的答案似乎都假定您将针对此类情况使用不同的 Controller 。但那是愚蠢的——如果它只对网页中的 JavaScript 代码有用，那么所有“让你的应用程序更容易公开为服务”的东西有什么意义，除非你在绕过 CSRF 的特殊 Controller 中复制一堆代码允许非网络客户端？这种额外的 Controller 只会增加攻击面。

有谁知道推荐的“正确”模式来处理 Rails 应用程序中的 CSRF 保护，这些应用程序的操作可能会被两种网络浏览器或非网络浏览器客户端(如 native iOS 或 Android 应用程序)“调用”？像“respond_with(...)”这样的内置东西不会做任何有用的事情，比如总是生成一个 JSON/XML 对象，其中包含 CSRF token 作为无所不在的字段。我能想到的最好的办法就是自己做，例如将“@thing”渲染为:

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

...但这看起来有点像 hack，需要做很多工作，而且它似乎通过在每个请求上宣布最新的 token 来绕过 world+dog 的 CSRF。 一定有更好的方法:-)

Answer 1

嗯，docs 说

Turn on request forgery protection. Bear in mind that only non-GET, HTML/JavaScript requests are checked.

建议对 JSON 和 XML 回复的请求已经不会进行 csrf 检查，我想这就是您的目标？它实际上不是那样工作的吗？

你也可以覆盖 verify_authenticity_token在您的 Controller 中具有用于何时实际执行验证的自定义逻辑；这是一个非常简单的方法，调用其他实际工作方法来进行验证并在未验证时做出响应，因此您可以重写以仅在某些情况下进行验证检查，如果这是您需要的话。或者不覆盖，只需基于相同的想法编写您自己的 before_filter，并调用您自己的 before 过滤器——查看源代码，这几乎就是所有 protect_from_forgery 所做的，添加 verify_authenticity_token 作为 before_filter。不过，做这些事情中的任何一件在未来可能会也可能不会向前兼容。

啊，我看到了 note you linked to宣布对“所有 非 GET 请求”进行 CSRF 保护，所以我猜说它仅适用于 HTML 请求的文档已经过时了——但这让我想到，这是什么原因改变？ (该公告没有准确记录漏洞的性质，我也没有去寻找差异)。您当然可以成功地以某种方式取消它并使 XML/JSON 请求不再检查 CSRF——但是您是否会重新引入 3.0.4 打算修补的任何漏洞，这对您的应用程序重要吗？我不知道。