セッションにuser_idを格納するのは危険ですか？

Question

ユーザーがログインに成功すると、セッションにアクセスするためのuser_idが表示されます。しかし、問題は、ユーザー/ハッカーが私が割り当てられた後に変更することができますか？私はuser_idを使用してデータベースを照会および挿入し、このuser_idを使用してすべての照会を実行します。これが危険で安全でない場合は、他に何ができますか？ありがとうございました。

Answer 1

あなたはあなたが本当にセッションID、いないユーザーIDについて話しているように聞こえる、「セッションにアクセスするためのuser_id」を持っているだろうと言います。基本的に、これは成功したログイン時に設定するCookieであり、サーバーはCookieを使用して適切なセッションを検索します。

注意：セッションハイジャック。セッションIDを使用するのはかなり標準的なスキームです（通常はセッションIDと呼ばれ、ユーザーIDではありません）。しかし実際にどのように実装されているかによって異なります。一般的に、アプリケーションサーバーは、コードを自分でコード化するのではなく、自動的に処理するようにしたいと思っています。たとえば、セッションIDが推測可能な場合、あなたのアプリはいわゆるsession hijackingという脆弱性があります。明らかにIDをシーケンスにすることは望ましくありませんが、それだけではありません。あなたはそれらをランダムにしたい、あなたはそれらがパターンを持っていないようにしたい（パターンがあるかどうかを判断するためのツールがありますが、必ずしも簡単ではありません）、セッションIDを生成する際に、通常、これはアプリの開発者がサポートするインフラストラクチャに委任するものです。

注意：セッション固定。その他のリスクの1つはsession fixationです。さまざまな種類がありますが、基本的な考え方は、誰かが既知のセッションID（Cookieを使用する代わりにURLにセッションIDが渡されたときに実行できる）をクリックするように欺くことです。彼は、例えばパブリック・フォーラムにリンクを掲示し、被害者はそれをクリックし、続いてセッションを認証する。攻撃者はセッションを引き継ぐことができ、彼は起動のために認証されます。 1つの対策は、認識されないセッションIDを受け入れて新しいセッションを開始するのではなく、クライアントから認識されないセッションIDを受け取ったときにアプリケーションが新しいセッションIDを生成するようにすることです。セッションIDを生成するための標準的な仕組みを使用している場合は、設定対策として、この対策を既に提供していることは保証されていますが、文書化されている可能性はあります。あなた自身で書くなら、それは誰もがほとんど間違いなく見過ごすであろう何かです。

セッションIDとユーザーIDを特定すると、セッションのハイジャックが発生します。他にもう一つ。あなたがセッションIDとユーザーIDとして二重の義務を果たすために単一のIDを使用している場合 - それをしないでください。まず、セッションとユーザーは概念的に異なるものです（セッションには関連ユーザーがありますが、ユーザーと同じではありません）。したがって、純粋なモデリングの観点からは正しくありません。しかしもっと重要なのは、ユーザIDは通常秘密ではなく、URL（ユーザが見ることができる）のようなものに現れます。セッションIDは間違いなく秘密です。たとえば、あなたのアプリにログインするたびに、「user_id = 14」というCookieを送信すると、誰かがあなたのアプリを見て、私がユーザー14であることに気づき、定期的にあなたのアプリに "user_id = 14"のクッキー遅かれ早かれ、彼らは私が実際にログインしていると同時にそれを行い、ボイラー、セッションハイジャックをするでしょう。

Answer 2

あなたはそれを取ることができる場所がたくさんありますが、表面にはあります。それはうまく聞こえる。 多くのサイトでは、ユーザーIDをCookieまたはセッションオブジェクトに格納しています。これを有効に活用しないためにベストプラクティスに従うようにしてください。

あなたが非常にconsuned場合は、常にそれを暗号化することができます。

デ