tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From david delbecq <>
Subject Re: How to avoid session fixation?
Date Wed, 06 Feb 2008 21:48:44 GMT
Sorry Christopher, but i tried at work, it's very easy to force a user 
to use a specific sessionid, and later use yourself that session id to 
gain that user's credential, and for the whole session there is only one 
login, the one from the user you attempt to hijack. As such, tomcat is 
vulnerable to session fixation issues. Tomcat does not check where the 
session originates from (IP of requester is not associated with 
session). By passing a ;jssessionid=.... to a url and asking someone to 
"check something on that url", you can, after that user logged in, use 
yourself the same url to gain that user's credential.

Note: we use tomcat 5.5.7, maybe this has been fixed in later versions....

Christopher Schultz a écrit :
> Hash: SHA1
> Christoph,
> Christoph Lenggenhager wrote:
> | I'm currently trying to find a way to fight "Session Fixation"
> | ( in tomcat when using
> | the built -in mechanisms to authenticate users of a servlet.
> I don't believe that Tomcat suffers from this problem. Without trying
> it, I would imagine that a user cannot authenticate twice using the
> built-in mechanism.
> When a remote user requests a protected resource, Tomcat checks to see
> if the user has authenticated already. If she has, Tomcat checks for
> authorization. If the user is not authorized, the request is rejected.
> If the user was not authenticated, the user is challenged for
> authentication and the process picks up after authentication.
> If a login request comes in without Tomcat expecting it, the request is
> rejected.
> Ergo, there's no way to login once and then expect someone to login
> afterward.
> If you are using your own authenticator, then this could be a problem.
> | In the
> | environment in question, an own realm implementation is in place and
> | we use the SingleSignOn feature as well.
> Have you demonstrated this problem in your own environment? If so, how
> did you do it?
> | Or is it in fact not a problem at all?
> See above.
> | A common solution to fix the problem is to renew the session (or at
> | least it's id) right before/after the user is authenticated (i.e. in
> | the same request). I came up with a custom valve that kind of does the
> | job, but I'm really not sure whether this is the way to go or if I'm
> | messing too much with tomcat internals.
> I would make sure it's a problem first, and then fix it.
> This is interesting for the securityfilter project, which DOES allow
> drive-by logins. Hmm. I'll have to think about this one. Thanks!
> - -chris
> Version: GnuPG v1.4.8 (MingW32)
> Comment: Using GnuPG with Mozilla -
> qFEAnRkWyeRSII8qJ4noef5uzzQ6u6tl
> =YRiq
> ---------------------------------------------------------------------
> To start a new topic, e-mail:
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message