Results 1 to 9 of 9

Thread: PHP Security...

  1. #1
    Join Date
    Dec 2002
    Posts
    65

    Unanswered: PHP Security...

    I apologize in advance for my long-windedness it's habit.

    Recently while talking with some other web developers the topic of the security of PHP came up - specifically the overall security of the language itself as opposed to writing secure applications within the PHP framework- and I was wondering if any people had some insight regarding this topic.

    One of the developers I was talking to works for a pretty well known organization that is mostly a PERL shop and expressed that he did not like using PHP because of its past security flaws. I was wondering if he felt this way because of specific version releases, or because of long term history of vulnerabilities that go unresolved (which would be surprising considering Yahoo's decision to use PHP for future development http://www.newsfactor.com/perl/story/19912.html). I am attempting to get as much of an objective answer to the overall security of PHP as a language compared to other web targeted languages (say PERL, Python, Ruby). I realize that ALL languages will have their weaknesses at one time or another do to changes within the language causing vulnerabilities like buffer overflows, mis-handled exceptions, etc. and I realize that PERL has been around much longer than PHP which may mean it has had more time to address any security issues.

    So as it stands with the current release versions of your favorite web languages which would you say is:
    1)the most secure
    2)the best in regards to usability/programmibility/performance vs security

    I'm hoping to open up a realistic and frank discussion about the available languages out there, hopefully as much criticism possible for any language you wish to discuss without getting into flame wars and fanboy-ism.

    For example let me start off. The use of sessions through cookies or passing session IDs through the URL is vulnerable to man in the middle packet sniffers or user tampering with the cookie that holds the session id. Is there another language that handles persistent data similarly, but more securely. SSL will help vs packet sniffing, but is there a language that handles this better, or is there a better way to do it in PHP?
    (I'm only available at the email address provided in my profile on weekdays, if you have questions or advice, during off hours use AIM). Also any views I provide here or on my website are mine and not representative of any views of my work, family, friends and sometimes even myself.

    http://www.bcyde.com

  2. #2
    Join Date
    Dec 2002
    Posts
    6

    Re: PHP Security...

    It is true that PHP has had a number of vulnerabilities, but so has other languages, and as for perl, security has never been a fundamental part of the language ;-)

    How secure/insecure PHP is compared to other languages I don't know, and I'm not even sure if that is the most important issue here.

    One way of securing yourself is making sure that you have the latest version of PHP, or whatever language you prefer, installed. No matter what language you use, there is always a good chance that sooner or later someone will find a new vulnerability.
    A good idea is to sign up for the bugtraq mailinglist, for info on the latest vulnerabilities:
    http://online.securityfocus.com/cgi-...e/subscribe.pl

    As for the man in the middle attack, you can make sure that the session id is impossible to guess. NEVER use incrementing numbering for session ID's. As far as I know it is always possible to hijack a session unless you use SSL.

    The perhaps most important things to do, regardless of language, is validating the input data. Make sure nobody can input data that may be harmfull in any way. One thing that many seems to forget, is that it is possible to input data even if the user isn't supposed to do any input.
    Just concider someone changing the URL whenever variables are passed using GET.

    For those interested in security in building web applications there is an interesting ongoing project called "OWASP Guide to Building Secure Web Applications and Web Services". They've written a guide full of good advice for webdevelopers, pdf can be downloaded from their site:
    http://www.owasp.org/guide/

  3. #3
    Join Date
    Dec 2002
    Posts
    65

    Thanks for your tips

    Thanks for your input. I'm checking the supplemental links/documents you provided. Regarding incremental session IDs, are you speaking of when generating your own session IDs via session_id() or are you speaking of a setting within PHP that generates incremental session IDs automatically when you call session_start()?

    I originally wanted to discuss PHP vs. other languages, but while we're on the topic of secure PHP coding practices here's a few off the top of my head:
    1)turn register globals off
    2)use $_SESSION[] instead of session_register
    3)In PHP 4.3 or newer use session.use_only_cookies to true if you don't want to use sessions through URLs (although this will reduce functionality for people who don't/can't use cookies)

    Thanks again,
    -B
    (I'm only available at the email address provided in my profile on weekdays, if you have questions or advice, during off hours use AIM). Also any views I provide here or on my website are mine and not representative of any views of my work, family, friends and sometimes even myself.

    http://www.bcyde.com

  4. #4
    Join Date
    Dec 2002
    Posts
    6

    Re: Thanks for your tips

    Originally posted by bcyde
    Regarding incremental session IDs, are you speaking of when generating your own session IDs via session_id() or are you speaking of a setting within PHP that generates incremental session IDs automatically when you call session_start()?
    I was thinking more of a case where it for some reason could be useful to create your own set of session identifiers.

    A nice way to create a session id is first seeding the random number generator:

    srand((double)microtime()*1000000);

    Then generate a unique id:

    md5(uniqid(rand()));

  5. #5
    Join Date
    Sep 2002
    Location
    Kyiv, Ukraine
    Posts
    77

    Re: Thanks for your tips

    Originally posted by bcyde
    ...
    2)use $_SESSION[] instead of session_register
    3)In PHP 4.3 or newer use session.use_only_cookies to true if you don't want to use sessions through URLs (although this will reduce functionality for people who don't/can't use cookies)
    ...
    Could you please describe more in details as for PHP Security Question newbie what these two rules are and why better keep to them?
    Yours faithfully,
    Yaroslav Zaremba

  6. #6
    Join Date
    Dec 2002
    Posts
    65

    Re: Thanks for your tips

    aZa

    2)use $_SESSION[] instead of session_register
    ----------------------
    Well basically this is something I learned the hard way a while back from the kind folks in #php on irc . At the time I was asking about $_SESSION[] vs usage of session_register() and basically got just use $_SESSION[] without a real explanation. After a while I realized that it was just better coding practice because:
    a)It can remove reliance on register globals and removes possible confusion that may occur with variable scope
    b)Since $_SESSION[] is a super global its value is available from within functions without having to extract it

    This basically says it all this was taken straight from the PHP manual at php.net for session_register

    If you want your script to work regardless of register_globals, you need to use the $_SESSION array. All $_SESSION entries are automatically registered. If your script uses session_register(), it will not work in environments where register_globals is disabled.

    3)In PHP 4.3 or newer use session.use_only_cookies to true if you don't want to use sessions through URLs (although this will reduce functionality for people who don't/can't use cookies)
    ----------------------
    In PHP 4.3 this setting was introduced and if you're sure your website visitors allow cookies then this would be a little more secure because the user's session ID won't get embedded within the URL by accident making it readily visible and easily accessible for copying. Still, using cookies won't protect you from a packet sniffer/man in the middle unless you're also doing things over SSL. If you're not sure that cookies are enabled this setting will interfere with your session capabilities though.

    Hope this helps clarify things.

    -b
    (I'm only available at the email address provided in my profile on weekdays, if you have questions or advice, during off hours use AIM). Also any views I provide here or on my website are mine and not representative of any views of my work, family, friends and sometimes even myself.

    http://www.bcyde.com

  7. #7
    Join Date
    Sep 2002
    Location
    Kyiv, Ukraine
    Posts
    77
    Tried searching for "$_SESSION" in PHP manual (pdf-version) and didn't find any mention of it. Any clue? Could you give me some more detailed description where to look for it?

    Regarding use_only_cookies: that's why I'm actually using sessions (because some of the users forbid cookies)! If you don't want to use pure sessions than there is no need at all to implement them and you can easily do the same thing through cookies (in my case that was authetification process on the site).

    I can only see this function useful in case when you are using some standard scripts and without getting much deep in to the code you wish to make them use only cookies for passing variables. This way you just put that function at the top of the main script pages. But if you program from "clean sheet" you can use cookies from the very beginning without even touching sessions ... Just my 2 cents. Or did I not understand something important again?
    Yours faithfully,
    Yaroslav Zaremba

  8. #8
    Join Date
    Dec 2002
    Posts
    65
    Hi in regards to $_SESSION check out http://www.php.net/manual/en/functio...n-register.php and read the caution portions.

    As far as cookies/sessions I'm not exactly sure what you mean by using either one or the other. When you use sessions the session ID must be passed to the server and is either passed along through the URL, form variable or by a cookie. Are you saying that you use sessions specifically by sending the session IDs through the URLs or hidden form vars?
    (I'm only available at the email address provided in my profile on weekdays, if you have questions or advice, during off hours use AIM). Also any views I provide here or on my website are mine and not representative of any views of my work, family, friends and sometimes even myself.

    http://www.bcyde.com

  9. #9
    Join Date
    Sep 2002
    Location
    Kyiv, Ukraine
    Posts
    77
    Thanks for the link! I seem to have a bit out-of-date manual I guess which doesn't have 'sessions' part at all. that's why I couldn't find mentioning of "_SESSION" in the document.

    Truly saying currently I use my hosting provider's default settings for passing session variables (through URL). I didn't quite understand the purpose of function use_only_cookies ... I thought that it simply sends all your session variables information using cookies, not only session's ID ... This way it seems to be much more secure than sending through URL and makes sense, I would even say big sense! Will surely redo my scripts with that setting turned ON.
    Yours faithfully,
    Yaroslav Zaremba

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •