Re: session info

Was there a question here or what? Did you want us to read a really long description of what you are doing? Jim ----- Original Message ----- From: "Jason Paschal" <j_paschal@hotmail.com> To: <php-general@lists.php.net> Sent: Friday, April 18, 2003 10:19 PM Subject: [PHP] session info > i was worried about session theft, so i ran some trials on different > machines. i had some if/then statements on my session protected pages. > that is, i set some session variables when someone logs in, and pass the > session ID along with each url, making sure to use the session ID during a > header redirect as a query string, and on each page, i check to see if those > session variables are still set. if they are not, i set the session ID to > what is passed via the url, and then i check those session variables again. > if the variables are still not set , i send them back to the login page. > this was tested on a machine that disabled cookies, and the only links that > worked were those that passed a valid session variable. changing that > session ID variable in the URL sent the user back to the login page, even if > that variable had been used in a previous session. > passing the session ID via URL is a necessary action for session dependent > sites, as is mentioned in the session documentation on php.net. sessions > depend upon cookies. if cookies are not enabled on a client, then the > session will not work. UNLESS you set the session ID in your code. if you > do, then you can call upon the variables associated with that code, and if > they are not set, if the ID is fabricated as one that does not exist, then > the session check fails, and that's when i send them to the login page. > of course, if someone fabricates an ID that DOES exist, there's nothing to > be done. session ID's are destroyed upon the closing of a browser, but if > you have a system that allows 'auto-login', which means that a unique ID is > stored on their system so a session can be resumed, then you open up new > possibilities of theft. unless you can determine a way to associate an id > with a client consistently, there's always a chance it'll be stolen. > fortunately, my situation involves a singles site, so a theft is survivable. > if something involving sensitive information is involved, i do require > personal verification to prove identity, though even that is not fool-proof. > so i resort to checking rationality. i validate all input to a tedious > degree, and if it passes, check it against stored information. if it does > pass, i check to make sure their action makes sense. if someone wants to > upgrade an account, i make sure it isn't already upgraded. an ounce of > precaution prevents a pound of cure. > > > > > > _________________________________________________________________ > The new MSN 8: smart spam protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >