0

ログインスクリプトに取り組んでいます。ユーザーが正常にログインしたら、$_SESSION['logged_in'] = TRUE;

次に、他のページをチェックします。そう$_SESSION['logged_in'] = TRUE;であれば、適切なコンテンツを表示します。

すべて正常に動作しますが、現在はセキュリティを強化しています。ログイン時にデータベースに保存されているsession_idユーザーと現在のユーザーのを確認することは有益ですか?session_idこれは、セッションハイジャックを防ぐのに役立ちますか?そうでない場合、私が取るべき他の予防策はありますか?

4

1 に答える 1

3

いいえ、セッションIDをDBに保存されているものと照合することは有益ではありません。セッションがハイジャックされた場合、それはハイジャッカーセッションIDを持っていることを意味します。したがって、DBと照合すると、ハイジャッカーが有効なセッショントークンを持っていることがわかります。

nokoが言ったように、IPをチェックすることもできますが、それは保存する必要がある他のことであり、すべての要求に対して行う必要がある他のことです。ユーザーエージェントをチェックすることは無意味でしょう。

セッションハイジャックを防ぐためにできる最善のことは次のとおりです。

  1. ログインフォームとユーザーがログインした後のすべてのページにTLS/SSLを使用します。理想的には、すべてにTLS/SSLを使用するのが最善です。
  2. ユーザーがログインした後、セッショントークンをローテーションします。ユーザーがログインする前にユーザーのsession_idが侵害された場合でも、ユーザーがログインした後も侵害されます。
  3. 十分にランダムなセッショントークンを使用していることを確認してください。これにより、推測が困難になり、セッション管理に対するブルートフォース攻撃が非常に困難になります。

更新:(要求に応じて)#3について詳しく説明するために、OWASPセッション管理のチートシートから引用して参照します

セッションIDは、ブルートフォース攻撃を防ぐのに十分な長さである必要があります。ブルートフォース攻撃では、攻撃者はID値の全範囲を調べて、有効なセッションの存在を確認できます。セッションIDの長さは、少なくとも128ビット(16バイト)である必要があります。

推測攻撃を防ぐために、セッションIDは予測不可能(十分にランダム)である必要があります。攻撃者は、統計分析手法を通じて有効なセッションのIDを推測または予測できます。この目的のために、優れたPRNG(疑似乱数ジェネレーター)を使用する必要があります。セッションID値は、少なくとも64ビットのエントロピーを提供する必要があります(適切なPRNGが使用されている場合、この値はセッションIDの半分の長さであると推定されます)。

于 2012-08-23T00:40:35.643 に答える