Session fixation in Java

Question

In the process of developing a vulnerable jsp/servlet based application I made an attempt to introduce the session fixation vulnerability.

Referring to the documentation I came up with the following code which when used in the servlet to create a new session, should return the existing HTTP session if it exists and otherwise it should return null. In any case a new session should not be created.

if(obj.checkLogin(username, password))//if credentials are valid
    {
    HttpSession session = request.getSession(false);//return the existing session

    if(session != null)
            response.sendRedirect("LoginSuccess.jsp");
        else
            response.sendRedirect("error.jsp");
    }

In order to test the code I deployed it using tomcat 7 and tested for session fixation:

1. Observe the cookie (c1) when login page loads (using an intercepting proxy)
2. Enter the correct credentials in the login form. The authentication was successful and I was redirected to LoginSuccess.jsp
3. Observe the cookie (c2) after the authentication.

I found the cookies c1 and c2 to be different. Which implies that the code is not vulnerable to session fixation. I am having trouble understanding this behavior. Why is it that the original cookie c1 does not persist after the authentication?

Answer 1

The servlet engine you are using securely handles session cookies when you call request.getSession(), and is not vulnerable to fixation.

(as discussed in the comments) This behavior is both intentional and correct. Whether getSession(), getSession(true) or getSession(false) is called, the server relies on its own memory to determine if there is a valid session matching the value received from the client. If there is no such session in server memory, then the servlet engine ignores the session id from the client. This prevents session fixation, since the server never allows the client to define the sessionid of a new session (new from the perspective of the server that doesn't have that sessionid in memory.)

You either need to find an older, broken servlet engine that is vulnerable to session fixation or you need to replace the session management code. If you go with the latter, you will need to determine if you can replace the session generation in place or if you will write your own session management code.

The approach you take should mirror what you are trying to teach. If you want people to teach...

• keep your stuff patched, then go with the broken old engine
• not to write your own session management mechanism, the write your own
• not to modify an existing session management mechanism, then modify the existing one