ユーザーがセッション情報を変更して他人になりすますことはできませんか？
攻撃者が自分のセッション（またはローカルに保存されているためCookie）の情報を変更して、正当なユーザーであるサーバーを騙すことはできませんか？
たとえば、WebサイトがデータベースIDを識別子として使用している場合、攻撃者は自分のアカウントにログインしてCookieを取得します。次に、IDを変更して、別の正当なユーザーになりすます。
はい、別のユーザーのセッションキーを推測できる場合は、そのユーザーになることができます。これが、取り消すことができる予測できないセッションキーが必要な理由です。
ベストプラクティスが守られていない場合があります。たとえば、Moonpigは、アカウントの作成時に設定されるユーザーのIDであるセッションキーを連続番号として使用するAPIを作成しました。これは、あなたがどんなユーザーになることもできることを意味しました。そのユーザーがあなたを止めたい場合、それは彼らが従事しているすべてのセッションのキーであり、Moonpigデータベース内のユーザーの一意のIDであるため変更できません。
これは、それを間違って行う方法の本当に良い例です。セッションキーは予測不可能で、破棄できる必要があります（1人のユーザーが多くのセッションキーを持つことができる可能性があります）。
@Mindwinがコメントで述べたように、セッションキーはHTTPペイロード（Cookieまたはフォームデータ[ベストプラクティスはCookieにあります]）内にあり、URL内にはない必要があります。これは、URLにセッションデータがあると、すべてのリンクのURLにデータを配置する必要があるため、ユーザーが離脱して戻ってきた場合にセッションを永続化し、URLをコピーして誰かに送信すると、セッションが提供されるためです。データと、URLに含めることができる文字の制限があります。
また、攻撃者がHTTPペイロードを覗き見してセッションキーのコピーを取得できないように、可能な限りHTTPSを使用する必要があります（これがFiresheepの動作方法です）。
はい。できる。
セッション情報はサーバー側（セッショントークンを除く）に保存されますが、Cookieはクライアント側（ブラウザ）に保存されます。そのため、攻撃者はセッショントークンを変更してセッションをハイジャックする可能性があります。
この攻撃は、一般にCookie操作によるセッションハイジャックとして知られています。ただし、攻撃者は有効な セッショントークン を使用する必要があります。これは、サイトの構成が不適切な場合に簡単に見つけることができます。不適切に構成されたサイトは、URLにトークンを格納するか、ランダムなトークンを生成しない可能性があります...
セッションをハイジャックするために使用される4つの主な方法を次に示します。
- Session fixation -URLからセッションIDが受け入れられている場合。
- セッションのサイドジャック-攻撃者がパケットスニッフィングを介してセッションCookieを盗む場合
- クロスサイトスクリプティング -攻撃者がユーザーのコンピューターをハッキングして、サーバーに属しているように見えるため信頼できると見なされるコードを実行し、攻撃者がCookieのコピーを取得したり、その他の操作を実行できるようにする場合オペレーション。
- マルウェア-ユーザーの知らないうちにブラウザを乗っ取り、Cookieファイルを盗むことができる.
保護するベストプラクティスは、セッショントークンをCookie内に格納することです。ただし、セッショントークンがランダム性、一意性、統計分析や暗号分析への耐性などの強力な基準に一致しない場合、攻撃者がセッションを操作する可能性があります。
ここでCookeisとセッション情報の間にはいくつかの混乱があるようですので、それを整理することから始めましょう：
Cookiesはクライアントに保存されます。したがって、ユーザーは必要に応じてそれらを変更できます。
セッション情報はサーバーに保存されます。つまり、ユーザーは変更できません。
「クライアントを信頼しない」は、セキュリティにおける古いルールです。つまり、ユーザー名のCookieの値が「Alice」であるからといって、「Mallory」がログインしたユーザーではなかったという意味ではありません。
そのため、重要な情報は通常、クライアントのCookieには保存されず、サーバーのセッションに保存されます。次に、セッションIDを含むCookieを使用して2つを接続します。セッションIDは長い乱数です。 AliceセッションIDが20349023490324サーバーには、その番号でファイルされたすべてのセッション情報（ユーザー名など）があります。
ユーザーはセッションIDを変更できますが、可能なセッションIDが非常に多いため、実際にユーザーに接続されているIDを推測することはほとんどありません。
とにかく、Cookieにデータを保存したい場合があります。ユーザーがそれらをいじるのを防ぐために、サーバー上にのみ持っているキーで署名することができます。ユーザーにはキーがないため、署名が一致しなくなるため、サーバーはCookieへの変更を検出できます。
セッションIDは、簡単に推測できないという意味で、暗号的に安全である必要があります。通常、これはランダムに見える128ビットの数値であり、識別しているユーザーとの明確な関係はありません。したがって、他のユーザーになりすますには、そのユーザーのIDを見つける必要があります。それを行う方法はいくつかありますが、他の誰かになるように「変更」するだけでは異なります。
ただし、サーバーには、実際のユーザー情報とそのユーザーに属するセッションIDを照合するテーブルがあり、その情報を使用できます。ただし、ブラウザに保存されているセッションIDを見ただけでは、他人のセッションIDを知ることはできません。
非常に多くの回答が、セッションIDにランダム性、一意性、統計的分析および暗号化分析への抵抗などが含まれている場合は問題ないと述べているようです。これは実際には当てはまりません（完全ではない場合など）。 Cookie（そのIDを含む）は、攻撃者が文字通り傍受して再利用できるため、推測する必要はありません。また、プロキシーまたはdmzパススルーシステムがcookieを混同することはまれですが可能性のあるインスタンスです（私はそれを確認しました）。このため、上記に加えて、アプリケーション自体に次のようなことを実行させる必要があるでしょう。
ログイン時に、システムにサーバー側セッションのリクエストのユーザーエージェントとIPアドレスを保存させます。後続のすべてのリクエストを確認し、ipとuser-agentの受信値がセッションに保存されている値と一致することを確認します。そうでない場合は、サーバー側のセッションを無効にし、ログイン画面にリダイレクトします。これにより、ハイジャッカーが侵入するのを防ぎます。許容可能な副作用として、正当なユーザーも追い出されます（ハイジャックの試みが発生した場合のみ）が、彼らは単に再度ログインすることができます。