問題タブ [session-hijacking]

ユーザーのセッションが作成される前にsession_regenerate_id()を使用することが常に推奨されるのはなぜですか。私の認識では、ユーザー セッション ID が作成されたら、session_regenerate_id() を使用する必要があり、ハッカーによるセッション固定攻撃を軽減するために、それを再生成する必要があります。

提案してください！！

セッションハイジャックを防ぐために、ユーザーエージェントとIPアドレス の変数に基づいて、各ユーザーに特定のCookie名を割り当てようとしました。

次の関数を使用して、セッションIDを保持するセッションCookie名を生成しました。

これは、私のWebサイトにアクセスするすべてのユーザーが、異なるセッションCookie名を持つことを意味します。ハイジャック犯が自分のユーザーエージェントを被害者のユーザーエージェントに変更しない限り、他人のCookieを使用することをブロックします。ユーザーのインターネットモデム、ルーター、NATなどを使用するなど、被害者のIPアドレスを使用してオンラインで表示しようとします。

例を使って説明しましょう。したがって、2人のユーザーが同じブラウザを使用し、同じIPアドレスから接続する場合、同じCookie名を取得します（f5e30acc605e938b097dee73c0272470と想定）。

これで、スクリプトはこれら2つのクライアントでf5e30acc605e938b097dee73c0272470という名前のCookie内のセッションIDを探します。この状態では、クライアントの1つが他のCookieを乗っ取ることができます。同じIP、同じユーザーエージェント、そして同じCookie名！

この方法は良いですが、完全に安全ではありません。ユーザーエージェントの変更はそれほど難しくありません。被害者とハイジャック犯は、コフェネットやパブリックホットスポットなどのパブリックネットワークから接続する場合、同じIPアドレスを持っている可能性があります。

特に「RememberMe？」を使用する場合は、攻撃者がそうすることを拒否することが重要です。長期的なセッションCookieを生成するオプション。

誰かがこの問題について提案がありますか？

私が調査したところ、解決策の1つはSSLと安全なCookieを使用することでした。しかし、SSLを使用しないソリューションを探しています。

ユーザーがログインした後のセッションハイジャックを回避するには、ログインプロセス中に、実際に正当なユーザーであることを検証するためにどのような情報を信頼できますか。中継するセッションを傍受した人が無効になるように

彼らのIPアドレスとブラウザ情報はそれで十分ですか？

私はsuPHPをよりよく理解しようとしています。

私は明らかにグーグルでsuPHPのドキュメントを見つけ、それが何であるか、そして何をするかについての一般的な答えを見つけましたが、それがセッションセキュリティとセッションハイジャックの防止にどのように役立つかについて混乱しています。

誰かが私のためにこれを明確にすることができれば、私は感謝するでしょう。グーグルは良い結果を出していない！

重複の可能性：
セッションハイジャックの防止

Webアプリケーションのログインおよび認証システムをコーディングしており、PHPセッションハイジャックを防ぐためのベストプラクティスを探しています。ログインページセットのセッション：

次に、すべてのページとアクションで、セッションが存在し、セッションに格納されているIPアドレスが$_SERVER['REMOTE_ADDR']のIPアドレスと一致していることを確認します。

ただし、オンラインで読むと、IPアドレスを確認するだけでは不十分だと言う人もいます。他に何が必要ですか？また、を使用するという話もありsession_regenerate_id()ます。それは私のコードにどのように影響しますか？session_regenerate_id()すべてのページに電話しますか？

ありがとう。

ユーザーが現在のセッションにログインすると、変数が設定されます

私の common.php ページ (すべての php ページで必要) で、以下のスクリプトを使用しました。これは、ユーザーがアクティブになるたびに 15 分のタイマーをリセットし、さらに IP アドレスをチェックし、user_agent をチェックします。彼らが最初にログインしたとき/セッションが最初に設定されたとき、セッションはさらに設定解除され、最大15分間非アクティブで、セッションも設定解除されます。

...私が行ったことは、セッションハイジャックを防ぐための良い方法ですか?それは安全ですか?それとも十分ですか? そうでない場合、これ以上何ができるでしょうか？

私のサイトの1つで、ini_set('session.use_trans_sid', 1)Cookieを持たないユーザーがサイトを使用できるように設定しました。これは、URLを介してセッションを追跡します。

ただし、セッションが簡単に乗っ取られる可能性があるという深刻なセキュリティ問題が発生しています。

基本的に、GooglebotはCookieを使用しないため、Googleはクロール時に指定されたセッションIDを使用してページのインデックスを作成しています。

次に、誰かが私のサイトを検索し、古いセッションURLを含むGoogleの検索結果をクリックすると、その古いセッションIDが（新しいセッションIDではなく）セッションIDになります。

したがって、そのユーザーがログインすると、そのユーザーのアカウントは、Google全体でインデックス付けされたセッションIDを使用してログインします。つまり、他のユーザーが私たちのサイトを検索し、Googleで検索結果のいずれかをクリックすると、他のユーザーのアカウントに自動的にログインします。

巨大なセキュリティホールについて話してください！

どうすればこれを修正できますか？PHPはセッションIDが無効である（または存在しない）ことを認識してから新しいIDを生成すると思っていたのですが、そうではないようです。そうすれば、この問題は修正されるようです。

助けてください！

編集：

ここで本質的に起こっていることは、PHPでは、URLにセッションIDパラメータに必要なものを入力するだけで、誰でも独自のカスタムセッションIDを作成できるようになり、PHPはそれをセッションIDとして使用し始めます。URLで文字通りSessionID = "securityflaw"を作成でき、ログイン後も文字通りそれをセッションIDとして使用します。したがって、誰かがGooglebotの古いセッションIDを使用してGoogleのリンクをクリックすると、PHPはユーザーに「カスタム」セッションIDを作成します。確かに何かがおかしい！

私はこのコードを持っています:

すべて正常に動作します。しかし、ログインするたびに (24 時間に 1 回)、エラーが発生します。ユーザーエージェントの変更か何かですか？

ご協力いただきありがとうございます。

バックグラウンド ストーリー:私たちは数千人のユーザーと少数の管理者がいる Web サイトを運営しています。これらの管理者の一部は、Web サイトへのすべてのアクセスを必要としないため、個別の権限を付与してアクセスを制限したいと考えています。

私の計画は、ユーザーのアクセス許可があれば、ユーザーのログイン時にセッションを設定することです。しかし、これは危険な行為ではないかと心配しています。

セッションはユーザーのクライアント側で操作できますか? この場合、通常のユーザーは、パーミッション名を知っていて自分用にセッションを設定すれば、管理機能にアクセスできます。

Stackoverflow で関連する質問をいくつか見つけましたが、この件に関する十分な情報が得られませんでした。

先日、とても奇妙で恥ずかしいことが起こりました。何が起こったのかを説明する言葉がありません。

私のアプリは、すべてTomcat7でJSF2.1、Hibernate 4、SpringSecurityと統合されたSpring3を実行します。私は経営幹部レベルの重要な人物と電話をしていて、同じページで同時にテスト環境にいました。彼は、彼のページが私の個人アカウントの詳細を思いついたのとほぼ同じ瞬間に、私がナビゲートしていたページにナビゲートしに行きました。私は彼を信じていなかったので、私は彼のオフィスに歩いて行きました、そして確かに、彼はどういうわけか彼がパスワードを持っていない私のアカウントとしてログオンしました。

アプリケーションは患者の健康情報を保護するため、経営幹部レベルに何が起こったのかを完全に報告するように命じられましたが、これがどのように可能であったかがわかりません。私はコードベースを精査し、何も思いつきませんでした。正確なシナリオを何度も再現しようとしましたが、再現できませんでした。私は私が満足しているという知識に基づいた推測さえ持っていません。

Tomcatアプリケーションコンテキストの実装に保存されているセッションで安全でないスレッド操作があった可能性があると思いますが、再現できない場合はこれを証明する方法がありません。また、Spring Securityは他のリクエストよりも先にフィルターとして機能し、転送するため、おそらく他のサーブレットフィルターの1つが干渉したと思いました。他の2つは、最近追加したPrimefacesFileUploadフィルターとOmnifacesSEOフィルターでした。

Omnifacesフィルターは、実際にはPrimefaces File Uploadフィルターと干渉し、2つが互いにうまく機能するように構成を調整する必要があったので、それも可能性があると感じています。

同様の問題を引き起こしているSpringSecurityの既知のバグはありますか？ApplicationContextから誤って間違ったセッション状態を提供することに関してTomcatに既知の問題がありますか？他の誰かが同様の問題を経験したか、これについていくつかのユニークな洞察を持っていますか？

編集：これを投稿した直後に私はこれを見つけました、ほんの数日前に投稿しました：

セッションの取り違え-Apachehttpdとmod_jk、tomcat、springsecurity-他のユーザーのデータを提供

これは、Tomcatの前にApache httpd + mod_jkプラグインがあるのとほぼ同じセットアップなので、私は夢中ではありません:)

アップデート：

mod_jkまたはApacheを前面に配置しなくても、開発環境で問題を再現できたため、これを原因として確実に除外できます。