Re: [PHP] Gracefully dealing with Cookies OFF
Monty,
The best way to avoid SID Hijacks is to assign an IP variable, and an
expiration
session_register(USERIP);
$_SESSION['USERIP'] = $_SERVER['REMOTE_ADDR'];
session_register(EXPIRES);
$_SESSION['expires'] = time() + 900; // 900 seconds (15 mins)
and then the session has the users Ip address assigned to it and an expirey,
then to check you simply...
if ($_SESSION['expires'] time()){
die(Your session has expired after 15 minutes of inactivity);}
if ($_SESSION['remoteip'] != $_SERVER['REMOTE_ADDR']){
die ('This session is not valid for you);}
The only problem lies with people on AOL or those that use proxy's because
their IP address can cgange from minute to minute.
With the expirey, make sure you update the expirey on every page after
you've checked it to keep it 15 minutes in the future.
Any more help get in touch.
Bix.
Monty [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
both the cookie and URL based session passed over without SSL is
insecure.
i'd love to know who told you otherwise.
I can't remember the exact sites now, but, the issue was about how much
easier it is to spoof Sessions when IDs are passed via the URL as opposed
to
being stored in a cookie.
perhaps now is the time to re-think all this stuff, decide if you are
going
to support everyone (which i would for any paying client with a wide
target
market), or skip over those who don't meet your definition of a web
visitor.
After your indepth response, I've re-thought my re-thinking and have gone
back to wanting to support all users whether or not they have cookies
turned
on. And, miraculously, I've already got it working, so, thanks for your
detailed reply.
But going back to the first point, if I'm passing Session IDs via the URL,
shouldn't I be doing something more to make the site a little more secure?
I
don't store sensitive data in sessions vars, but, if it allows a
non-paying
member to hijack a paying member's session, then this is going to be a
problem. But I'm not sure what more I can do to make the session a little
more secure and less likely that someone will hijack it. SSL is a little
overkill for this, as this isn't a bank or financial institution, it's
just
a little community website.
The log-in for the site is fairly simple: After verifying the username and
password against what's stored in the DB, it sets up a few session vars
with
that member's access level and a few other preferences. This is so I don't
have to continually query the DB for this info on every page.
Is there anything more I can do to make it harder to spoof sessions?
just to throw another spanner into it all, what happens if I have JS
off?
will I still be able to access the content of the pop-ups? i bet not :)
Well, I have to draw the line somewhere. Javascript is used throughout
this
site for simple things like resizable popups. I'm not willing to dumb it
down that much.
Thanks!
Monty
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Gracefully dealing with Cookies OFF
On Sat, 7 Jun 2003, Bix wrote: Monty, The best way to avoid SID Hijacks is to assign an IP variable, and an expiration session_register(USERIP); $_SESSION['USERIP'] = $_SERVER['REMOTE_ADDR']; session_register(EXPIRES); $_SESSION['expires'] = time() + 900; // 900 seconds (15 mins) [snip] I've not followed this thread (nor do I want to get involved with his touchy and difficult topic) but must make a general comment on the above code. One should never mix use of the deprecated session_register() function with $_SESSION. If you're going to use $_SESSION, also use it to assign session variables. There is NO need for use of session_register() in the above code. From the manual (various versions of this text is also in the manual): If you are using $_SESSION (or $HTTP_SESSION_VARS), do not use session_register(), session_is_registered(), and session_unregister(). And btw, EXPIRES != expires. And lastly, there is now session_regenerate_id() although it won't set session cookies until PHP 4.3.3. Regards, Philip -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Gracefully dealing with Cookies OFF
On Saturday 07 June 2003 17:12, Bix wrote: The best way to avoid SID Hijacks is to assign an IP variable, and an expiration Never rely on an IP address to be unique to a particular browser/user. For reasons why search archives. -- Jason Wong - Gremlins Associates - www.gremlins.biz Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * -- Search the list archives before you post http://marc.theaimsgroup.com/?l=php-general -- /* I'm pretending that we're all watching PHIL SILVERS instead of RICARDO MONTALBAN! */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Gracefully dealing with Cookies OFF
both the cookie and URL based session passed over without SSL is insecure. i'd love to know who told you otherwise. I can't remember the exact sites now, but, the issue was about how much easier it is to spoof Sessions when IDs are passed via the URL as opposed to being stored in a cookie. perhaps now is the time to re-think all this stuff, decide if you are going to support everyone (which i would for any paying client with a wide target market), or skip over those who don't meet your definition of a web visitor. After your indepth response, I've re-thought my re-thinking and have gone back to wanting to support all users whether or not they have cookies turned on. And, miraculously, I've already got it working, so, thanks for your detailed reply. But going back to the first point, if I'm passing Session IDs via the URL, shouldn't I be doing something more to make the site a little more secure? I don't store sensitive data in sessions vars, but, if it allows a non-paying member to hijack a paying member's session, then this is going to be a problem. But I'm not sure what more I can do to make the session a little more secure and less likely that someone will hijack it. SSL is a little overkill for this, as this isn't a bank or financial institution, it's just a little community website. The log-in for the site is fairly simple: After verifying the username and password against what's stored in the DB, it sets up a few session vars with that member's access level and a few other preferences. This is so I don't have to continually query the DB for this info on every page. Is there anything more I can do to make it harder to spoof sessions? just to throw another spanner into it all, what happens if I have JS off? will I still be able to access the content of the pop-ups? i bet not :) Well, I have to draw the line somewhere. Javascript is used throughout this site for simple things like resizable popups. I'm not willing to dumb it down that much. Thanks! Monty -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Gracefully dealing with Cookies OFF
I don't have a study in front of me, but I'm fairly sure that cookies are much more likely to be enabled than javascript. I reccomend opening a normal popup using a link with a target, and opening a sized popup and returning false with javascript in an onclick property. Something like: a href=foo.php target=_blank onclick=window.open(...); return false;Open popup/a Monty wrote: Well, I have to draw the line somewhere. Javascript is used throughout this site for simple things like resizable popups. I'm not willing to dumb it down that much. -- The above message is encrypted with double rot13 encoding. Any unauthorized attempt to decrypt it will be prosecuted to the full extent of the law. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Gracefully dealing with Cookies OFF
both the cookie and URL based session passed over without SSL is insecure. i'd love to know who told you otherwise. I can't remember the exact sites now, but, the issue was about how much easier it is to spoof Sessions when IDs are passed via the URL as opposed to being stored in a cookie. It's easier because you can just type it in rather than crafting a cookie, but it's all pretty much the same. They are both equal, security wise. Well, actually, the other problem with session IDs in the URL is that user's could mistakenly post a URL somewhere with their session ID. If someone clicked on this link while the session was active, it could be hijacked. But going back to the first point, if I'm passing Session IDs via the URL, shouldn't I be doing something more to make the site a little more secure? I don't store sensitive data in sessions vars, but, if it allows a non- paying member to hijack a paying member's session, then this is going to be a problem. But I'm not sure what more I can do to make the session a little more secure and less likely that someone will hijack it. SSL is a little overkill for this, as this isn't a bank or financial institution, it's just a little community website. You kind of contradict your self. It'll be a problem, but it's just a little community website. So is it a problem or not? Honestly, if I somehow hijacked Joe Blow's session, what could I do? If it is a problem, then use SSL, plain and simple. That'll protect you from session IDs being sniffed from a network. ---John W. Holmes... Amazon Wishlist: http://www.amazon.com/o/registry/3BEXC84AB3A5E PHP Architect - A monthly magazine for PHP Professionals. Get your copy today. http://www.phparch.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Gracefully dealing with Cookies OFF
I think most people just put it in some sort of privacy policy I know Harrypotterfanfiction.com says it outright that you have to be able to accept not just their cookie but third party ones as well..Ouch..be sure to run SpyBot after you visit them. Vote.com has it in their privacy policy and explains how having cookies turned off limits your enjoyment of the site, but doesn't require cookie activation nor does use third party cookies, thank G-d.. Carl Furst -Original Message- From: Monty [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 3:08 AM To: [EMAIL PROTECTED] Subject: [PHP] Gracefully dealing with Cookies OFF I've decided to require that members for a site need to have cookies enabled in their browsers to sign-up and use the site. Is there a graceful way to deal with this when users who have cookies off try to sign-up or log-in to the site? Thanks, Monty -- 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] Gracefully dealing with Cookies OFF
Hi Justin, I hear what you're saying about refusing people without cookies turned off, and I really tried to make it work on my site, but, keep running into lots of problems. I do have enable-trans-sid turned on, but, get inconsistent results. For example, when someone logs out I return them to the log-in page. Even though I've deleted all sessions vars and destroyed the session before redirecting them, I noticed that the login page is full of PHPSESSID= tags that are sometimes empty and sometimes filled with a session ID. This happens whether or not I use session_start() at the beginning of my login script. As a result, it totally screws up the log-in process. I was seeing instances where it was appending two different PHPSESSIDs to the URL! And then there are things like header redirects (which you had a good solution for) and javascript popups. Those are ignored by enable-trans-sid, so, it means I have to go through all my scripts (there are many) and tweak them to pass the SID to every URL. The reason I decided against doing all this tweaking was because while researching this online, I read many statements by developers saying that passing Session IDs via the URL is more of a security risk than allowing this to be done via cookies. As the site I'm working on will be a pay membership site, it seems like a good idea to require cookies. I realize I may be turning people away, which would also be the case for those using ancient browsers. But, I don't have the level of programming expertise or resources of companies like Amazon and MSN who probably have very robust security systems in place even though they are passing sessions via the URL. I do appreciate your comments and insight on this, it makes me keep thinking: should I? could I? I'd be interested in hearing how others have dealt with requiring users to have cookies turned on for sessions, or not. Monty From: [EMAIL PROTECTED] (Justin French) Newsgroups: php.general Date: Wed, 04 Jun 2003 19:23:11 +1100 To: Monty [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PHP] Gracefully dealing with Cookies OFF Why on earth would you refuse users without cookies?? Take a look at all the major websites (amazon msn for starters). Do they require cookies? No. Do they require JavaScript? No. Do they require anything else special on the site? No. They take advantage of technology where available (DHTML and CSS for example), but the basic guts of the site can function without any of it, to the best of my knowledge. Instead, you choose to defy what every major site is doing, and require cookies. Cookies are not available to a wide number of users: - those in corporations where the IT dept. has disabled them - those accessing the 'net from any public computer: - libraries - airports - internet cafe's - those who choose to have a more secure, private web experience - those who don't understand the technology Doesn't make sense to me at all, but as long as you properly inform the client of your choice to ignore a large portion of users, then I guess it's your (and their) choice. PHP actually has a nice degradation of sessions built in. If you compile PHP with enable-trans-sid (compiled by default on PHP = 4.3 I *think*), PHP will: 1. use cookies wherever possible, OR 2. rewrite* all relative URLs/links in your pages to include the session id, where cookies are not available * in practice, it doesn't handle javascript or other client side scripting that well from memory. Even with enable-trans-sid not compiled, you can manually append the session id to all your URLs with the pre defined constant SID. This is just my point of view, but I don't believe you have any excuse for not allowing non-cookie users to join in the fun, and CERTAINLY not without informing the client of your decision. To manually test for cookies, know that you're testing, then let the user know that you don't want their business/traffic is more work than just letting PHP handle it with enable-trans-sid. Justin French -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Gracefully dealing with Cookies OFF
on 05/06/03 8:05 AM, Monty ([EMAIL PROTECTED]) wrote: Hi Justin, I hear what you're saying about refusing people without cookies turned off, and I really tried to make it work on my site, but, keep running into lots of problems. I do have enable-trans-sid turned on, but, get inconsistent results. For example, when someone logs out I return them to the log-in page. Even though I've deleted all sessions vars and destroyed the session before redirecting them, I noticed that the login page is full of PHPSESSID= tags that are sometimes empty and sometimes filled with a session ID. This happens whether or not I use session_start() at the beginning of my login script. As a result, it totally screws up the log-in process. I was seeing instances where it was appending two different PHPSESSIDs to the URL! I'd have to see your logout script and login script but here's what happens (pretty much): 1. you request the first page with a session_start() 2. PHP doesn't know if you have cookies or not, so it appends the sid to all URLs AND sets a cookie. 3. any internal link you click on this page will have the SID attached, so it will appear in the URL of the second page you view. 4. the second page you view, PHP can see that there is a SID in the URL... if it also finds a cookie, then it can stop rewriting the URLs... if it can't find the cookie, then it keeps on rewriting URLs. Make sense? So, if your logout script kills the session, but your next page starts a new session, i would expect to see SID's in some URLs around the logout/login area, and I would expect the SID to change. What you need to do is turn off cookies in your browser, and actually test how this works in your app, preferably using very simple code (not your large app) from the PHP site's samples. If it works, then why worry about how If it doesn't work, post the code here, and we'll attempt to fix it. And then there are things like header redirects (which you had a good solution for) and javascript popups. Those are ignored by enable-trans-sid, so, it means I have to go through all my scripts (there are many) and tweak them to pass the SID to every URL. well, for a smart application, you'd have them all in a couple of include files or .js files, which you could easily search for things like window.open to point you to problems. or perhaps your definition of degrade gracefully may not include the SID being available in pop-ups (is it needed???) just to throw another spanner into it all, what happens if I have JS off? will I still be able to access the content of the pop-ups? i bet not :) perhaps now is the time to re-think all this stuff, decide if you are going to support everyone (which i would for any paying client with a wide target market), or skip over those who don't meet your definition of a web visitor. me personally, I would not have mission-critical parts of the site rely on cookies, javascript, or anything else client side, other than HTML with simple CSS. The reason I decided against doing all this tweaking was because while researching this online, I read many statements by developers saying that passing Session IDs via the URL is more of a security risk than allowing this to be done via cookies. As the site I'm working on will be a pay membership site, it seems like a good idea to require cookies. both the cookie and URL based session passed over without SSL is insecure. i'd love to know who told you otherwise. given that your site has paid membership, this reinforces the need for you to reach as many paying customers as possible. I realize I may be turning people away, which would also be the case for those using ancient browsers. But, I don't have the level of programming expertise or resources of companies like Amazon and MSN who probably have very robust security systems in place even though they are passing sessions via the URL. most of it has been done for you via PHP sessions... you just need to write a small few-page site from scratch using simple, clean code (most of which will be on php.net already) to learn what needs to be done, test test test, then apply your new wealth of knowledge to your existing application. or, turn them away -- i'm trying to tell you what should be done, i'm trying to tell you that sessions via the URL is not the issue... perhaps it's a simple coding mistake, or a lack of understanding of what happens, or perhaps you just don't what to know :) I do appreciate your comments and insight on this, it makes me keep thinking: should I? could I? I'd be interested in hearing how others have dealt with requiring users to have cookies turned on for sessions, or not. no problem you know my stance :) justin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Gracefully dealing with Cookies OFF
I've decided to require that members for a site need to have cookies enabled in their browsers to sign-up and use the site. Is there a graceful way to deal with this when users who have cookies off try to sign-up or log-in to the site? Thanks, Monty -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Gracefully dealing with Cookies OFF
Why on earth would you refuse users without cookies?? Take a look at all the major websites (amazon msn for starters). Do they require cookies? No. Do they require JavaScript? No. Do they require anything else special on the site? No. They take advantage of technology where available (DHTML and CSS for example), but the basic guts of the site can function without any of it, to the best of my knowledge. Instead, you choose to defy what every major site is doing, and require cookies. Cookies are not available to a wide number of users: - those in corporations where the IT dept. has disabled them - those accessing the 'net from any public computer: - libraries - airports - internet cafe's - those who choose to have a more secure, private web experience - those who don't understand the technology Doesn't make sense to me at all, but as long as you properly inform the client of your choice to ignore a large portion of users, then I guess it's your (and their) choice. PHP actually has a nice degradation of sessions built in. If you compile PHP with enable-trans-sid (compiled by default on PHP = 4.3 I *think*), PHP will: 1. use cookies wherever possible, OR 2. rewrite* all relative URLs/links in your pages to include the session id, where cookies are not available * in practice, it doesn't handle javascript or other client side scripting that well from memory. Even with enable-trans-sid not compiled, you can manually append the session id to all your URLs with the pre defined constant SID. This is just my point of view, but I don't believe you have any excuse for not allowing non-cookie users to join in the fun, and CERTAINLY not without informing the client of your decision. To manually test for cookies, know that you're testing, then let the user know that you don't want their business/traffic is more work than just letting PHP handle it with enable-trans-sid. Justin French on 04/06/03 6:08 PM, Monty ([EMAIL PROTECTED]) wrote: I've decided to require that members for a site need to have cookies enabled in their browsers to sign-up and use the site. Is there a graceful way to deal with this when users who have cookies off try to sign-up or log-in to the site? Thanks, Monty -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Gracefully dealing with Cookies OFF
On Wed, 04 Jun 2003 03:08:00 -0400, Monty wrote: I've decided to require that members for a site need to have cookies enabled in their browsers to sign-up and use the site. Is there a graceful way to deal with this when users who have cookies off try to sign-up or log-in to the site? You can lead them to a page where you politly suggest they turn on their cookies just for your site and why. I would suggest using cookies only for the convenience of having their login information survive from session to session and use PHP Sessions for management of a particular visit. That said, I admit to having a cookie only site and have had absolutly no problems with my users figuring out they must have cookies enabled. However, I intend to add PHP Sessions to this site for those who like to log out after every session. Most like having their login information remembered via cookies. Thanks, Monty -- 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
