Rails 4 为 API 操作跳过protect_from_forgery [英] Rails 4 skipping protect_from_forgery for API actions

查看:18
本文介绍了Rails 4 为 API 操作跳过protect_from_forgery的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I've been implementing a Rails 4 application with an API. I want to be able to call the API from mobile phones and the webapp itself. I came across this note while researching protect_from_forgery:

请务必记住,XML 或 JSON 请求也会受到影响,如果您正在构建 API,您将需要以下内容:

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

我正考虑这样做,但我有一些保留意见/问题:

I was thinking of doing this, but I have some reservations/questions:

  1. 这个解决方案似乎留下了 CSRF 漏洞,因为现在攻击者可以使用发布 JSON 的 onclick javascript 制作链接?
  2. 检查 API 令牌是否是合理的替代品?即,如果不是跳过真实性检查,而是允许它在 handle_unverified_request 中通过检查失败并恢复,如果 api 令牌存在并且对当前用户正确,该怎么办?
  3. 或者我应该让 web 应用程序和移动设备 发送 CSRF 令牌在 HTTP 标头中?那安全吗?如果手机一开始就没有呈现 HTML 表单,那么它如何获得 CSRF 令牌?
  1. This solution seems to leave the CSRF hole open because now an attacker could craft a link with an onclick javascript that posts JSON?
  2. Would checking for an API token be a reasonable substitute? i.e., what if instead of skipping the authenticity check, allowing it to fail the check and recover in handle_unverified_request if the api token is present and correct for current user?
  3. Or maybe I should just make the webapp and mobile devices send the CSRF token in the HTTP headers? Is that safe? How would the mobile phone even obtain the CSRF token, given that it isn't rendering HTML forms to begin with?

编辑以澄清:

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

I am more concerned about the webapp user clicking a crafted CSRF link. The mobile users are authenticated, authorized, an have an API key, so I am not concerned about them. But by enabling CSRF protection for the webapp users, the mobile users are blocked from using the protected API. I want to know the correct strategy for handling this, and I don't believe the Rails documentation gives the right answer.

推荐答案

攻击者可以随意卷曲您的控制器,但如果您的 API 需要身份验证,他们将无处可去.

An attacker could CURL at your controllers all they like, but if your API requires authentication, they wont get anywhere.

让 API 消费者发送 CSRF 并不是 CSRF 真正所做的.为此,您需要实现一种敲门机制,您的客户端首先点击授权端点以获取代码(又名 CSRF),然后在 POST 中提交.这对移动客户端来说很糟糕,因为它使用了他们的带宽和功率,而且速度很慢.

Making the API consumers send a CSRF is not really what CSRF does. To do this you'd need to implement a type of knocking mechanism where your client hits an authorization endpoint first to get the code (aka CSRF) and then submit it in the POST. this sucks for mobile clients because it uses their bandwidth, power, and is laggy.

无论如何,如果授权客户端最终攻击了您的控制器,它实际上是伪造的(即 CSRF 中的 F)吗?

And anyway, is it actually forgery (i.e. the F in CSRF) if its an authorized client hitting your controller after all?

这篇关于Rails 4 为 API 操作跳过protect_from_forgery的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆