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を新たにインストールしてRailstutorialgitコードに攻撃を実行すると、まったく同じ問題に直面しました。セッションが正常にリセットされないということです。つまり、チュートリアルアプリはその種の攻撃に対して脆弱です。

コード（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メソッドを追加してrememberトークンをクリーンアップします。

class ApplicationController < ActionController::Base
  protect_from_forgery
  include SessionsHelper

  def handle_unverified_request
    sign_out
    super
  end
end
于 2013-02-05T15:42:08.027 に答える