In a previous life, I used a similar technique and was defeated when the network guys put a cache engine in front of our servers. Then, all requests came from the same IP address. This sort of thing can happen based on other priorities in the organization and break your best solutions.
The main thing with security is to determine who the threat is and how difficult you want to make bypassing your security. In many cases, the added expense (in time and money) is not worth the slim chance that you are trying to eliminate. I don't know if that is the case for you, but it's worth some review before trying to build a security system. For the most bang for the buck, only allow access to the admin portions through SSL. This encrypts the cookie along with the rest of the request. The only thing you'd have left to worry about is physical security of the system. G. Wade Sjoerd van Leent wrote: > > Here is a question to do the same without cookies, so storing something > in a cookie just won't work at al. I know that an IP address is not the > best solution at all, but when you're using an internal network, it will > work. I agree that using an IP address is by far not the best solution, > but the odds are low... > > Sjoerd > > -----Original Message----- > From: Mike Cherichetti (Renegade Internet) > [mailto:[EMAIL PROTECTED] > Sent: zondag 17 augustus 2003 22:29 > To: Tomcat Users List > Subject: RE: Session Security > > Todd, > > Putting the IP address of the user in the session won't work too well. > An > AOL user for example may have a different IP address every time they > send in > a request. And, it's obviously possible for someone to spoof an IP > address. > > The best solution I've found to prevent sessions from being stolen is to > use > a one time access token. The token, which I usually create by doing > MD5(ip > + timestamp + random #), gets stored in a cookie and in the session > itself. > So, say a user logs in, they get a token and when they come back with > their > next request they send in that token. Your authentication logic checks > the > token in the cookie against the token in the session and handles > accepting > or denying the request. When the response is processed, you give them a > new > token and continue this cycle for all requests to follow. > > Now, lets say someone manages to steal the session. That person is > going to > get a different token than the legitimate user that's logged in > currently > has. So, when the legitimate user sends in their next request with a > wrong > token, you should catch that the session has been compromised and > invalidate > it immediately. This will result in the malicious user being kicked > out. > > Still, this isn't a perfect solution because most users forget to > logout. > Using a low timeout value for the session is the only way I know of to > deal > with this scenario. You could run your application under HTTPS instead > of > HTTP too if that's an option :) > > Hope that helps, > Mike > > -----Original Message----- > From: Todd O'Bryan [mailto:[EMAIL PROTECTED] > Sent: Sunday, August 17, 2003 2:45 PM > To: [EMAIL PROTECTED] > Subject: Session Security > > Is there any block against someone stealing someone else's session id > and using it for nefarious purposes? In other words, if I write a grade > book program, could a sharp student write down the session id from a > web address (if cookies are off) or look in the teacher's cookie file, > and then go to a computer in the library and use the same session id to > connect to the grade book page before the teacher logs out? > > Does the session id check itself against the issuing computer's IP > address or anything to prevent such a thing from happening? I realize > it's a stretch that someone might leave their computer unattended long > enough for such a thing to happen, but I just want to be sure. Also, > could someone listening in to the net traffic grab the session id and > then use it? > > Thanks, > Todd > > --------------------------------------------------------------------- > 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] > > --------------------------------------------------------------------- > 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]
