サインイン時に生成された署名付きのCookieを使用して、ActionCableで現在のユーザーを識別することは安全ですか？

Question

私はRails 5でActionCableについて学ぶためにインスタントメッセージングアプリケーションを作成しています。ユーザーがチャンネルに安全に接続してストリームする方法を理解しようとしています。

ユーザーが購読すると、ユーザーIDで指定されたチャンネルからストリームが配信されます。このユーザーIDは、ユーザーがアプリにサインインしたときに生成された署名付きのCookieから取得されます。 （すなわち、署名されたクッキーは、ユーザからストリームチャネルを指定するChatChannelでsubscribed方法で使用される順番であるcurrent_user変数にActionCable::Connectionにconnect方法で割り当てられる。）

私の質問は、広くこれがあるかどうかであります安全です。具体

：

• はそれが署名されたクッキーは、current_userを定義するために（そしてユーザからストリームどのチャネルを決定するために）使用されると仮定することがOKでは間違いなく、ユーザサインで生成された署名付きクッキーですか？それとも、サインインして、アプリケーションの外で生成されたCookieを使ってActionCable Connectionに接続することは可能でしょうか？この '接続'が通常のHTTPリクエストであった場合、ユーザーIDを含む署名されたCookieは、そのユーザーがリクエストを行ったことを証明するには不十分です。
• ActionCable Connectionを別のユーザーのIDに変更した後に誰かがcurrent_user変数を変更する可能性がありますか？そうすれば、別のチャンネルを購読できますか？
• ユーザーは、アプリケーションのインデックスアクション（メッセージングインターフェイスをレンダリングする）にアクセスするにはログインする必要がありますが、ログインすることなく、外部で生成された署名入りのCookieを使用してActionCable ConnectionにアクセスできますユーザーIDを含むアプリですか？ （App.cable.subscriptions.create "ChatChannel"はインデックスページをレンダリングするときに呼び出されますが、中に署名されていない誰かによって呼び出されることに対する保護が何であるのか？）

私は、ユーザーに署名する工夫を使用していて、ちょうどに追加していデフォルトのセッション方法はActionCableを設定するために使用される署名済みクッキーを生成する:: current_userを接続します

def create 
    super do |user| 
    cookies.signed[:user_id] = user.id if user_signed_in? 
    end 
end 

Answer 1

を私は今、答えを持っていると思います。

は、私は次のようにして、他のユーザーのメッセージをストリームすることができました：

ユーザーとして

• サインがuser_idの中の文字列は、ユーザB
• ようにクッキー
• ログに署名したコピー新しい署名付きクッキーを削除する
• JSコンソールで、ユーザーAのCookieからコンテンツとしてコピーされた文字列を使用してuser_idという新しいCookieを作成します。
• ページのJavaScriptをリロードしてActionCableに再接続するためにブラウザを更新:: Connectionインスタンス

だから、署名クッキーが別のユーザーの署名クッキー（またはその内容）を盗むために、ユーザのために、それは可能な限り安全ではありません。

実際には、サーバーのセッションIDに一致する暗号化されたセッションIDを持つCookieをユーザーが持っていなければならないサーバーのセッションにユーザーIDが存在することによって認証された通常のHTTP要求。基本的に、セッションクッキーはユーザーを認証するためのもので、クッキーを与えられたユーザーがブラウザーを介して新しい要求を行うユーザーであるという前提と同じくらい安全です。

したがって、クッキーまたはその内容を盗むことができるかどうかという疑問があります。内容は簡単に

を推測できないように暗号化されたクッキーを使用して

（そう、単一の盗難/偽造は一時的なアクセスを提供します）クッキーにユーザーがログインするたびに変更

• ：それはによって難しく行うことができますデータベースにクッキーの内容を保存しないでください。代わりにハッシュされたバージョンを保存します（ユーザーIDを使用するだけではなく、各ユーザーのハッシュされたトークンを保存することを意味します）。各ユーザーへのユニークな参照を保証するためのユーザーID
• ユーザーIDとトークンをCookieに割り当てて、同じ理由でデータベース全体に存在するパスワードを推測するのは個人のパスワードを推測するよりも簡単です

Answer 2

私はActionCableのドキュメントでこれを見つけ出し、ユーザーIDだけを使用しましたいくつかの警鐘を発したものを認証する！

個人的に私は署名されたクッキーにユーザーIDを保存し、一定時間後にログアウトするとトークンが失効します。しかし、私から追加する最も重要なことは、SSLがサイト全体に確実にインストールされるようにすることです。

セッションハイジャックの最も基本的なタイプ、つまり、セッションキーを取得するためにパケットスニッファを使用する公開されている安全でないネットワーク上の誰かが、サイト全体にわたって正しくインストールされたSSL証明書によって軽減される必要があります。

攻撃者がマシンにアクセスしてセッションクッキーとその他のクッキーを取得できる場合は、ログイン時の有効期限を設定するとおそらく最善の方法です限界ダメージ。

また可能性：

• は、それが同じ場所（なりすましにはまだ脆弱な）から来るのを確認するために、各リクエストのIPを確認します。
• ブラウザのユーザーエージェントを確認して、同じマシンとブラウザの種類（スプーフィング）であることを確認します。
• ユーザーを一度に1つのセッションに制限します。

しかし、これらのオプションはあまり効果的ではなく、ユーザーエクスペリエンスに影響を与える可能性があります。ユーザーが基本的なクライアント側のセキュリティを配置していない場合は、このようにしてください。そのOSでパスワード保護のようなものや悪意のある人物がマシンに侵入された場合、残念なことに違反の責任はあなたのものではなく自分たちの肩にあります。

私は最も人気のあるセッションベースのサイトがこれに対処し、セッションハイジャックがいかに簡単だったかを知りたがっていましたので、Facebookが何をやっているかを見てきました。ユーザー;