1

在玩了几个星期的 rails 应用程序并完成了 rails 教程之后，我想了解一些 web 应用程序中常见的 web 攻击。

我设法使用 .html 文件中的以下代码块执行 CSRF 攻击类型。

<form action="http://localhost:3000/users/2" method="post">
  <input type="hidden" name="_method" value="delete">
  <div>
    <input type="submit" value="Delete">
  </div>
</form>

以管理员身份登录后，我对自己的代码运行了攻击，该代码基于与 Railtutorial 相同的会话机制，并且我成功删除了由于缺少真实性令牌而应该停止的用户。

默认行为应该是会话重置，从而防止用户在 Web 应用程序之外被删除。

我可以在日志中看到“无法验证 CSRF 令牌真实性”，但会话未重置。

覆盖 handle_unverified_request 方法，默认情况下应该重置会话，使用

def handle_unverified_request
  raise(ActionController::InvalidAuthenticityToken)
end

错误得到正确提出。

从全新安装的 railstutorial/sample_app_2nd_ed 对 Railstutorial git 代码运行攻击，我遇到了完全相同的问题：会话未按应有的方式重置。这意味着教程应用程序容易受到这种攻击。

我深入研究了代码（http://api.rubyonrails.org/classes/ActionDispatch/Request.html#method-i-reset_session），但无法弄清楚为什么在上下文 Railstutorial 中它似乎不起作用。

任何人都可以验证，如果 tutiral 确实容易受到 CSRF 攻击？如果是，解决方案是重写handle_unverified_request 以在这种情况下进行正确的注销？最后为什么它不能正常工作？

谢谢你的帮助。

4

1 回答 1

0

如果无法验证 CSRF 令牌，我知道如何强制用户注销。

这似乎与我们清空会话而不是 cookie 的记住令牌这一事实有关。

在您的应用程序中覆盖 handle_unverified_request（以便所有控制器从中受益）并添加 sign_out 方法来清除记忆令牌。

class ApplicationController < ActionController::Base
  protect_from_forgery
  include SessionsHelper

  def handle_unverified_request
    sign_out
    super
  end
end
于 2013-02-05T15:42:08.027 回答