Session ID re-used after call to invalidate

Question

I've inherited a pretty ancient JSP application (JDK 1.3.1_15) and am attempting to plug a session fixation hole.

I'm successfully invalidating the current session after authentication using HttpSession.invalidate() however when the new session is created, the old session ID is re-used.

<%
// 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;
}
%>

I can see the new session assignment in my HTTP monitor, it's just using the same number again.

-- 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=/

Prior to me using session.invalidate() the second Set-Cookie response header was not present at all.

Does anybody have any advice on how to generate a new session ID? I'm not very familiar with JRUN4 but trawling through the configuration documentation hasn't turned up anything.

Answer 1

To work around this, you can use a second non-persistent cookie to act as a session id that you can control the value of. The idea is to generate a unique id and store it in both the cookie and the session. Implement the same logic with this cookie that you are attempting to do with the session through using invalidate. Specifically, don't issue the actual identifier that will be accepted for future requests until authentication is successful. Then create a Servlet Filter that checks each request and matches the value of this new cookie to the value stored in the session. If they don't match, something nefarious is going on. I know it is a bit more cumbersome than just relying on session.invalidate() to issue a new id. But given your constraints and JRun's behavior, this will provide sufficient protection against session fixation.

Answer 2

From Section 7.3 of the Java Servlet 3.0 specification, you can see that:

HttpSession objects must be scoped at the application (or servlet context) level. The underlying mechanism, such as the cookie used to establish the session, can be the same for different contexts, but the object referenced, including the attributes in that object, must never be shared between contexts by the container.

It's a really terrible idea, but I wonder if the JSESSIONID cookie is simply re-used and the actual session context destroyed. Can you still acess state (i.e. attributes) of the invalidated session?