RE: [PHP] session data vs cookie data
-Original Message- From: Erik Price [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 30, 2002 3:30 PM To: PHP Subject: [PHP] session data vs cookie data I have read elsewhere that depending on Cookie data for site authentication is false economy, because Cookie data can be spoofed. True I'm designing a login that auto-fills a person's name into a field for authentication (based on their $user_id, which is stored in the cookie), then they enter a password below that name and the fields are checked against data stored in MySQL. Standard authentication system. But from that point onward, I'd like to use a session variable that establishes the user's legitimacy as having logged in, using the cookie to store the SESSID. Barring the user spoofing the SESSID in the cookie, could someone easily fake legitimacy? I would think not, since the session data ($logged_in = 1 or something similar) is not stored in the cookie but rather on the server. But I just want to confirm. It is possible to steal a session because a session_id is usually based on a cookie. So I always store the IP, HTTP_X_FORWARD and USER_AGENT in the session. And check them every page. kind regards, Jerry I should mention that I have register_globals = off in php.ini (4.1.0 on Linux). Thanks, Erik -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] The information contained in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any form of disclosure, production, distribution or any action taken or refrained from in reliance on it, is prohibited and may be unlawful. Please notify the sender immediately. The content of the email is not legally binding unless confirmed by letter bearing two authorized signatures. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] session data vs cookie data
Jerry Verhoef wrote: It is possible to steal a session because a session_id is usually based on a cookie. So I always store the IP, HTTP_X_FORWARD and USER_AGENT in the session. And check them every page. kind regards, Jerry Do you null the user if the IP changes? IPs can change during a user's session, so I wouldn't base the validity of the session solely based on IP. Michael Kimsal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] session data vs cookie data
When that happens a user has to relogin. No data will be lost. Jerry -Original Message- From: Michael Kimsal [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 30, 2002 3:53 PM To: Jerry Verhoef Cc: PHP Subject: Re: [PHP] session data vs cookie data Jerry Verhoef wrote: It is possible to steal a session because a session_id is usually based on a cookie. So I always store the IP, HTTP_X_FORWARD and USER_AGENT in the session. And check them every page. kind regards, Jerry Do you null the user if the IP changes? IPs can change during a user's session, so I wouldn't base the validity of the session solely based on IP. Michael Kimsal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] The information contained in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any form of disclosure, production, distribution or any action taken or refrained from in reliance on it, is prohibited and may be unlawful. Please notify the sender immediately. The content of the email is not legally binding unless confirmed by letter bearing two authorized signatures. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] session data vs cookie data
Maybe you haven't had this experience, but we've regularly seen AOL users get switched between IPs during the same session on our sites. They'd had to start over and relogin every 5-10 minutes sometimes under that method. Do you not get any complaints? Michael Kimsal Jerry Verhoef wrote: When that happens a user has to relogin. No data will be lost. Jerry Do you null the user if the IP changes? IPs can change during a user's session, so I wouldn't base the validity of the session solely based on IP. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] session data vs cookie data
Do you null the user if the IP changes? IPs can change during a user's session, so I wouldn't base the validity of the session solely based on IP. When that happens a user has to relogin. No data will be lost. Relogin? Huh, I'd never visit a site where I have to login on every twice click. For some reason our company share 5 ip adresses for it's employees with NAT. We don't ever know what is our *current* request's ip, it's always changes by chance. It could be that I use one ip while I'm visiting a site (it's not likely), but it could be that my 5 requests get to the site sitting on 5 different ips. So I don't recommend using the visitors ip address for anything. Arpi -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] session data vs cookie data
HTTP_REFERRER is another good way to check. This allows users to access the page ONLY from a specific set of referring pages. However, if you have a gigantic site this can be cumbersome and can create a rather large array of referring pages, so you may want to put the value through a reg-ex that checks for the hosts on your domain (like www.domain.com, subdomain.domain.com, etc). That locks out all other domains, at least. Don't use this as your sole method of verification, but you can certainly include it. Mike Frazer Jerry Verhoef [EMAIL PROTECTED] wrote in message 1CDA86C6527BD311B91F0008C784121003D55205@ugbiex1">news:1CDA86C6527BD311B91F0008C784121003D55205@ugbiex1... -Original Message- From: Erik Price [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 30, 2002 3:30 PM To: PHP Subject: [PHP] session data vs cookie data I have read elsewhere that depending on Cookie data for site authentication is false economy, because Cookie data can be spoofed. True I'm designing a login that auto-fills a person's name into a field for authentication (based on their $user_id, which is stored in the cookie), then they enter a password below that name and the fields are checked against data stored in MySQL. Standard authentication system. But from that point onward, I'd like to use a session variable that establishes the user's legitimacy as having logged in, using the cookie to store the SESSID. Barring the user spoofing the SESSID in the cookie, could someone easily fake legitimacy? I would think not, since the session data ($logged_in = 1 or something similar) is not stored in the cookie but rather on the server. But I just want to confirm. It is possible to steal a session because a session_id is usually based on a cookie. So I always store the IP, HTTP_X_FORWARD and USER_AGENT in the session. And check them every page. kind regards, Jerry I should mention that I have register_globals = off in php.ini (4.1.0 on Linux). Thanks, Erik -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] The information contained in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any form of disclosure, production, distribution or any action taken or refrained from in reliance on it, is prohibited and may be unlawful. Please notify the sender immediately. The content of the email is not legally binding unless confirmed by letter bearing two authorized signatures. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] session data vs cookie data
On Wed, 30 Jan 2002, Michael Kimsal wrote: a cookie. So I always store the IP, HTTP_X_FORWARD and USER_AGENT in the Do you null the user if the IP changes? IPs can change during a user's session, so I wouldn't base the validity of the session solely based on IP. Also, sometimes there are issues with caches (despite of the HTTP_X_FORWARD)... Regards. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] session data vs cookie data
On Wednesday, January 30, 2002, at 09:55 AM, Jerry Verhoef (UGBI) wrote: When that happens a user has to relogin. No data will be lost. Jerry So then, do you include a re-login script at the top of every page (for when the session authentication fails)? Or do you have some advanced remember algorithm for what the user was doing at that point in their session? Erik Erik Price Web Developer Temp Media Lab, H.H. Brown [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
