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 :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Christoph,
Christoph Lenggenhager wrote:
| I'm currently trying to find a way to fight "Session Fixation"
| (http://www.owasp.org/index.php/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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkeqFawACgkQ9CaO5/Lv0PDMIQCfdE5LNfTtW1ZifQmW9us9QkuB
qFEAnRkWyeRSII8qJ4noef5uzzQ6u6tl
=YRiq
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
