75

複数のクライアントが同じセッションIDを使用しないようにするにはどうすればよいですか？Webサイトでのセッションハイジャックを防ぐためにセキュリティの層を追加したいので、これを求めています。ハッカーが何らかの方法で別のユーザーのセッションIDを見つけ出し、そのSIDを使用してリクエストを行った場合、サーバー上で単一のSIDを共有しているさまざまなクライアントがあることを検出し、ハイジャックの試みを拒否するにはどうすればよいですか？

編集

ステートレスHTTPプロトコルの制限により、私が求めていることは不可能であることに気付いたので、慎重に検討した結果、Gumboの回答を受け入れました。HTTPのおそらく最も基本的な原則が何であるかを忘れてしまいましたが、この質問について考えると、少し些細なことのように思えます。

私が何を意味するのか詳しく説明させてください：

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

結論として、セッションハイジャックからWebサイトを完全に保護できないことを非難するのはステートレスHTTPですが、セッション攻撃の大部分を防ぐには、グッドプラクティス（Gumboが提供するものなど）で十分です。したがって、同じSIDの複数の要求を拒否することによってセッションをハイジャックから保護しようとすると、単純にばかげており、セッションの目的全体が無効になります。

4

9 に答える 9

91

残念ながら、本物のリクエストとは反対に、攻撃者から発信されたリクエストを間違いなく識別する効果的な方法はありません。IPアドレスやユーザーエージェントの特性など、対策チェックに対応するほとんどのプロパティは信頼できない（IPアドレスは複数のリクエスト間で変更される可能性がある）か、簡単に偽造できる（User-Agentリクエストヘッダーなど）ため、不要な誤検知が発生する可能性があります（つまり、本物のユーザーがIPアドレスを切り替えた）またはフォールスネガティブ（つまり、攻撃者が同じUser-Agentでリクエストを正常に偽造できた）。

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

そうは言っても、次のことを行う必要があります。

  • セッションIDを生成するために十分なランダム入力を使用します（session.entropy_file、session.entropy_length、およびsession.hash_functionを参照） 。
  • HTTPSを使用して送信中にセッションIDを保護する
  • リファラーからの漏洩を防ぐために、セッションIDをURLではなくCookieに保存します（session.use_only_cookiesを参照） 。
  • HttpOnlyおよび属性を使用してCookieを設定し、SecureJavaScriptを介したアクセスを禁止し（XSSの脆弱性の場合）、安全でないチャネルを介した送信を禁止します（session.cookie_httponlyおよびsession.cookie_secureを参照） 。

さらに、特定のセッション状態の変更（ログイン後の信頼性の確認や認証/特権の変更など）後に古いID（session_regenerate_id機能を参照）を無効にしながらセッションIDを再生成する必要があります。これを定期的に実行して、期間を短縮することもできます。セッションハイジャック攻撃を成功させるため。

于 2012-09-02T08:45:42.353 に答える
5

このようなことはできますか？

セッションIDをデータベースに保存します。また、そのセッションIDのIPアドレスとHTTP_USER_AGENTを保存します。これで、一致するセッションIDを含むサーバーにリクエストが届いたら、スクリプトでどのエージェントとIPからリクエストが来ているかを確認します。

すべてのリクエストが処理される前に検証されるように、セッションに共通の関数またはクラスを作成することで、この基金を機能させることができます。数マイクロ秒かかることはほとんどありません。ただし、多くのユーザーがサイトにアクセスしていて、セッションの膨大なデータベースがある場合、これはパフォーマンスの問題ではない可能性があります。ただし、=>再生成セッションの使用などの他の方法と比較すると、確かに非常に安全です。

セッションIDの再生成では、セッションハイジャックの可能性はほとんどありません。

ユーザーのセッションIDがコピーされ、そのユーザーがしばらくの間作業またはアクティブでなく、古いセッションIDを持つサーバーに新しいセッションIDの再生成を要求する要求が行われなかったとします。次に、セッションIDがハイジャックされた場合、ハッカーはそのセッションIDを使用し、そのIDでサーバーに要求を行います。その後、サーバーは再生成されたセッションIDで応答し、ハッカーがサービスの使用を続行できるようにします。実際のユーザーは、再生成されたIDと、リクエストで渡されるリクエストセッションIDがわからないため、操作できなくなります。完全になくなった。

どこか間違っていたら訂正してください。

于 2014-06-17T14:13:34.857 に答える
4

セッションハイジャックに対する標準的な防御策はたくさんあります。それらの1つは、各セッションを単一のIPアドレスに一致させることです。

他のスキームでは、以下から生成されたHMACを使用できます。

  • クライアントのIPのネットワークアドレス
  • クライアントから送信されたuser-agentヘッダー
  • SID
  • サーバーに保存されている秘密鍵

IPのネットワークアドレスのみが使用される理由は、ユーザーがパブリックプロキシの背後にいる場合です。この場合、IPアドレスはリクエストごとに変更できますが、ネットワークアドレスは同じままです。

もちろん、本当に安全であるためには、そもそも攻撃者になる可能性のある人がSIDを傍受できないように、すべての要求に対してSSLを強制する必要があります。ただし、すべてのサイトがこれを行うわけではありません（:: cough :: Stack Overflow :: cough ::）。

于 2012-09-02T07:42:37.467 に答える
3

セッションハイジャックは深刻な脅威であり、トランザクションを含む高度なアプリケーションにセキュアソケットレイヤーを使用するか、上記で説明したようにCookie、セッションタイムアウト、IDの再生成などの簡単な手法を使用して処理する必要があります。
インターネットが誕生したとき、HTTP通信はステートレスになるように設計されていました。つまり、2つのエンティティ間の接続は、要求がサーバーに送信され、結果の応答がクライアントに返されるのに必要な短い期間だけ存在します。ハッカーがセッションをハイジャックするために従ういくつかの方法は次のとおりです

  • ネットワーク盗聴
  • 無意識の露出
  • 転送、プロキシ、フィッシング
  • リバースプロキシ

php.iniのグローバル設定を上書きするために、スクリプトの開始時にini_set（）ディレクティブに従う場合にも、SSL SecureSocketsLayer
を常に 使用することをお勧めします。

ini_set( 'session.use_only_cookies', TRUE );                
ini_set( 'session.use_trans_sid', FALSE );

セッションタイムアウトとセッション再生成IDを使用する

<?php
// regenerate session on successful login
if ( !empty( $_POST['password'] ) && $_POST['password'] === $password )         
{       
 // if authenticated, generate a new random session ID
  session_regenerate_id();

 // set session to authenticated
  $_SESSION['auth'] = TRUE;

 // redirect to make the new session ID live

 header( 'Location: ' . $_SERVER['SCRIPT_NAME'] );
}                   
// take some action
?>
于 2019-04-17T21:53:25.940 に答える
1

私の見解では、ユーザーがログインするときにセッションIDをデータベースに保存し、ログインする前に全員が同じかどうかを確認できます。ユーザーがログアウトするときにデータベースに保存したのと同じセッションIDを削除します。すべてのユーザーのセッションIDを簡単に見つけることができます。そうでない場合は、私がお手伝いします。

于 2012-09-02T04:41:47.577 に答える
1

簡単な実装の1つは、ログに記録されたユーザーとしてデータベースにテーブルを作成し、ログイン時にそのテーブルをユーザー名とそのSIDで更新することで実行できます。これにより、ログアウト時に同じユーザーとして他のログインができなくなります。データベースにログインしているデータを削除する簡単なクエリを実行するだけで、これを使用して、一度にurWebサイトにログインしているユーザーを追跡することもできます。

于 2012-09-02T04:45:00.353 に答える
1

明らかに、ブラウザでセッションCookieを設定すると、そのCookieがリクエストで送信されます。これで、リクエストが来ると、サーバーはデータベースのセッションIDをチェックし、アクセスを許可します。これを防ぐには、エージェントとIPを保存することが重要です。これにより、サーバーをチェックする前に、乗っ取られる可能性のある一意のセッションIDではなく、一意のクライアントにセッションアクセスが許可されていることを確認します。

于 2014-06-18T07:44:54.627 に答える
0

コーディング部分についてはよくわかりません。だから私はあなたにこれを行うためのアルゴリズムを教えることができます。SSLなどを設定したり、セッションCookieをセキュアに設定したりhttpOnlyを設定したりすると、ユーザーがLANネットワークからセッションIDを盗聴した場合にのみ機能します（提供されたユーザーと攻撃者は同じLANにいます）。

したがって、ユーザーがアプリケーションに正常にログインしたら、Webアプリケーションのすべてのページに一意のトークンを設定し、サーバー側でこれを追跡することができます。そのため、有効なユーザーが特定のページにアクセスするためのリクエストを送信すると、そのページのトークンもサーバー側に送信されます。トークンは特定のセッションのユーザーに固有であるため、攻撃者がセッションIDを取得できたとしても、サーバーに有効なトークンを提供できないため、攻撃者はユーザーセッションを乗っ取ることができません。

于 2014-10-16T13:26:15.333 に答える
0

@Anandu M Das：

あなたが言及しているのは、各セッションIDでのセッショントークンの使用だと思います。このサイトでは、セッションでのトークンの使用について説明できます。

https://blog.whitehatsec.com/tag/session-token/

セッショントークンはXSS攻撃によって簡単に侵害されますが、これは決して使用されるべきではないという意味ではありません。つまり、サーバーのセキュリティの脆弱性によって何かが危険にさらされた場合、それはメソッドのせいではなく、その脆弱性を導入したプログラマーのせいです（HessonとRookの指摘を強調するため）。

適切なセキュリティ規則と慣行に従い、SQLインジェクションやXSSからサイトを保護し、すべてのセッションをHTTPSで管理する必要がある場合は、セッション内に保存されているサーバー側トークンを使用して、CSRFからの潜在的な攻撃を簡単に管理できます。また、ユーザーがセッションを操作するたびに更新されます（$ _POSTが送信されるなど）。また、セッションまたはそのコンテンツは、エンコードされていると思われる場合でも、URLに保存しないでください。

ユーザーのセキュリティが最優先事項である場合（そうあるべきです）、セッショントークンを使用すると、セッションのセキュリティを損なうことなく、より優れた、またはより高度な機能を提供できます。

于 2015-09-26T22:42:34.330 に答える