SitePoint Sponsor

User Tag List

Results 1 to 19 of 19
  1. #1
    SitePoint Member RedStorm's Avatar
    Join Date
    Jul 2005
    Location
    Santo Domingo
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Exclamation Security threat with print_r ($GLOBALS)

    hello, I was playing around with some predefined variables built in PHP trying to get some ideas for a small script I am playing with.

    I ran:

    Code:
        print_r ($GLOBALS);
    on my PHP page and ran it to see all the variables it returns. I noticed it prints out all the variables registered in PHP, those being used in my web page, etc.

    It freaked me out the moment I saw my username, password and all related information about my database connection routine. I then asked myself, since I do allow some file uploads to the server for administration purposes, if someone decided to upload a php script with that command in it, it could be a huge security hole.

    My first approach was to better check for file uploads and make sure they did not ran any PHP scripts at all in them, but I feel now so stupid I did not realize this issue before that I would like some better orientation from people with more experience in security and PHP.

    Any comments or suggestions are welcome. Thank you.

    Jose R. Lopez
    Last edited by RedStorm; Aug 9, 2005 at 08:40. Reason: made a typo in title

  2. #2
    SitePoint Member
    Join Date
    Mar 2005
    Posts
    19
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Jose,

    I'm glad to see that you are interested in improving the security of your scripts and servers.

    This is one of the reasons why we have print_r in our "disable_functions" within the PHP configuration file, among other things.

    A production server has no use for print_r, at least not in my books.

    Disabling Register Globals will also do tremendous good as well.

    I am releasing a 150-page Linux Administrator Security Handbook in a few months. In addition to physical server security, services security, and application security on production servers - the guide will also contain very detailed and in-depth information on how to help secure PHP scripts and PHP itself. Once the guide is released, you'll know it because I'll have it in my signature.

    Now, back to the problem at hand! In addition to adding that to your disable functions list, you may want to take a look at mod_security for Apache (if you are running apache).

    - Matt
    OverclockersClub.com - Technology News & Hardware Reviews

  3. #3
    SitePoint Member RedStorm's Avatar
    Join Date
    Jul 2005
    Location
    Santo Domingo
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OOC, thank you for your prompt reply. I though when I started learning PHP that
    PHP Code:
    print_r 
    was very usefull to dig into my arrays and see what was in it. And to be honest it has helped understand many things and find many mistakes. But just like you said, I have never really used it in a live website for nothing at all and I always do my tests on test servers different from live ones.

    I would be anxious to read through your book, I have learned a great deal of things thanx to sitepoint books (a sitepoint book was actually the very first book I have ever read complete in my entire life) but I know my programs have many security issues I need to address ASAP.

    Thank you once again for your reply.

    Jose R. Lopez

  4. #4
    SitePoint Member RedStorm's Avatar
    Join Date
    Jul 2005
    Location
    Santo Domingo
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just a small update for someone who is also concerned about security issues. I added some filters to my upload script to check for mime type for the file and the file extensions. I am going to disable the print_r feature from my php configuration file as well. Somehow I still feel some things are missing. Will keep reading up and update this post as I find more things to it.

    Jose

  5. #5
    Keep it simple, stupid! bokehman's Avatar
    Join Date
    Jul 2005
    Posts
    1,933
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by OCC
    A production server has no use for print_r,
    How is that a security risk? And how would anyone be able to access that? There would need to be other gapping holes in security already wouldn't there?

  6. #6
    SitePoint Member RedStorm's Avatar
    Join Date
    Jul 2005
    Location
    Santo Domingo
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bokehman
    How is that a security risk? And how would anyone be able to access that? There would need to be other gapping holes in security already wouldn't there?
    print_r displays the contents of an array. There is a global array in PHP which contains all the active variables being used by a specific script. When you use print_r to see the contents of a global variable you are able to see all the contents in it. That includes the username, password and all other related information in your script to connect to a database, open a file or whatever.

    Now, how can someone externally access that? I don't want to give anyone ideas, but I imagine that you can easily fake an image file with a text document. If you allow your upload path to a directory readable by a web browser (inside your DocummentRoot folder) and you fail to properly check that file that was just uploaded for its file extension, mime type, maybe if it is binnary or ASCII etc, that person could find a way to excecute that script. Even if he didn't the fact that he got it to your server is itself a security threat.

    Now that I carefully think about it, if the user managed to upload that file with malicius script in it, he needs to find a way to have it processed by the webserver, for which he will need to see which are the accepted extensions...

    hmmmmm

    Maybe if I limit those files that can be processed by the webserver and explicitly exclude those from my allowed files I can better secure it all.

    I'm not sure, simply thinking out loud. I am not sure how to explain it, but I know for sure that having a function avaliable to print the contents of an array and having a global array that holds all your variables without needing to guess your actual variable names sounds like a big security threat to me.

  7. #7
    Keep it simple, stupid! bokehman's Avatar
    Join Date
    Jul 2005
    Posts
    1,933
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So your argument is that print_r should be disabled to protect people who write bad code. Well that's just nannying.

  8. #8
    SitePoint Member RedStorm's Avatar
    Join Date
    Jul 2005
    Location
    Santo Domingo
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bokehman
    So your argument is that print_r should be disabled to protect people who write bad code. Well that's just nannying.
    What I meant was that someone could write a script, upload it to your server by tricking it to be an image or any other allowed file and then running it if it is accesible on the document root. If that person manages to get print_r($_GLOBALS) output from your script you'll be in trouble.

    At least its my perception.

  9. #9
    Keep it simple, stupid! bokehman's Avatar
    Join Date
    Jul 2005
    Posts
    1,933
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If it was uploaded as an image the server would run it with an image mime type so it would not be executed.

  10. #10
    SitePoint Enthusiast
    Join Date
    May 2001
    Location
    lalal
    Posts
    85
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If someone can get their own php code to run on your server via your script, disabling print_r is the least of your worries. Running print_r($GLOBALS) will be at the very bottom of their todo list.
    But while you're at it, don't forget to disable the functions var_dump, var_export, debug_zval_dump, debug_backtrace, the ability to loop, the $GLOBALS array etc etc etc etc. Heck why not just go all out and disable all the functions and functionability of PHP.

  11. #11
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I heart post 10.
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  12. #12
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Brooklyn, NY
    Posts
    359
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tress
    If someone can get their own php code to run on your server via your script, disabling print_r is the least of your worries. Running print_r($GLOBALS) will be at the very bottom of their todo list.
    You just made my day - thanks for the laugh. :-)
    Chris Shiflett
    http://shiflett.org/

  13. #13
    SitePoint Wizard Young Twig's Avatar
    Join Date
    Dec 2003
    Location
    Albany, New York
    Posts
    1,355
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tress
    If someone can get their own php code to run on your server via your script, disabling print_r is the least of your worries. Running print_r($GLOBALS) will be at the very bottom of their todo list.
    But while you're at it, don't forget to disable the functions var_dump, var_export, debug_zval_dump, debug_backtrace, the ability to loop, the $GLOBALS array etc etc etc etc. Heck why not just go all out and disable all the functions and functionability of PHP.
    Haha... thank you.

  14. #14
    Keep it simple, stupid! bokehman's Avatar
    Join Date
    Jul 2005
    Posts
    1,933
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There obviously seem to be two styles here. Style 1: write code so people can't compromise the server. Style 2: write bad code and try to configure the server to cover for it.

    I think I'll stick with style 1.

  15. #15
    SitePoint Wizard samsm's Avatar
    Join Date
    Nov 2001
    Location
    Atlanta, GA, USA
    Posts
    5,011
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bokehman
    There obviously seem to be two styles here. Style 1: write code so people can't compromise the server. Style 2: write bad code and try to configure the server to cover for it.
    In fairness, I think most people would agree that a prudent approach to security involves both good code and reasonable limitations in configuration. People make mistakes, it's a good idea to have a little redundancy where possible.

    It's just that this particular limitation has limited practical value.
    Using your unpaid time to add free content to SitePoint Pty Ltd's portfolio?

  16. #16
    SitePoint Member RedStorm's Avatar
    Join Date
    Jul 2005
    Location
    Santo Domingo
    Posts
    12
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bokehman
    There obviously seem to be two styles here. Style 1: write code so people can't compromise the server. Style 2: write bad code and try to configure the server to cover for it.

    I think I'll stick with style 1.
    True, very true for people who think doing it yourself is the only way in doing it right.

    I code alone for now, I code for myself, my websites and scripts are for my own specific use. So yeah, if I write good code, i don't really have to worry much about many security threats, but when you think ahead and see yourself people taking over what you do "improving it", or addapting it, creating new scripts and working under your structure where you can not completly control how that code is being written, and just like samsm said, people make mistakes, you need to better approach both things.

    I am sorry tress if my intrigues in this subject where found a little dumb to you as I am aware there are many other security issues to be covered way before print_r, i just happened to find interesting how easy it was to access that much information our of a single function.

    I'll keep doing my best in writting good code, and I'll do even better in writting bad one, at least by doing so I can easier understand and prevent what most people do and secure my servers accordingly.

    Writting good code is simply part of the equation, for you to really understand the why's of writting good code you must first meet the consecuences of not doing so.

    There is a saying in my country "Dominican's (From Dominican Republic) only lock their doors after thiefs have stolen from them". It is a very stupid thing we do, we never prevent things from happening, until they happen. I try not to honor such saying by doing what I feel most people would do first and addressing it accordingly.

    Jose

  17. #17
    SitePoint Evangelist sputza's Avatar
    Join Date
    Jan 2002
    Location
    Canada
    Posts
    528
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by tress
    If someone can get their own php code to run on your server via your script, disabling print_r is the least of your worries. Running print_r($GLOBALS) will be at the very bottom of their todo list.
    But while you're at it, don't forget to disable the functions var_dump, var_export, debug_zval_dump, debug_backtrace, the ability to loop, the $GLOBALS array etc etc etc etc. Heck why not just go all out and disable all the functions and functionability of PHP.
    LOL
    Steven Watkins
    Chief Web Ninja
    Code Monkey Interactive
    lowgravity.ca

  18. #18
    Keep it simple, stupid! bokehman's Avatar
    Join Date
    Jul 2005
    Posts
    1,933
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by RedStorm
    I imagine that you can easily fake an image file with a text document.
    How? And how would you get a .jpg file to be executed by the php interpreter?

  19. #19
    SitePoint Wizard Dylan B's Avatar
    Join Date
    Jul 2004
    Location
    NYC
    Posts
    1,150
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bokehman
    How? And how would you get a .jpg file to be executed by the php interpreter?
    THe only way would to upload a new .htaccess file, and if you can to that, you seriouslyt need to rethink programming as a career choice.


Bookmarks

Posting Permissions

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