SitePoint Sponsor

User Tag List

Results 1 to 23 of 23
  1. #1
    SitePoint Evangelist captainccs's Avatar
    Join Date
    Mar 2004
    Location
    Caracas, Venezuela
    Posts
    516
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    OOP: Keeping passwords safe

    I'm working on my first full fledged OOP web-app.

    I just realized that making usernames and passwords properties of an object creates a huge security risk because they are visible with
    PHP Code:
    print_r $object
    How and where are these sensitive data stored? In my old procedural framework I had "setup.php" files which I included to get these values. I suppose I could include them in the appropriate class method. For example:
    PHP Code:
    public function __construct($account) {
        include 
    "/path/to/accounts/" $account;
        
    $this->database = new Database($user$pass$name$host);

    Any other ideas about safekeeping usernames and passwords? (I'd rather not use a database for this.)
    Denny Schlesinger
    web services

  2. #2
    Community Advisor bronze trophy
    fretburner's Avatar
    Join Date
    Apr 2013
    Location
    Brazil
    Posts
    1,387
    Mentioned
    45 Post(s)
    Tagged
    12 Thread(s)
    Surely if an unauthorised person can write their own PHP code on your server to inspect the inner workings of your app, then your security has already been compromised?

  3. #3
    SitePoint Evangelist captainccs's Avatar
    Join Date
    Mar 2004
    Location
    Caracas, Venezuela
    Posts
    516
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by fretburner View Post
    Surely if an unauthorised person can write their own PHP code on your server to inspect the inner workings of your app, then your security has already been compromised?
    Yes but there are easier and harder places for hackers to attack. The public part (public_html) is easier to hack than the root of the server. Once an object is created it is available everywhere (kind of like a global variable) while a file in the root is local and harder to crack.
    Denny Schlesinger
    web services

  4. #4
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,011
    Mentioned
    62 Post(s)
    Tagged
    0 Thread(s)
    If they can gain access to your server to write a file to print_r and then get it to execute, you're already compromised.

  5. #5
    SitePoint Evangelist captainccs's Avatar
    Join Date
    Mar 2004
    Location
    Caracas, Venezuela
    Posts
    516
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Any ideas about keeping usernames and passwords safe in an OOP php framework? (I'd rather not use a database for this.) I'd love to have a discussion about this subject. Thanks.
    Denny Schlesinger
    web services

  6. #6
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    I'm not clear why you think you're vulnerable in the first place. If a hacker can't run arbitrary PHP on your site, then they can't print_r $object. And if they can run arbitrary PHP, then you're already hosed.
    "First make it work. Then make it better."

  7. #7
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Lets look at this. This attack is called "On the other side of the air tight hatch way." The attacker has root access to your machine and can do what every they want. Your passwords are the least of your problems now.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  8. #8
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Darn cannot edit my post now, forgot to aid this link of good reading: http://blogs.msdn.com/b/oldnewthing/...7/4268706.aspx
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  9. #9
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by captainccs View Post
    Any ideas about keeping usernames and passwords safe in an OOP php framework? (I'd rather not use a database for this.) I'd love to have a discussion about this subject. Thanks.
    I don't think there's much to discuss here since there are really not many options and others have already exaplained why. You can encode your php files with ionCube or something similar for some increased protection but its effectiveness is limited, too.

    The answer is elsewhere - keep your server secure against attacks.

  10. #10
    Community Advisor bronze trophy
    fretburner's Avatar
    Join Date
    Apr 2013
    Location
    Brazil
    Posts
    1,387
    Mentioned
    45 Post(s)
    Tagged
    12 Thread(s)
    captaincss, if you're interested in how config settings can be handled in OOP, you could take a look at how it's done in my framework of choice (Kohana). Configuration is stored as arrays in separate files under a /config directory, and in your app you instantiate a config object which reads in the setting for whichever configuration group you want.

    An example of this (from the Kohana docs):
    PHP Code:
    $config Kohana::$config->load('database')->get('default');
    $hostname $config['connection']['hostname']; 
    [url]http://kohanaframework.org/3.3/guide/kohana/config[/url

    owen100: did you intend to quote me, rather than just repost exactly what I'd said?

  11. #11
    SitePoint Evangelist captainccs's Avatar
    Join Date
    Mar 2004
    Location
    Caracas, Venezuela
    Posts
    516
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by fretburner View Post
    captaincss, if you're interested in how config settings can be handled in OOP, you could take a look at how it's done in my framework of choice (Kohana). Configuration is stored as arrays in separate files under a /config directory, and in your app you instantiate a config object which reads in the setting for whichever configuration group you want.
    Very interesting, thanks!

    Kohana gives you the choice of database and/or file system configuration data and provides the corresponding readers and writers. This is quite beyond anything I'm planning on now. What interested me were the properties they have. Only the directory and database locations. The config data is passed through, returned to the caller. That seems safe enough.


    Anyone who has managed a website, specially a commercial one, knows that websites are constantly under attack, 24/7/365, by very sophisticated hackers using tireless robots. The attacks come in innumerable ways with the url and html forms being great windows of opportunity. An approach that is based on the idea that if they break in you are already hosed is not a good one. My approach is to think about security constantly.

    For example, to connect to a database you need four pieces of configuration data (host, user, password, and database name). Once the connection is made you no longer need these data, all you need is the connection resource or connection object, and it's best not to have the configuration data floating around in a config object that persists for the duration of the php process (Kohana does not do this).

    In the grand scheme of things local scope variables are safer than global ones. php objects are super-global as far as I can tell. Once a password becomes the property of an oop object in practice it becomes a global variable even if declared as private. You can see it with var_dump() or print_r().

    Paranoid? Perhaps. My point is that every ounce of prevention counts.
    Denny Schlesinger
    web services

  12. #12
    Community Advisor bronze trophy
    fretburner's Avatar
    Join Date
    Apr 2013
    Location
    Brazil
    Posts
    1,387
    Mentioned
    45 Post(s)
    Tagged
    12 Thread(s)
    Quote Originally Posted by captainccs View Post
    An approach that is based on the idea that if they break in you are already hosed is not a good one.
    I don't think anyone was suggesting that you should ignore other security measures.. the point is that once someone has managed to run their own php code on your server and print_r() any of the vars from your app, then there aren't any security measures that are going to be effective past that point. You say that your preference with procedural code is to keep the database passwords in setup.php and include it when you need it.. what is to stop an attacker with write access to your public_html folder from including that file in his/her own script and gaining access to the the information?

    Quote Originally Posted by captainccs View Post
    In the grand scheme of things local scope variables are safer than global ones. php objects are super-global as far as I can tell. Once a password becomes the property of an oop object in practice it becomes a global variable even if declared as private.
    An object has the same scope as any other variable you declare in php, and you can unset() them in the same way.

  13. #13
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    If an attacker could print_r $object, then an attacker could also readfile('setup.php'), which means your old procedural framework was just as vulnerable... if you can even call it a vulnerability, which no one here seems to think to it is.

    We all love analogies, right? You're worrying about a thief being able to pick your front door lock from inside your house.
    "First make it work. Then make it better."

  14. #14
    SitePoint Evangelist captainccs's Avatar
    Join Date
    Mar 2004
    Location
    Caracas, Venezuela
    Posts
    516
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by fretburner View Post
    I don't think anyone was suggesting that you should ignore other security measures.. the point is that once someone has managed to run their own php code on your server and print_r() any of the vars from your app, then there aren't any security measures that are going to be effective past that point.
    To me that is so obvious that I don't see the reason for even mentioning it.

    Once dead, you're dead.


    You say that your preference with procedural code is to keep the database passwords in setup.php and include it when you need it.. what is to stop an attacker with write access to your public_html folder from including that file in his/her own script and gaining access to the the information?
    I thought I said that my secure files are NOT in public_html folder. I keep them in the server root.


    An object has the same scope as any other variable you declare in php, and you can unset() them in the same way.
    OK. Is unsetting the variable that contains object the same as destroying the object?
    Denny Schlesinger
    web services

  15. #15
    SitePoint Evangelist captainccs's Avatar
    Join Date
    Mar 2004
    Location
    Caracas, Venezuela
    Posts
    516
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    If an attacker could print_r $object, then an attacker could also ....
    Please see my reply above to fretburner
    Denny Schlesinger
    web services

  16. #16
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by fretburner
    the point is that once someone has managed to run their own php code on your server and print_r() any of the vars from your app, then there aren't any security measures that are going to be effective past that point.
    Quote Originally Posted by captainccs View Post
    To me that is so obvious that I don't see the reason for even mentioning it.
    If it's obvious that, at that point, nothing will be effective, then why are we having this conversation? Nothing will be effective.

    Quote Originally Posted by captainccs View Post
    I thought I said that my secure files are NOT in public_html folder. I keep them in the server root.
    Doesn't matter. I can readfile outside the public_html folder. All your setup.php are belong to us.

    Quote Originally Posted by captainccs View Post
    OK. Is unsetting the variable that contains object the same as destroying the object?
    Just a moment ago, you seemed to agree it was obvious that nothing will be effective. So... why?
    "First make it work. Then make it better."

  17. #17
    SitePoint Evangelist captainccs's Avatar
    Join Date
    Mar 2004
    Location
    Caracas, Venezuela
    Posts
    516
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Jeff:

    They had a reformed car thief on TV. They asked him which cars he preferred to steal. He replied: "The ones where the driver leaves the ignition key in place."



    You seem to be saying "A thief could get into your house so why bother with keys, locks, and other safety devices?" To try to keep the thief out or at least make breaking-in as difficult as possible.

    I don't see why you have a problem with my question. You seem to be making simplicity very complicated
    Denny Schlesinger
    web services

  18. #18
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,246
    Mentioned
    16 Post(s)
    Tagged
    0 Thread(s)
    In this case, the car is a web app, and the web app doesn't work without the keys. That's why every app, even your old procedural framework, keeps that information readily available.

    I don't see why you have a problem with my question.
    I don't actually have a problem with the question. But a half dozen people have already given you the same answer.
    "First make it work. Then make it better."

  19. #19
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Do not forget there is also: hightlight_file. Once again, when an attacker can run arbitrary code on your server. Their is nothing you can do. You'll need to have a DB password somewhere, readable by your application to connect to the DB and pull down settings.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  20. #20
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,784
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Assuming that the attacker does not have access to the server directly then the only possibility of the code being compromised is if the page doesn't get processed as PHP and so all the PHP displays in the browser.

    The way to prevent the password etc being compromised in that situation is to place that code in a separate file that is not inside of public_html and so is only accessible when the PHP can actually run (at which time none of the PHP will then be visible to the attacker using a web browser).
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  21. #21
    SitePoint Wizard siteguru's Avatar
    Join Date
    Oct 2002
    Location
    Scotland
    Posts
    3,629
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    If your application runs on a shared server then you will significantly increase the risk of an attacker gaining direct access - it's not unknown for shared servers to be exploited. If you're running on a dedicated server then felgall's post above makes sense; whilst a dedicated can still be compromised, the actions needed to do so are more involved.
    Ian Anderson
    www.siteguru.co.uk

  22. #22
    SitePoint Addict bronze trophy vectorialpx's Avatar
    Join Date
    Dec 2012
    Location
    Bucharest
    Posts
    247
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jeff Mott View Post
    You're worrying about a thief being able to pick your front door lock from inside your house.
    Except that here you don't have an alarm system and the thief can exit at anytime.
    But, you may create a system (let's say it's an "Alarm system") that tracks changes of your executable files (.sh, .php, .inc and others) and make a system that denies the changes (reverts the file instantly) by some algorithm. This must be created outside PHP, from UNIX (or whatever) because we assume the OS cannot be compromised. You may also create such a system from PHP, but it will cost you lots of resources.

  23. #23
    SitePoint Evangelist captainccs's Avatar
    Join Date
    Mar 2004
    Location
    Caracas, Venezuela
    Posts
    516
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    Assuming that the attacker does not have access to the server directly then the only possibility of the code being compromised is if the page doesn't get processed as PHP and so all the PHP displays in the browser.

    The way to prevent the password etc being compromised in that situation is to place that code in a separate file that is not inside of public_html and so is only accessible when the PHP can actually run (at which time none of the PHP will then be visible to the attacker using a web browser).
    Yes, I place all my code above the public_html. The pages in the public_html only have a few include statements. At the top of the page one include to kick start the script and in the body of html others to include dynamic content. In theory this prevents hackers from monkeying with the code via http but they can still get at it via ftp if they find the passwords.
    PHP Code:
    <?php
    $include 
    "/path/to/scripts/";
    include 
    "{$include}start.php";
    ?>
    <!DOCTYPE html>
    <html>
    <more html>
    <div class="some style">
    <?php include "{$module}some/output.php"?> 
    </div>
    <more html>
    <div class="more style">
    <?php include "{$module}more/output.php"?> 
    </div>
    <more html>
    </html>
    BTW, the designer I used to work with liked it very much because there was not a ton of php code cluttering up his Dreamweaver html/css design.


    Quote Originally Posted by siteguru View Post
    If your application runs on a shared server then you will significantly increase the risk of an attacker gaining direct access - it's not unknown for shared servers to be exploited. If you're running on a dedicated server then felgall's post above makes sense; whilst a dedicated can still be compromised, the actions needed to do so are more involved.
    The above can run on dedicated, virtual and shared servers with no change [as far as I know]. I use a shared server and, yes, leaks between accounts is quite easy to do.
    Denny Schlesinger
    web services


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
  •