2

私はかなり古いJSPアプリケーション（JDK 1.3.1_15）を継承しており、セッション固定の穴を埋めようとしています。

を使用した認証後に現在のセッションを正常に無効にしていHttpSession.invalidate()ますが、新しいセッションが作成されると、古いセッションIDが再利用されます。

<%
// login.jsp
if (authenticated) {
    request.getSession().invalidate();

    // create new session and store data
    HttpSession session = request.getSession();
    session.putValue(...);
    // etc

    response.sendRedirect("logged-in.jsp");
    return;
}
%>

HTTPモニターで新しいセッションの割り当てを確認できます。これは、同じ番号を再び使用しているだけです。

-- Initial request response --
HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=6a303082951311647336934;path=/

-- login.jsp request response --
HTTP/1.1 302 Moved Temporarily
Location: http://example.com/logged-in.jsp
Set-Cookie: JSESSIONID=6a303082951311647336934;path=/

私の前session.invalidate()は、2番目のSet-Cookie応答ヘッダーを使用することはまったくありませんでした。

新しいセッションIDを生成する方法について誰かアドバイスはありますか？私はJRUN4にあまり精通していませんが、構成ドキュメントを調べても何も見つかりませんでした。

4

2 に答える 2

3

これを回避するには、2番目の非永続Cookieを使用して、値を制御できるセッションIDとして機能させることができます。アイデアは、一意のIDを生成し、それをCookieとセッションの両方に保存することです。このCookieを使用して、invalidateを使用してセッションで実行しようとしているのと同じロジックを実装します。具体的には、認証が成功するまで、将来のリクエストで受け入れられる実際の識別子を発行しないでください。次に、各リクエストをチェックし、この新しいCookieの値をセッションに保存されている値と照合するサーブレットフィルターを作成します。それらが一致しない場合、何か悪意のあることが起こっています。session.invalidate()新しいIDを発行するだけに頼るよりも少し面倒だと思います。ただし、制約とJRunの動作を考えると、これによりセッション固定に対する十分な保護が提供されます。

于 2011-07-31T05:16:27.617 に答える
1

Javaサーブレット3.0仕様のセクション7.3から、次のことがわかります。

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

これは本当にひどい考えですが、JSESSIONID cookieが単に再利用され、実際のセッションコンテキストが破棄されるのではないかと思います。無効化されたセッションの状態（つまり属性）に引き続きアクセスできますか？

于 2011-07-29T01:48:54.890 に答える