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)

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. Feb 10, 2015 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, 2015 at 9:42
  • In your exercise can you confirm that c1 was server generated, referring to an existing active session? Feb 20, 2015 at 6:47
  • @Shurmajee Can you please share your github source code link? Sep 22, 2016 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, 2016 at 15:50

1 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
  • 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, 2014 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, 2014 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, 2014 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, 2014 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, 2014 at 5:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .