Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Session Fixation Attack with Tomcat 7

 
Prashant Chotu
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

According to the docs, tomcat7 is not vulnerable to session fixation attack. But my tomcat 7.0.25 as well as 7.0.27 is vulnerable to this attack.
JSESSIONID is not getting changed on successful login.

I added following Valve to my conf/context.xml. But this didn't work. Please help me.

<Valve className="org.apache.catalina.authenticator.BasicAuthenticator" changeSessionIdOnAuthentication="true" />

Thanks,
Prashant Gupta
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18094
48
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's odd, because Tomcat6 does change the sessionID - I've read the source code that does it. Although the change isn't done strictly at login, it's done when the client switches from non-SSL to SSL transport (https), which can be done without logging in.
 
Prashant Chotu
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Tim for the reply.
Actually, my entire application, all the pages runs on ssl (https). So is there any provision in tomcat 7, so that the JSESSIONID cookie value get changed on each successful login ?

Right now, we doing it through code, on login we are manually invalidating the existing session and creating a new session with all the attributes copied from the existing session.
Is it possible, the JSESSIONID value can be renamed randomly

.
Regards,
Prashant Gupta
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18094
48
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't try to change the jsessionID yourself. That can only lead to trouble.

If all of your traffic is already encrypted, what advantage is changing the jsessionID just because you've logged in going to give you? The reason for the initial switch is to invalidate access to a now-secured object, but you're already secure. Only the client and the server can see the sessionID as clear text, so no one else knows what it is.

The sessionID carries no meaningful information itself - it's just a hash key and one chosen to be sufficiently unlikely that someone isn't going to randomly guess it.
 
Prashant Chotu
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just want to protect my app from session fixation attack. I give you a scenario - Suppose an attacker who is also an user of my app and he/she has a valid JSESSIONID. If the attacker sets this valid JSESIONID in the victim's browser via any means, then the next login of victim will be in the session fixed by the attacker as the JSESSION cookie value is getting changed on login. And the attacker without login will be able to access all the pages which need login.

That is why I need to change the JSESSIONID on each successful login.

Thanks,
Prashant Gupta
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic