Thanks Mark. I agree, but they are the security people and I have to at least try to comply. Do you think it would be feasible for us to change the org.apache.catalina.authenticator.AuthenticatorBase for Tomcat 4.1.18 to change the session ID post logging in? We'd obviously have to recompile tomcat after doing so. Are there any hidden "gotchas" you can think of with doing that?
Thanks Alex. -----Original Message----- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, 18 July 2005 2:50 AM To: Tomcat Users List Subject: Re: Tomcat security realms question The problem you describe is true of any session tracking system running over http. The solution is to use https. However, here's a question to fire back at your security team: "If you are worried about an attacker physically looking at a session ID on a user's screen, what about if they decide to install a keyboard logger (physical or software) whilst they have access to the user's machine?" In fact, I can think of a whole bunch of other things I could do as well that would be equally or more damaging than hijacking a single session. Fundamentally, if an attacker has physical access to a machine it is game over - they have won. Your security team knows the threat model for you situation far better than I do but it sounds to me like they are trying too hard in one area and have missed a bunch of other threats. Mark Akoulov, Alexandre [IT] wrote: > Hi all > > I have a problem that's been raised by my security team to do with using > Tomcat JDBCRealms. We're using such realms to protect restricted resources. > We also have a custom login form. The steps Tomcat seems to follow when using > such a setup is: > > 1. Check to see if the user is logged in with access to the restricted > resource. > 2. If they aren't, forward them to the login page and create an HTTPSession > to keep track of that user. > 3. Once they've logged in, add the authentication system to the HTTPSession > created in step 2 to hold that info and forward them to the resource. > 4. Continue using the same HTTPSession to maintain state. > > The problem my security team has with this is that someone could potentially > steal the users HTTPSession ID before they've logged in, as this is created > in the login screen. e.g. the user is forwarded to the login screen, then > goes to make themselves a cup of coffee. A hacker goes to their computer and > writes down the session ID. The user comes back and logs in, and the hacker > pretends to be them from another computer. > > My question is: how can I avoid this situation and keep the security guys > happy? Is it possible to have the session ID held by the browser (in > JSessionID) change post-login (ie make tomcat invalidate the current session > and create a new session after the user has been successfully authenticated)? > > Thanks for your help. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
