6

Whenever you authenticate, your application should change the session identifier it uses. This helps to prevent someone from setting up a session, copying the session identifier, and then tricking a user into using the session. Because the attacker already knows the session identifier, they can use it to access the session after the user logs in, giving them full access. This attack has been called "session fixation" among other things. How can i change the session id once the user login to the system ?

  • Is there a reason you asked this twice? http://stackoverflow.com/questions/1138436/can-i-regenerate-my-own-session-id-in-servlet – blowdart Jul 22 '09 at 06:49
  • yes i cannot add the comment and reply the message –  Jul 22 '09 at 06:57

4 Answers4

9

You're still on the server while you invalidate the session.

//get stuff out of session you want before invalidating it.
currentSession = request.getSession(true);
UserProfile userProfile = (UserProfile) currentSession.getAttribute("userProfile");

//now invalidate it
currentSession.invalidate();

//get new session and stuff the data back in
HttpSession newSession = request.getSession(true);
newSession.setAttribute("userProfile", userProfile);
Brian
  • 13,412
  • 10
  • 56
  • 82
2

Get the existing; invalidate it; create a new one ...

1) Get the current Session with HttpServletRequest.getSession();
2) Clear the Session: HttpSession.invalidate();
3) Create a new one: HttpServletRequest.getSession(true);

Henrik
  • 568
  • 4
  • 10
  • If i using this method, once the user login he will first logout in order to regenerate the id –  Jul 22 '09 at 06:32
  • 1
    as blowdart stated: "Well then that's a limitation of the framework you are using I'm afraid." Can you give a code-example of your authentication process? This might help. – Henrik Jul 22 '09 at 08:16
2

Talking generally (because this isn't a Java problem at all, it's a general web problem) session fixation arises when session IDs are easy to discover or guess. The main method of attack is when the session ID is in the URL of a page, for example http://example.com/index?sessionId=123. An attacker could setup capture a session and then embed the link in their page, tricking a user into visiting it and becoming part of their session. Then when the user authenticates the session is authenticated. The mitigation for this is to not use URL based session IDs, but instead use cookies

Some web applications will use a cookie session based but set it from the initial URL, for example visiting http://example.com/index?sessionId=123 would see the session id in the url and then create a session cookie from it, setting the id in the session cookie to 123. The mitigation for this is to generate random session ids on the server without using any user input as a seed into the generator.

There's also browser based exploits where a poorly coded browser will accept cookie creation for domains which are not the originating domain, but there's not much you can do about that. And Cross Site Scripting attacks where you can send a script command into the attacked site to set the session cookie, which can be mitigated by setting the session cookie to be HTTP_ONLY (although Safari does not honour this flag)

For Java the general recommendation is

session.invalidate();
session=request.getSession(true); 

However at one point on JBoss this didn't work - so you need to check this works as expected within your chosen framework.

blowdart
  • 55,577
  • 12
  • 114
  • 149
  • I try using this method, but the user will be logout is session.invalidate() is called –  Jul 22 '09 at 06:33
  • Well then that's a limitation of the framework you are using I'm afraid. – blowdart Jul 22 '09 at 06:34
  • i am using jsf and tomcat, so got any other method to solve the problem? –  Jul 22 '09 at 06:41
  • 1
    Even the OWASP page has an anti-fixation fix only for ASP – Ryan Fernandes Jul 22 '09 at 07:32
  • 1
    Well with ASP.NET it's not so much of a worry, as the authentication process is generally separate from the session. Unless you've rolled your own. I guess JSF stores authentication information in the session which is why the original poster is setting it lost when regenerating sessions, but I know nothing about that platform. – blowdart Jul 22 '09 at 08:04
  • @blowdart : This sounds more like he is not saving his session information before he invalidates it. That will of course appear to be a logout, since all user info will be lost. See what Brian said about saving stuff first. And since he refused to post any code when Henrik asked, no one could help him. – Amit Naidu Aug 03 '11 at 13:04
0

Invalidate the current session and the get a new session:

//invalidate the current session
request.getSession().invalidate();
/*
get another session and get the ID (getSession()) will create a session if one does not exist
*/
request.getSession().getId();
Brian
  • 13,412
  • 10
  • 56
  • 82