セッションハイジャックを防止する

私が言いたいことを詳しく説明します。

ユーザー A が example.com にログインした後、簡単のために 'abc123' とする、いくつかのランダムなセッション ID が与えられます。このセッション ID はクライアント側の Cookie として保存され、サーバー側のセッションで検証され、ログインしたユーザーがある Web ページから別の Web ページに移動してもログインしたままであることを保証するために使用されます。もちろん、HTTPがステートレスでなければ、このクッキーは存在する必要がない。そのため、もしユーザーBがユーザーAのSIDを盗み、彼のコンピュータに「abc123」という値のクッキーを作成すると、彼はユーザーAのセッションを乗っ取ることに成功しますが、サーバーがユーザーBのリクエストがユーザーAのリクエストと異なることを正当に認識する方法がないため、サーバーにはリクエストを拒否する理由がないだけなのです。たとえ、サーバ上で既にアクティブになっているセッションをリストアップし、誰かが既にアクティブになっているセッションにアクセスしているかどうかを確認しようとしたとしても、それがセッションに不正にアクセスしている別のユーザであって、既にセッションIDでログインしていて、単にそれを使って別のリクエストをしようとしている(すなわち別のウェブページに移動する)同じユーザではないことをどうやって判断するのでしょうか? できません。ユーザーエージェントをチェックする？なりすましの可能性はありますが、それでも深層防護対策としては有効です。IPアドレスは？しかし、IP アドレスをまったくチェックしないのではなく、IP の最初の 2 オクテットをチェックすることをお勧めします。データプラン ネットワークのユーザーで、完全に正当な理由で常に IP を変更している場合でも、通常は IP の最後の 2 オクテットが変更されるだけです。

結論として、ステートレス HTTP は、セッションの乗っ取りから Web サイトを完全に保護することはできませんが、（Gumbo が提供したような）優れた実践は、セッション攻撃の大部分を防ぐのに十分でしょう。同じ SID の複数のリクエストを拒否することによってセッションをハイジャックから保護しようとすることは、単に馬鹿げており、セッションの目的全体を破壊することになります。

どのように解決するのですか?

残念ながら、本物のリクエストとは逆に、攻撃者から発信されたリクエストを明確に識別する効果的な方法はありません。なぜなら、IP アドレスやユーザー エージェントの特性など、対策がチェックするほとんどの特性は信頼できないか (IP アドレスは複数のリクエストの間で変わる可能性があります)、簡単に偽造できる (例. ユーザーエージェント リクエストヘッダなど) のようなほとんどの特性は信頼できないか、あるいは簡単に偽造できるため、望ましくない偽陽性 (つまり本物のユーザが IP アドレスを交換した) や偽陰性 (つまり攻撃者が同じ ユーザーエージェント ).

そのため、セッションハイジャックを防ぐ最良の方法は、攻撃者が他のユーザーのセッションIDを知ることができないようにすることです。これは、(1) 攻撃者が十分なエントロピーを使用して有効なセッション ID を推測できないように、また (2) ネットワーク通信のスニッフィング、クロスサイトスクリプティング、 を介した漏洩などの既知の攻撃/脆弱性によって攻撃者が有効なセッション ID を取得する他の方法がないようにアプリケーションとそのセッション管理を設計しなければならないということを意味します。 リファラー など。