The check will verify that the session id doesn't duplicate another active session.
If the session expires - it is still possible ( even if extremely unlikely ) that a user will reuse the same browser window and get into someone's else session. I think this is as likely as someone using a random session ID ( for any decent random generator, the fact that a number has been generated before shouldn't affect the probability of having it generated again - AFAIK ) We could completely eliminate this chance by including the time - so each sessionID will have the start time included in it ( that may be used for other purpose eventually ). Costin Glenn Olander wrote: > Here's a follow-up on the bug report I submitted that started this thread. > > 1) We confirmed the problem is a duplicate session id. > > Luckily we were logging session id's. It took a lot of hunting through > access logs, but we did indeed find two sessions which were started a > couple of minutes apart, with a number of intervening sessions, which > had duplicate session id's. The pair of sessions corresponded to the user > report of seeing someone else's session data. We're using 4.1.12. > > 2) I don't believe this is *common* > > The problem hasn't been duplicated in our app, so I'm not sure I'd call > this a common problem, but that's a subjective term. > > 3) I believe this is a serious vulnerability > > There should probably be some sort of an alert delivered to tomcat > users to let them know of this problem. > > 4) A simple patch is available > > It is not necessary to use the head version of tomcat to fix the problem. > Simply install your own manager class, which subclasses StandardManager, > which has the duplicate session id checking implemented. In other words, > a simple patch on an existing tomcat installation can fix this. > > 5) The strength of the PRNG is largely irrelevant > > As a user, I wouldn't trust any solution which lacks a check for > duplicate session id's, regardless of the strength of the PRNG. The head > revision now includes such a check, so I believe the problem has been > solved. Even the weakest of PRNG's would generate a collision only rarely, > so I wouldn't worry about improving its strength. > > - Glenn -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
