5

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?

  • I think we need to see the implementation of obj.checkLogin(username, password) to answer this. This must be where the session is created as the getSession(false) in your posted code does not create sessions. – SilverlightFox Feb 10 '15 at 11:36
  • @SilverlightFox the checkLogin() method just checks the entered credentials against a hard-coded list. As this was an experiment I know that the session management is done by the above code only. – Shurmajee Feb 19 '15 at 9:42
  • In your exercise can you confirm that c1 was server generated, referring to an existing active session? – SilverlightFox Feb 20 '15 at 6:47
  • @Shurmajee Can you please share your github source code link? – Some Java Guy Sep 22 '16 at 14:00
  • @SomeJavaGuy It has been a long time man. No idea where the code is now. I never put it on Github – Shurmajee Sep 22 '16 at 15:50
-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
  • The question clearly states that tomcat 7 was used and can you please elaborate your point where you say 'this is typical behavior' ? – Shurmajee Nov 12 '14 at 4:12
  • @Shurmajee, you're right, I overlooked that it was tomcat. Will correct that. What is there to elaborate on? "Behaving securely regarding session fixation is typical behavior..." not sure what you're looking to hear... besides, i've removed that bit since it is no longer relevant with the edit. – atk Nov 12 '14 at 5:31
  • The expected behavior in this case would be reuse of the initial cookie after authentication as I am calling the getSession method with a boolean false parameter. There is a difference between getsession() and getSession(false). Please refer to the documentation link given in the question – Shurmajee Nov 12 '14 at 5:34
  • @Shurmajee, I am familiar with the documentation. What you expect is broken behavior. Tomcat 7 is not broken in this way, as your testing demonstrates. getSession(false) does not create a session. In your case, no session exists in server memory, so the value received in the request is ignored and no new session is created. This is secure behavior that prevents a servlet developer error from introducing a session fixation flaw. This also makes a lot of sense, as the servlet is not supposed to do session management; the engine is. – atk Nov 12 '14 at 5:38
  • I think there is a slight confusion here. The method getSession(false) does create a new session as a new jsessionid cookie is set after the authentication step (c1 != c2). This behavior is secure but unexpected. – Shurmajee Nov 12 '14 at 5:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.