tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From david delbecq <delbd+jaka...@oma.be>
Subject Re: How to avoid session fixation?
Date Mon, 11 Feb 2008 22:24:52 GMT
Christopher Schultz a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David,
>
> David Delbecq wrote:
> | I think this is worth submitting a security issue request on tracker,
> | to ask that, at least, the container links the requester IP to the
> | session.
>
> I'm pretty sure that nobody will want to do this -- at least not without
> the ability to turn the feature off. You'll break a lot of users if you
This won't be the first fix in tomcat that would potentially break other 
application, in the past tomcat team have always made such change 
optionnal. IT wold anywa be good for system administrator if they can 
prevent such issue.
>
> | Changing session ID upon login in container would be a good thing
> | imho, it would ensure ID become unknown to attacker after login,
> | wouldn't destroy user session (keep session, only change it's
> | identifier) and would work whatever authentication mechanism is used.
> |
> I completely agree. Christopher, I think your valve might be more
> attractive if it was able to change the id of the session and leave it
> at that. I'm not familiar enough with the Tomcat API to know if this is
> possible and/or a good idea.
>
> | Draw back is that webapp that rely on session id for some session
> | tracking mechanism would break.
>
> True, although most webapps probably use whatever session id is
> currently in use. If you did a lot of AJAX where the session id
> available to the page becomes out-of-date after a login, you will have
> to make special considerations for that. I think you'll find that this
> is not much of a problem.
I would more be thinking about applications that plays with 
sessionlistener and maintain list of active session (to track number of 
users / who is logged in, etc). Like ip<->session id matching, a change 
id on the fly could also break at several levels and should be 
optional.Also, for example, of non-cookies enabled user, for which url 
previous to login would become useless (or at least would point to an 
inexistant session).
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkewsO8ACgkQ9CaO5/Lv0PBWXQCggsMZA1AGkdzSDvBmYeHC2JED
> iU4An15g6IGrG/yU4mgWokKnVkXdnW0O
> =eLbx
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message