I can also imagine this company gives employees the go-a-head and hijack each others session. It would also reward the idiot(s) that can do it best with double pay...
Your imaginary company example doesn't really happen within a real company, does it? Usually there are codes of conduct and policies against such malice behavior, with serious consequences. I think the risk is rather low than "relatively high", as you say. Even if you can enforce a "SAFE" session, what is there to stop a user from reconstructing his URL (with session ID and all) and email it to friends and company? Session hijacking is a potential problem with all web apps, regardless of technology. The only thing we can do, falling short of making the user authenticate with each request, is to determine the right balance between content security and risk. For most applications, I would feel reasonably secure if requests for a session are indeed coming from the same IP. Long ----- Original Message ----- From: "Tomas Hulek" <[EMAIL PROTECTED]> To: "Tomcat Users List" <users@tomcat.apache.org> Sent: Thursday, August 10, 2006 2:53 PM Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it > > In this case the chances are relatively high - imagine a company using a > proxy to connect to the Internet. The client IP does not change, a someone > in the company sniffing can easily hijack sessions from his/her colleagues. > > Tomas > > > > "Long" > <[EMAIL PROTECTED] > om> To > "Tomcat Users List" > 10.08.2006 18:30 <users@tomcat.apache.org> > cc > > Please respond to Subject > "Tomcat Users Re: Session hijacking with > List" Tomcat/Myfaces - unable to fix it > <[EMAIL PROTECTED] > che.org> > > > > > > > > > I wonder if associating (and checking) the request IP with the session > would reduce the problem to some acceptable level. What is > the chance of a session being hijacked from the same network (face-ip)? > > Another question is can the original request IP be spoofed? > > Long > > ----- Original Message ----- > From: "Tomas Hulek" <[EMAIL PROTECTED]> > To: "Tomcat Users List" <users@tomcat.apache.org> > Sent: Thursday, August 10, 2006 12:06 PM > Subject: Re: Session hijacking with Tomcat/Myfaces - unable to fix it > > > > > > We have tried it, but the internal session attributes where Tomcat stores > > the original request are hidden to application, and are certainly not > > accessible to javax.servlet.* API (and we do try to write PORTABLE > > application, relying on the specification and not on the internals of one > > particular servlet engine). > > > > Commenting on other suggestions > > > > 1) SSL for the whole application is not practical, there are many users > who > > only use the public pages and never log in. > > > > 2) We have implemented one workaround in the login-form > > if the session was not generated under SSL do the following: > > - invalidate session > > - create new session and mark it as safe (generated under SSL) > > - do an external redirect to a fixed, non-public page > > > > The last step will start the whole login process again, this time with a > > safe session ID. > > > > > > I am still not happy with it. A very enhancement in Tomcat would do: > > generate new session ID after switch to HTTPS, based eg. on the SSL > session > > ID (to get a new, unique ID). > > > > Tomas > > > > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
