我一直在使用 API 实现 Rails 4 应用程序。我希望能够从手机和 webapp 本身调用 API。我遇到了this note在研究 protect_from_forgery 时:

It's important to remember that XML or JSON requests are also affected and if you're building an API you'll need something like:

class ApplicationController < ActionController::Base
  protect_from_forgery
  skip_before_action :verify_authenticity_token, if: :json_request?

  protected

  def json_request?
    request.format.json?
  end
end

我正在考虑这样做，但我有一些保留/问题:

1. 这个解决方案似乎打开了 CSRF 漏洞，因为现在攻击者可以使用发布 JSON 的 onclick javascript 制作链接？
2. 检查 API token 是否是合理的替代方法？即，如果 api token 存在并且对于当前用户是正确的，而不是跳过真实性检查，而是允许它在 handle_unverified_request 中检查失败并恢复？
3. 或者我应该只制作 webapp 和移动设备 send the CSRF token in the HTTP headers ?那安全吗？考虑到手机一开始没有呈现 HTML 表单，它如何获得 CSRF token ？

编辑澄清:

我更关心 webapp 用户点击精心制作的 CSRF 链接。移动用户经过身份验证、授权、拥有 API key ，所以我不关心他们。但是通过为 webapp 用户启用 CSRF 保护，移动用户被阻止使用 protected API。我想知道处理这个问题的正确策略，我不相信 Rails 文档给出了正确的答案。

最佳答案

攻击者可以随心所欲地在您的 Controller 上进行 CURL，但如果您的 API 需要身份验证，他们将无处可去。

让 API 消费者发送 CSRF 并不是 CSRF 真正做的事情。为此，您需要实现一种敲门机制，您的客户端首先点击授权端点以获取代码(也称为 CSRF)，然后在 POST 中提交。这对移动客户端来说很糟糕，因为它会使用它们的带宽、功率并且滞后。

无论如何，如果它是经过授权的客户端访问你的 Controller ，它实际上是伪造的吗(即 CSRF 中的 F)？

关于ruby-on-rails - Rails 4 为 API 操作跳过protect_from_forgery，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23773730/