这个Rails JSON身份验证API(使用Devise)是否安全?


70

我的Rails应用程序使用Devise进行身份验证。它有一个姐妹iOS应用程序,用户可以使用与该Web应用程序相同的凭据登录到iOS应用程序。所以我需要某种API进行身份验证。

这里有许多类似的问题指向本教程,但它似乎token_authenticatable已过时,因为此模块已从Devise中删除,并且某些行会引发错误。(我使用的是Devise 3.2.2。)我曾尝试根据该教程(和教程)来推出自己的教程,但我对此并不百分百自信-我觉得可能有些东西被误解或错过。

首先,按照这个要点的建议,我authentication_tokenusers表中添加了text属性,以下内容添加到user.rb

before_save :ensure_authentication_token

def ensure_authentication_token
  if authentication_token.blank?
    self.authentication_token = generate_authentication_token
  end
end

private

  def generate_authentication_token
    loop do
      token = Devise.friendly_token
      break token unless User.find_by(authentication_token: token)
    end
  end

然后,我有以下控制器:

api_controller.rb

class ApiController < ApplicationController
  respond_to :json
  skip_before_filter :authenticate_user!

  protected

  def user_params
    params[:user].permit(:email, :password, :password_confirmation)
  end
end

(请注意,我application_controller有一行before_filter :authenticate_user!。)

api / sessions_controller.rb

class Api::SessionsController < Devise::RegistrationsController
  prepend_before_filter :require_no_authentication, :only => [:create ]

  before_filter :ensure_params_exist

  respond_to :json

  skip_before_filter :verify_authenticity_token

  def create
    build_resource
    resource = User.find_for_database_authentication(
      email: params[:user][:email]
    )
    return invalid_login_attempt unless resource

    if resource.valid_password?(params[:user][:password])
      sign_in("user", resource)
      render json: {
        success: true,
        auth_token: resource.authentication_token,
        email: resource.email
      }
      return
    end
    invalid_login_attempt
  end

  def destroy
    sign_out(resource_name)
  end

  protected

    def ensure_params_exist
      return unless params[:user].blank?
      render json: {
        success: false,
        message: "missing user parameter"
      }, status: 422
    end

    def invalid_login_attempt
      warden.custom_failure!
      render json: {
        success: false,
        message: "Error with your login or password"
      }, status: 401
    end
end

api / registrations_controller.rb

class Api::RegistrationsController < ApiController
  skip_before_filter :verify_authenticity_token

  def create
    user = User.new(user_params)
    if user.save
      render(
        json: Jbuilder.encode do |j|
          j.success true
          j.email user.email
          j.auth_token user.authentication_token
        end,
        status: 201
      )
      return
    else
      warden.custom_failure!
      render json: user.errors, status: 422
    end
  end
end

并在config / routes.rb中

  namespace :api, defaults: { format: "json" } do
    devise_for :users
  end

我有点不合常理,而且我确定这里有些事会让我未来的自我回顾并畏缩(通常是这样)。一些困难的部分:

首先,您会注意到Api::SessionsControllerfrom的继承,Devise::RegistrationsController而from的Api::RegistrationsController继承ApiController(我还有其他一些控制器,例如Api::EventsController < ApiController用于处理其他模型的更多标准REST东西,而与Devise的联系并不多。)这是一个非常丑陋的安排,但我想不出另一种方法来访问所需的方法Api::RegistrationsController。我上面链接的教程的内容是include Devise::Controllers::InternalHelpers,但该模块似乎已在Devise的最新版本中删除。

其次,我禁用了该线路的CSRF保护skip_before_filter :verify_authentication_token。我对这是否是一个好主意感到怀疑-我看到关于JSON API是否易受CSRF攻击的很多冲突难以理解的建议-但添加这一行是使该死的事情起作用的唯一方法。

第三,我要确保我了解用户登录后身份验证的工作原理。假设我有一个API调用GET /api/friends,该调用返回当前用户的朋友列表。据我了解,iOS应用程序必须authentication_token从数据库中获取用户的身份(这是一个永远不变的用户的固定值?),然后将其作为参数与每个请求一起提交,例如GET /api/friends?authentication_token=abcdefgh1234,那么我Api::FriendsController可以就像User.find_by(authentication_token: params[:authentication_token])获得current_user一样。真的这么简单吗,还是我错过了什么?

因此,对于所有设法阅读完这一庞然大物的读者,感谢您的宝贵时间!总结一下:

  1. 这个登录系统安全吗?还是有我忽略或误解的东西,例如涉及CSRF攻击?
  2. 我了解用户登录正确后如何对请求进行身份验证吗?(请参阅上面的“第三...”。)
  3. 有什么办法可以清除或改进此代码?特别是一个控制器继承于Devise::RegistrationsController其他控制器的丑陋设计ApiController

谢谢!


Api::SessionsController的延伸是Devise::RegistrationsController..
科恩。

Answers:


58

您不想禁用CSRF,我已经读到人们认为出于某种原因它不适用于JSON API,但这是一种误解。要使其保持启用状态,您需要进行一些更改:

  • 在该服务器端,将一个after_filter添加到您的会话控制器中:

    after_filter :set_csrf_header, only: [:new, :create]
    
    protected
    
    def set_csrf_header
       response.headers['X-CSRF-Token'] = form_authenticity_token
    end
    

    这将生成一个令牌,将其放入您的会话中,然后将其复制到所选操作的响应标头中。

  • 客户端(iOS),您需要确保已完成两件事。

    • 您的客户端需要扫描所有服务器响应以查找此标头,并在传递时保留它。

      ... get ahold of response object
      // response may be a NSURLResponse object, so convert:
      NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse*)response;
      // grab token if present, make sure you have a config object to store it in
      NSString *token = [[httpResponse allHeaderFields] objectForKey:@"X-CSRF-Token"];
      if (token)
         [yourConfig setCsrfToken:token];
      
    • 最后,您的客户需要将此令牌添加到它发出的所有“非GET”请求中:

      ... get ahold of your request object
      if (yourConfig.csrfToken && ![request.httpMethod isEqualToString:@"GET"])
        [request setValue:yourConfig.csrfToken forHTTPHeaderField:@"X-CSRF-Token"];
      

难题的最后一步是了解登录进行设计时,正在使用两个后续的session / csrf令牌。登录流程如下所示:

GET /users/sign_in ->
  // new action is called, initial token is set
  // now send login form on callback:
  POST /users/sign_in <username, password> ->
    // create action called, token is reset
    // when login is successful, session and token are replaced 
    // and you can send authenticated requests

谢谢,这真的很有帮助。因此,我是否正确地认为,登录后,我需要auth_token从响应中获取,然后将其与随后的请求一起传递以验证该用户身份?
GMA 2013年

如果您修改客户发送我的请求(非GET)的方式,这将自动完成。顺便说一句,所有这些都假设您使用了devise的默认基于会话的身份验证。如果您使用令牌进行身份验证,则需要其他登录流程,不确定那里的详细信息。
beno1604 2013年

1
因此,要澄清一下,这是怎么回事?1)iOS应用程序调用GET /users/sign_in并获取CSRF令牌。2)它POST /users/sign_in使用刚收到的CSRF令牌进行提交,并获得一个新的CSRF令牌。这也将cookie保存在iOS应用程序上并创建一个新会话。3)对于所有将来的请求,iOS应用程序使用cookie进行身份验证,此外,它还包括CSRF令牌,以保护非GET请求。我对吗?
GMA 2013年

是的,基本上就是这样。为了澄清起见,cookies /会话在匿名状态和登录状态中都被使用。
beno1604 2014年

1
如果您根本不使用Cookie /会话,该怎么办?您为何比CSRF更关心?只需要关心XSS就可以了。
如果__name__为None

3

你的例子似乎模仿从设计博客的代码- https://gist.github.com/josevalim/fb706b1e933ef01e4fb6

如该帖子所述,您的操作类似于选项1,他们说这是不安全的选项。我认为关键是您不想每次保存用户时都简单地重置身份验证令牌。我认为令牌应显式创建(通过API中的某种TokenController)并应定期过期。

您会注意到我说“我认为”,因为(据我所知)没有人对此有更多信息。


0

OWASP Top 10中记录了Web应用程序中最常见的10个最常见的漏洞。这个问题提到跨站请求伪造(CSRF)保护已禁用,并且CSRF处于OWASDP前10名中。简而言之,攻击者使用CSRF以经过身份验证的用户身份执行操作。禁用CSRF保护将导致应用程序中的高风险漏洞,并破坏拥有安全身份验证系统的目的。由于客户端无法通过CSRF同步令牌,CSRF保护很可能失败了。

阅读整个OWASP前10名,否则将非常危险。密切关注断开的身份验证和会话管理,并查看会话管理备忘单


9
这些如何应用于RESTful API?RESTful API不使用会话!黑客必须针对API使用JavaScript调用,而API则必须访问HTTP本地存储或网站Cookie,这实际上需要在您的网站上获取恶意脚本,这时似乎有许多更简单的方法攻击系统。
RonLugge 2014年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.