1

WebLogic アプリケーションのデバッグ中に、ユーザーがログアウトしても JSESSIONID が変わらないことに気付きました。

これが私が心配する必要があるものかどうかを理解しようとしています。

このアプリケーションは、WebLogic インスタンス内で実行されている 2 つのアプリケーションのうちの 1 つで、どちらも同じ JSESSIONID を共有していることに気付きました。

この質問は、以下を参照しています。

SRV.7.3 セッション スコープ

HttpSession オブジェクトは、アプリケーション (またはサーブレット コンテキスト) レベルでスコープを設定する必要があります。セッションの確立に使用される Cookie などの基礎となるメカニズムは、異なるコンテキストで同じにすることができますが、参照されるオブジェクト (そのオブジェクトの属性を含む) は、コンテナーによってコンテキスト間で共有されてはなりません。

これは、最終的にこれらの JSESSIONID 値を管理する方法を選択するのは WegLogic 次第であることを示唆しており、値の変化 (またはその欠如) から意味を解釈しようとするべきではありません。

HttpSessionListenerさらに、アプリケーションにを接続したところ、sessionDestroyedメソッドが呼び出されることがわかりました。

これら 2 つの要素を考慮すると、JSESSIONID が変更されていないことは安全だと思われます。ただし、これは私が慣れ親しんでいるものとは異なる動作であるため、私の仮定を確認したいと思います。

JSESSIONID が変更されないのはセキュリティ上の問題ですか?

4

1 に答える 1

3

いいえ、そのセッションに実際に関連付けられていたすべてのデータが破棄されるため、セキュリティ上の大きな問題にはなりません。はJSESSIONID、その (現在は存在しない) データへの鍵にすぎません。

JSESSIONIDただし、ログアウト/ログインごとに変更したい場合は、ログアウト機能を実装してJSESSIONID、ユーザーがログアウトしたときに Cookie を明示的に削除することができます。次に、サーバーは次のリクエストで新しいセッション/ID を割り当てます。

もちろん、ドキュメントに記載されているように、たまたま単一のJSESSIONIDCookie に依存している複数のコンテキストがある場合、1 つの Cookie を削除すると、実質的にすべての Cookie が削除され、サーバー上のすべてのコンテキストからユーザーが効果的にログアウトされます。実際には、それぞれが独自のログイン/セッション状態を持つ複数のユーザー向けコンテキストを持つことはあまり一般的ではありません。

于 2012-04-10T01:32:39.207 に答える