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)
If your "cookie domain" is ".domain.com", it will send the cookie to both, however, you don't really WANT to use the same cookie in both places. > 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). Yes, and so this is inappropriate. Allocate a cookie for all pages (ssl and not). When they transition to SSL for checkout, then give them an SSL cookie as well, and associate it with the old cookie. You could store them in a session -- I do it in a database table. Store the time you allocated the SSL cookie. Mandate that when someone views a secure page, to be considered authenticated, they must hand you the SSL-only cookie. You can use its association to retrieve the cart, but not to let someone else interrupt the ordering process, or use its authentication properties to view personal details, cancel an order, etc. Since you set the cookie to be SSL-ONLY (there's a flag for that in setcookie()), it won't be passed in the clear. Associate the assignment time of the cookie with it, and each pageview, reset it to some reasonable number, say 5-30 min. After that time expires, the cookie is no good and you reassign one. In my own scheme, that's when a user re-enters their password. Anyhow, the dual-cookie approach will allow you to maintain reasonable security. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
