RE: [PHP] sessions not so secure..solution?
Looking through the php.ini file brought me to the following setting: ; Check HTTP Referer to invalidate externally stored URLs containing ids. ;session.referer_check I looked in the manual and found this explanation: "session.referer_check contains the substring you want to check each HTTP Referer for. If the Referer was sent by the client and the substring was not found, the embedded session id will be marked as invalid. Defaults to the empty string." This sounds like it will do what you are trying to do. Jason -Original Message- From: Analysis & Solutions [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 10:03 AM To: PHP List Subject: Re: [PHP] sessions not so secure..solution? On Tue, Mar 19, 2002 at 08:37:43AM -0800, PHP freak wrote: > BUT - it's actually happening often that someone linking to our store > from their own website is including the long SESSID in the URL > that links to us, to that everyone who follows that link from > that website is getting the same shopping cart! Two things. First, tell the person linking to you to take the session id out of the link. Second, rework your system to more precisely track things. Here's what I track in my system: User Agent Time Referer = Last Page Viewed Enjoy, --Dan -- PHP scripts that make your job easier http://www.analysisandsolutions.com/code/ SQL Solution | Layout Solution | Form Solution T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions not so secure..solution?
On Tue, Mar 19, 2002 at 08:37:43AM -0800, PHP freak wrote: > BUT - it's actually happening often that someone linking to our store > from their own website is including the long SESSID in the URL > that links to us, to that everyone who follows that link from > that website is getting the same shopping cart! Two things. First, tell the person linking to you to take the session id out of the link. Second, rework your system to more precisely track things. Here's what I track in my system: User Agent Time Referer = Last Page Viewed Enjoy, --Dan -- PHP scripts that make your job easier http://www.analysisandsolutions.com/code/ SQL Solution | Layout Solution | Form Solution T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions not so secure..solution?
I came to the PHP list today with the same question/problem. My cart doesn't require cookies. If the user doesn't have them it just puts the SESSID in the URL. (Good ol PHP!) BUT - it's actually happening often that someone linking to our store from their own website is including the long SESSID in the URL that links to us, to that everyone who follows that link from that website is getting the same shopping cart! What to do? Not sure yet. I've seen that Amazon does this: Here's a shopping cart I just made in a browser with no cookies: http://www.amazon.com/exec/obidos/shopping-basket/ref=top_nav_sb_music/102-7862797-5184911 You can cut-n-paste that into a DIFFERENT browser with no cookies, and my cart items come up. (I think the 102-7862797-5184911 is my SESSID in this case.) I can go SSH into a remote server on the other side of the world, and type: lynx http://www.amazon.com/exec/obidos/shopping-basket/ref=top_nav_sb_music/102-7862797-5184911 Tell it to never allow cookies, and yes my cart STILL comes up. ... so they're not doing it by IP address. BUT - if I now take that URL that I've pasted in many cookie-less browsers, and put it in a browser WITH cookies, it says my cart is empty. IDEA: Maybe it's comparing the SESSID in the URL with the cookie, and if they match (rather - if they don't conflict) - then it's OK. I just was able to log all the way into my existing account at Amazon AND complete an order all without cookies. It did ask for my password 2 different times, though. Ah - i dunno. IF I WERE YOU, I'd approach it like http://my.yahoo.com At Yahoo, they have one level of authentication that lets you just see your basic "my.yahoo" page. Even if I haven't been there in months, it knows it's me. Let's assume it's a 1-year cookie. THEN - if I actually want to check my email, I need to enter the password every few hours. So make one cookie/SESSID last forever that only shows cart items. (As you say - no big deal, just a cart.) Then make another cookie/SESSID that only lasts a few hours, for that login stuff. That 2nd one could perhaps be concerned with IP address & whatnot. I dunno... keep me in the loop. Let me know what you decide. And vice-versa. On Tue, Mar 19, 2002 at 07:13:00AM -0500, Steve Clay wrote: > Hello, > I'm building an e-commerce site which uses sessions to > hold my $cart object. This works great but I've two worries: > > 1) When the user connects through our secure hostname, can I ensure > the browser will send the server the cookie (w/ SESSID)? The user > will shop through domain.com and checkout via https:secure.domain.com. > (haven't got cert yet) > > 2) While the user shops the SESSID is thrown around insecurely (no big > deal, just a cart). But when I move the user to a secure server to > get sensitive info a resourceful hacker could also go to the checkout > script using this SESSID and 'confirm' the real user's personal > details (kept in another registered session object). > > If I can't keep the user's details in the old session, can I delete > the old session and copy the cart to a new session? Should I do this > anytime the user goes back to the insecure site and returns to finish > checking out? > > As an alternative, would there be any problems with keeping the IP of > the user in a session variable for further authentication? I assume > I'd record the IP immediately upon checking in at the secure server > then enforcing this per request. That way, worst case scenario the > hackers gets a SESSID and heads to checkout first, server restricts > real user from accessing (because of different IP). > > This is my first time coding for a secure server and my first post > here as well.. > > Steve > -- > [EMAIL PROTECTED] ** http://mrclay.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] sessions not so secure..solution?
I can't answer your overall question but I can tell you that a 'resourceful' hacker can also easily spoof an IP address, or so I'm told ;) Why not just have the entire session encrypted. The user could browse around the catalog sessionless and as soon as a cart was necessary (wants to put something in it) the https starts. (?) Drew Lopucki [EMAIL PROTECTED] -Original Message- From: Steve Clay [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 7:13 AM To: PHP-GENERAL Subject: [PHP] sessions not so secure..solution? Hello, I'm building an e-commerce site which uses sessions to hold my $cart object. This works great but I've two worries: 1) When the user connects through our secure hostname, can I ensure the browser will send the server the cookie (w/ SESSID)? The user will shop through domain.com and checkout via https:secure.domain.com. (haven't got cert yet) 2) While the user shops the SESSID is thrown around insecurely (no big deal, just a cart). But when I move the user to a secure server to get sensitive info a resourceful hacker could also go to the checkout script using this SESSID and 'confirm' the real user's personal details (kept in another registered session object). If I can't keep the user's details in the old session, can I delete the old session and copy the cart to a new session? Should I do this anytime the user goes back to the insecure site and returns to finish checking out? As an alternative, would there be any problems with keeping the IP of the user in a session variable for further authentication? I assume I'd record the IP immediately upon checking in at the secure server then enforcing this per request. That way, worst case scenario the hackers gets a SESSID and heads to checkout first, server restricts real user from accessing (because of different IP). This is my first time coding for a secure server and my first post here as well.. Steve -- [EMAIL PROTECTED] ** http://mrclay.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
