• Post Reply Bookmark Topic Watch Topic
  • New Topic

Problem with jsession id  RSS feed

 
Bajrang Asthana
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I need workaround for below-

As I guess there is known issues with jsession id. JBoss does not generate a new session id after logout(in the same browser) or browser uses same session id for all user's login. Session id is alive till max session period specified in web.xml. Actually I am using Seam framework, and while logout we call Seam.invalidateSession() method to invalidate session but after debugging I found that browser was using same session id after logout and all the session variables are alive (that must be unbounded after logout). I have also tried Identity.instance().logout(), unfortunately it is also not working.

I want to know how can we unbound all session variable and avoid session hijack or cookies theft.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The session is supposed to be an object stored in the webapp server in a Map whose key is the sessionID. The session.invalidate() method is supposed to remove that key/value pair from the appserver's session map, making the session ID unresolvable. Also part of the process is calling any session listeners that may be interested, but that's probably not important here.

I would expect that the Seam invalidation method would invoke the J2EE session invalidate() method, but I could be wrong.

One problem with "back" buttons, however, is that they may or may not actually contact the server. If they're pulling from the local user cache, then variables will appear to still exist even though they have been destroyed on the server.
 
Bajrang Asthana
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just want to correct myself-

I could see that all the session variables are unbounded after log out using invalidate method, but browser uses same session id as of previous logged in user's . Actually I am looking for possible solutions for session fixation and cookies theft.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stealing the cookie doesn't matter if there's nothing attached to it anymore.

What's more important than whether you're logged in or not is whether you're using TLS transport. As long as you are, then no one outside of the TLS pipeline can see the session ID anyway.

So the question is: are you trying to remedy a problem that may not exist, or is there a specific exploit you're having to deal with?
 
Bajrang Asthana
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I agree with you.

Could you please take a look of http://en.wikipedia.org/wiki/Session_fixation

 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmmm. I see. I'm definitely not evil enough to think up schemes like these myself.

Speaking for Tomcat, and assuming that the other appservers are at least as paranoid (especially since some of them use Tomcat internally!), the technique of jamming in a totally made-up session ID wouldn't work.

The other approach is to obtain a session ID from the server, pass it along, and get a free ride. This one is, indeed trickier, and while I haven't done a complete security analysis, I can venture a few guesses and observations.

The first one is pretty basic: never keep secure information in a session until you have logged in. Otherwise it will get "grandfathered" in to secure code when you log in.

The second one is this: Don't invent your own security system. I have a long list of reasons why DIY logins are a Bad Idea, and you've just given me one more to add to that list. If the server handles the login, then the server can be configured to drop the insecure session ID and return a secure session ID. DIY logins would have to go in and muck around with server internals to achieve that effect. They will probably not do it reliably because there will be odd corners of the appserver that the "security genius" didn't know about. Plus significant upgrades to the server software tend to break that kind of code.

So I think that you're safe enough as long as you look at the session like it was a multi-user sharable object for non-logged-in users and put all the secured stuff on the safe side of a container-managed (J2EE standard) login. And, of course, make sure that there is absolutely no way an external user can set values for secured session properties while not logged in.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!