Re: [PHP] sessions security (no problems just question)
On Jun 14, 2003, Ryan A claimed that: |Hi, |I have been reading up on the old discussions on this list as i was very |busy for the past few daysand i saw a very intresting topic regarding |sessions and security. | |I really didnt understand some of the things you guys wrote on hi-jacking a |session...do you have any examples of this? |How can someone else have the session info of another user? |after looking at the session id i see that its a long garbled string and |even if someone is a good guesser...isnt that a very very very long shot? or |am i missing something? | |I looked up on google and i didnt see anything major... | |I dont mean to drag this topic up all over again so if any of you have any |URLs that you think would shed some light on this matterplease do post |it to me. | |This concerns me a lot as I have a very sessions heavy site...which is |also a kind of paysite/freesite. | |Cheers, |-Ryan From http://www.php.net/manual/en/print/ref.session.php There are several ways to leak an existing session id to third parties. A leaked session id enables the third party to access all resources which are associated with a specific id. First, URLs carrying session ids. If you link to an external site, the URL including the session id might be stored in the external site's referrer logs. Second, a more active attacker might listen to your network traffic. If it is not encrypted, session ids will flow in plain text over the network. The solution here is to implement SSL on your server and make it mandatory for users. Another way is to monitor session.save_path of another domain on a server that you have access to. Using some screen scraping techniques it might not be hard to extract passwords or (using something similar to Amazon's 'one-click' purchasing) to buy a bunch of crap using someone else's money. -- Registered Linux user #304026. lynx -source http://jharris.rallycentral.us/jharris.asc | gpg --import Key fingerprint = 52FC 20BD 025A 8C13 5FC6 68C6 9CF9 46C2 B089 0FED Responses to this message should conform to RFC 1855. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions security (no problems just question)
JH are associated with a specific id. First, URLs carrying session ids. If JH you link to an external site, the URL including the session id might be JH stored in the external site's referrer logs. Second, a more active JH attacker might listen to your network traffic. If it is not encrypted, JH session ids will flow in plain text over the network. The solution here is JH to implement SSL on your server and make it mandatory for users. Also I want to note. If sids are accessible via http_referer, there is a way to execute php scripts on behalf of a user. For example, user clicks a link to some php script which will grab sid from referer and then outputs a html with redirect to another script (for example to set a forwarding filter or etc). Since sid is right and also script was called from user's PC, this is a quite bad thing, but unfortunately this still exists on several web based e-mails. So, be careful in using only session mechanisms provided by PHP. It's quite insecure. -- Best regards, Martchukov Anton aka VHmailto:[EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions Security
--- Clarkson, Nick [EMAIL PROTECTED] wrote: I am trying to find the best method for implementing sessions in PHP to track/limit users. However, the more I read, the more I am concerned about security. Can anyone give me a definitive answer as to the best method of tracking users with security in mind? I have spoken on this topic several times in the past. Here are a few recent ones: http://groups.google.com/groups?selm=20030115215804.74315.qmail%40web14307.mail.yahoo.com http://groups.google.com/groups?selm=20030102155526.52596.qmail%40web14302.mail.yahoo.com http://groups.google.com/groups?selm=3DC35A8C.6030208%40php.net http://groups.google.com/groups?selm=3DBC8190.9080007%40shiflett.org http://groups.google.com/groups?selm=3D7BBDD2.7090803%40php.net Hopefully that will give you a good start. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Sessions Security
Thanks - I've only just joined the list so must have missed your previous msgs. I'll give them a read later. Thanks again. Nick -Original Message- From: Chris Shiflett [mailto:[EMAIL PROTECTED]] Sent: 23 January 2003 15:28 To: Clarkson, Nick; [EMAIL PROTECTED] Subject: Re: [PHP] Sessions Security --- Clarkson, Nick [EMAIL PROTECTED] wrote: I am trying to find the best method for implementing sessions in PHP to track/limit users. However, the more I read, the more I am concerned about security. Can anyone give me a definitive answer as to the best method of tracking users with security in mind? I have spoken on this topic several times in the past. Here are a few recent ones: http://groups.google.com/groups?selm=20030115215804.74315.qmail%40web14307.m ail.yahoo.com http://groups.google.com/groups?selm=20030102155526.52596.qmail%40web14302.m ail.yahoo.com http://groups.google.com/groups?selm=3DC35A8C.6030208%40php.net http://groups.google.com/groups?selm=3DBC8190.9080007%40shiflett.org http://groups.google.com/groups?selm=3D7BBDD2.7090803%40php.net Hopefully that will give you a good start. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php This private and confidential e-mail has been sent to you by Egg. The Egg group of companies includes Egg Banking plc (registered no. 2999842), Egg Financial Products Ltd (registered no. 3319027) and Egg Investments Ltd (registered no. 3403963) which carries out investment business on behalf of Egg and is regulated by the Financial Services Authority. Registered in England and Wales. Registered offices: 1 Waterhouse Square, 138-142 Holborn, London EC1N 2NA. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with 'received in error' as the subject and then delete it from your mailbox. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions Security
Hi, There's actually another thread on this topic at the moment... quick summary: 1. you can't rely on the IP address 2. you can't rely on the referrer It's been suggested on the list that you could record the user agent into the session, and check against that -- keeping in mind that the user agent may be null, and that this would not prevent someone with an identical useragent from hijacking the session... it's more like an added layer of protection :) Check out the recent thread prevent session_replay Justin on 03/01/03 11:36 AM, Duncan ([EMAIL PROTECTED]) wrote: Hi, i am currently working with sessions and how to secure them as much as possible. In an older script of mine, i used session_is_registered() to take care of this, but according to the manual: If you are using $_SESSION (or $HTTP_SESSION_VARS), do not use session_register(), ... - i can't use this anymore. Well, so i wondered: how do you or would you make sure that s.o. won't be able to hijack the session? Also any recommended URLs about this matter are more than welcome as well :) I am currently only checking the IP, but i read about issues with AOL users about this, since it can happen that their IP changes while browsing the site. S.o. mentioned checking the referer and so making sure, the script comes from the own server, but when using redirects or stuff like that (or the browser doesn't support this properly - as read in the php manual), then this isn't 100% working as well. So, start nuking me with your comments ;) Regards, Duncan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sessions Security
Ah, thanks a lot. I will add my 2 cents in there then :) Regards, Duncan Justin French wrote: Hi, There's actually another thread on this topic at the moment... quick summary: 1. you can't rely on the IP address 2. you can't rely on the referrer It's been suggested on the list that you could record the user agent into the session, and check against that -- keeping in mind that the user agent may be null, and that this would not prevent someone with an identical useragent from hijacking the session... it's more like an added layer of protection :) Check out the recent thread prevent session_replay Justin on 03/01/03 11:36 AM, Duncan ([EMAIL PROTECTED]) wrote: Hi, i am currently working with sessions and how to secure them as much as possible. In an older script of mine, i used session_is_registered() to take care of this, but according to the manual: If you are using $_SESSION (or $HTTP_SESSION_VARS), do not use session_register(), ... - i can't use this anymore. Well, so i wondered: how do you or would you make sure that s.o. won't be able to hijack the session? Also any recommended URLs about this matter are more than welcome as well :) I am currently only checking the IP, but i read about issues with AOL users about this, since it can happen that their IP changes while browsing the site. S.o. mentioned checking the referer and so making sure, the script comes from the own server, but when using redirects or stuff like that (or the browser doesn't support this properly - as read in the php manual), then this isn't 100% working as well. So, start nuking me with your comments ;) Regards, Duncan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Sessions/security
Try looking at register_shutdown_function at http://www.php.net/manual/en/function.register-shutdown-function.php From the documentation: "int register_shutdown_function (string func) Registers the function named by func to be executed when script processing is complete." What qualifies as "complete"? After each page is parsed and served to the client? After a certain amount of time when the requesting browser hasn't made another request? Chris
