session info
| From: | Jason Paschal | Date: | Sat, 19 Apr 2003 05:19:23 +0000 |
| Subject: | session info | ||
| Groups: | php.general | ||
| Request: | Send a blank email to php-general+get-144469@lists.php.net to get a copy of this message | ||
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