tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Duplicate session IDs are *common*
Date Fri, 10 Jan 2003 19:08:12 GMT
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

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 ). 


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:   <>
For additional commands, e-mail: <>

View raw message