3

Omniauth を使用して、最初から認証を行おうとしています。

Ryan Bate のスクリーンキャストをフォローしました。しかし、実装を展開する前に、いくつか理解しておきたいことがあります。

彼のスクリーンキャストでは、次のようhelper_methodになっていapplication_controllerます。

helper_method :current_user

private

def current_user
  @current_user ||= User.find(session[:user_id]) if session[:user_id]
end

上記のコードは、 をチェックしuser_idます。

セッションが暗号化されている(そして Cookie に保存されている)ことは知っています。ただし、それらは読み取り可能ですが、変更することはできません。誰かが偽のセッションをハイジャックするのはどれほど難しいでしょうuser_idか? 誰もがゼロから、または「Cookie インジェクター」メソッド (そのようなものが存在する場合) を介して Cookie を作成するのを妨げているのは何ですか。

これらの Cookie がどのように保護されているかを理解しようとしています。

4

2 に答える 2

3

通常、セッションはサーバー側で保持され、Cookie を介してクライアントとの間でやり取りされるのはセッション ID だけです。実際のセッション データをその Cookie に保存すると、暗号化の程度に関係なく、主要なセキュリティ ホールになります。たとえば、安価でrot-13「暗号化」を使用した場合、ユーザーがデータをいじって を設定するのは簡単ですsuperuser=1。

しかし、セッション ID では、それは不可能です。サーバー側のデータを操作するために使用できる Cookie は何もありません。せいぜい、ランダムなセッション ID 値を送り返し、他の誰かのセッションをハイジャックしようとする程度です。ID ハッシュが十分に大きい場合、ハイジャックする別のセッションを見つける可能性はほとんどありません。

于 2013-02-14T15:07:03.983 に答える
1

あなたが提供したリンクが最良の答えを与えると思います。また、機密性の高いアプリケーションについては、私がより懸念している、はるかに陰湿な攻撃を多数カバーしています。

Rails では、Cookie はサーバーによって署名され、送信された Cookie は署名が正しいことを確認するためにチェックされるため、セッション データを含む偽造または改ざんされた Cookie を送信することは非常に困難です。Cookie の値を変更するには、サーバーが Cookie に署名する際に使用する秘密鍵を知る必要があります。

ベスト プラクティスは、とにかくセッションに非常に小さなビット (できれば ID) のみを保存することです。誰かがユーザー ID を含むセッション Cookie を最初から作成できることを懸念している場合、簡単な答えは次のとおりです。 .id を Cookie に含めます。代わりに、Cookie で ID として機能する各ユーザーの GUID を生成します。このようにして、ユーザーの ID を知っていると、攻撃者が有用な Cookie を偽造できるようになることを恐れずに、URL で user.id を公開できます。

于 2013-02-15T12:41:13.263 に答える