Thanks David. It hadn't dawned on me to do the cookie storing/retrieving over SSL - sometimes I need to be hit over the head with a sledgehammer to see the obvious. Without some sort of secure mechanism to transport the cookie between the browser and app all the app can be assured of is that the cookie is valid. The app cannot be 100% certain that the cookie being sent is sent by the real owner of the cookie. Generally, I would say that most applications could use any of the proposals floated on the list yesterday and today and not worry about client sessions being hijacked. Of course, if a session is hijacked - how much damage is done is a question the developer needs to ask themselves. If the risks are acceptable then what is in the Eagle book and has been discussed is OK. If the risks are not acceptable then what David suggests is the way to go.
And thanks to everyone who posted. --Joe Breeden --------------------------------------- If it compiles - Ship It! Aranea Texo > -----Original Message----- > From: David Young [mailto:[EMAIL PROTECTED]] > Sent: Thursday, November 15, 2001 6:30 PM > To: [EMAIL PROTECTED] > Subject: Re: Cookie authentication > > > I don't think that really solves Joe's proposed problem. Joe > wants to ensure > that the cookie is coming back from the client he sent it to. If you > generate a unique ID, someone can sniff the network, grab the > cookie, and > send it as their own. The Eagle book does half-heartedly > suggest IP address > as being a way to ensure the cookie's source, but that's not > reliable in > these days of proxies and NAT. > > The only answer, I think, is to only send the cookie over an > SSL connection, > so that it can not be sniffed. Remember that there is an > attribute you can > set on the cookie that tells the browser to only send the > cookie over an SSL > connection. > > Spend some time playing with Amazon and see how they handle > cookies. They > appear to have cookies that get sent over every connection > which they use to > personalize your web pages (not necessarily sensitive info). > However, as > soon as you try to purchase something or go to a sensitive > area, you are > asked to sign-in and sent a cookie over https. > > > > From: "Perrin Harkins" <[EMAIL PROTECTED]> > > Date: Thu, 15 Nov 2001 18:40:03 -0500 > > To: "Joe Breeden" <[EMAIL PROTECTED]>, "mod_perl List" > <[EMAIL PROTECTED]> > > Subject: Re: Cookie authentication > > > >> Excuse my question if it seems dumb I'm not 100% on NAT and > >> proxies, but the Eagle book says to 1 Choose a secret, 2 > Select fields to > > be > >> user for the MAC. It also suggests to use the remote IP > address as one of > >> those fields. 3 Compute the MAC via a MD5 hash and store > in the clients > >> browser. 4 On subsequent visits recompute the MAC and > verify it matches > > the > >> original stored MAC. How is this reliable in a situation where many > >> similarly configured computers are behind a NAT/Proxy and > one of the users > >> try to steal someone else's session by getting their > cookie/session_id > > info? > > > > Don't use the IP address in the cookie, just generate a > unique ID of your > > own. I suggest using mod_unique_id. > > - Perrin > > > > >
