As far as I know Tomcat will always generate a new id for each session it generates. As for how they have detected that your application is vulnerable to session fixation issues etc. try having a look at Burp Suite http://portswigger.net/burp/ which detects a great deal of web application flaws.
Rob > -----Original Message----- > From: Brian [mailto:bbprefix-m...@yahoo.com] > Sent: 11 October 2010 17:06 > To: 'Tomcat Users List' > Subject: RE: JSESSIONID weakness Severity in Tomcat 6.0.29? > > Hi Mark, > > Well, it seems that www.securitymetrics.com got crazy! They already told me > that they made some changes in their system, and now they are having > problems (bugs). > I was just asking myself: How can their automatized procedure know if I am > vulnerable to the session fixation problem, if it doesnt know a valid > user+password, so it is not being able to actually login to my system? > > Anyway, something good came from this: I realized that actually my system > was not safe to session fixation. After the login process, it was not > invalidating the session and creating a new one. Now it is. I just had to > program the system to save the attributes, invalidadte the current session, > create a new one, and recreate the attributes. Fortunately, Tomcat generates > a new session ID for the new session. It seems that it was not happening in > the previous versions of Tomcat and in other containers (according to what I > have read in some forums), but now it is. > > Thanks for all your help! > > > > -----Original Message----- > > From: Mark Thomas [mailto:ma...@apache.org] > > Sent: Sunday, October 10, 2010 03:09 PM > > To: Tomcat Users List > > Subject: Re: JSESSIONID weakness Severity in Tomcat 6.0.29? > > > > On 10/10/2010 20:59, Brian wrote: > > > Hi Mark, > > > > > > Do you understand exactly what vulnerability are they talking about? > > > > No. It doesn't make much sense to me at the minute. I'd ask for more > specific > > information. > > > > > For > > > some reason, they have determined that I have it, even though I'm not > > > using Jrun but they wrongly assume I am. > > > > Looks like it so far. It all depends how they are detecting the > vulnerability. It > > could be a false positive but there isn't enough information to tell. > > > > > What do you mean exactly with "app managing its own authentication"? > > > Sorry if it is a dumb question. > > > > If you use Tomcat's authentication (BASIC, FORM, etc) then Tomcat will > change > > the session ID on authentication and therefore protect against session > fixation. > > > > If the app has its own authentication mechanism it is possible that the > session ID > > will not be changed on authentication creating the possibility for a > session > > fixation attack. > > > > > I found this on Google, and now that I read it I realize they are > > > quoting you! :-) > > > http://www.developer.com/java/web/article.php/3904871/Top-7-Features-i > > > n-Tomc > > > at-7-The-New-and-the-Improved.htm > > > Is this the same subject? > > > > Yep, although that is looking at Tomcat 7. The session fixation protection > (along > > with a handle of other things originally developed for Tomcat 7) got > back-ported > > to Tomcat 6. > > > > Mark > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
