Config Settings and Security

I have a file called “db_settings.php” which looks like this…

    // Database Host.
    define('DB_HOST', 'localhost');

    // Database User.
    define('DB_USER', 'some_user');

    // Database Password.
    define('DB_PASSWORD', 'some_password');

    // Database Name.
    define('DB_NAME', 'some_database');

    // Make Connection.
    $dbc = @mysqli_connect(DB_HOST, DB_USER, DB_PASSWORD, DB_NAME)
                        OR die('Could not connect to database.  Contact System Administrator.');

A while back I moved it from the web root to a directory called “outside_root” - which is obviously just that!

Then for any script that needs to connect to MySQL, I use REQUIRE “db_settings.php”

I was always under the assumption that doing this added more security, because someone from the Internet - capital “I” :wink: - could not access my database username and password.

But for some strange reason today, I am wondering if things work the way I thought?

What is the truth?

It isn’t an assumption, it is fact. If your outside_root folder is outside of the folder being served by Apache to the public, the only way to access that folder are as follows:

  1. Direct access to the box (via SSH or being physically there)
  2. An injection was found on your site that permits a user to upload a PHP file and execute it, thus permitting the access to the files you’ve stored on your server.

The first one, there isn’t much you can do. If they get that kind of access, you are screwed. So use a strong password, or better yet, use a SSH key with a passphrase and disable typical password authentication for SSH
http://www.linux.org/threads/how-to-force-ssh-login-via-public-key-authentication.4253/

For the second, validate ALL input from your users. Do not permit unknown file extensions or mime types. If you permit image uploads, make sure they are truly images, etc.

That is what I thought, but what about this…

I have “db_settings.php” located outside of my web root with my database login credentials, and that supposedly keeps people from getting to it from the Internet.

However, since “user-profile.php” - in my web root - INCLUDES “db_settings.php” doesn’t that allow some hacker to still get the database credentials associatively?

That is what has me second guessing myself.

To be more clear, here is my current situation…

I decided to switch from mail( ) to phpMailer( ) because it is supposed to be more secure. As I am adding the code for phpMailer( ), I see that I have to give it the Username, Password, Port, etc for the Email Server on my VPS.

So I was freaked out about putting the password that I use to log in to check my email account into a PHP script in PLAINT-TEXT!!

To me, you should avoid writing down or storing passwords. Period.

Unfortunately as I found out in another thread, this apparently is a necessary evil.

So to address this, I figured I could mimic how I handled my database credentials for my email credentials, i.e. store them outside of the web root.

But the problem still seems to be that since I would INCLUDE “email_settings.php” in several scripts in my web root, that I am still basically making the Username/Password easily available to hackers… :frowning:

Does that make sense, and do you have any recommendations on how to be more secure, and how to handle things like a big enterprise would - or at least on my client’s tiny budget!!

Thanks.

Only if

1 Like

Well, I stand behind my “upload-photo.php” script. However, I do have to look closer at Apache and make sure hackers can’t upload files another way. I will have to ask advanced hosting about that.

To your other point, are you saying that as long as I prevent hackers from uploading executable files, that no one on the Internet will be able to see my database (or email server) Username/Password even though I am INCLUDING them in scripts located in my web root?

Yes with one more contingency. Are you permitting individuals to type in code and then executing that code via an eval statement? If not, you are safe.

My client’s website has forms where people can register, post comments, posts questions, send requests for information, send PM’s, etc.

Not sure what you are exactly getting at?

Think http://writecodeonline.com/php/, where you can type PHP code and execute it. If you are not permitting that and you are 100% sure about your file upload script, you are fine.

What would I have to do - or not do - to allow users to enter PHP into a form and execute it?

My client’s website has lots of HTML forms where people can enter account info, or post messages or send PM’s, and I do sanitize all of the entries - in what I believe to be a reasonable approach.

I’m still not understanding what I would need to overtly do to allow someone to execute PHP on my client’s site, or if the absence of something might allow that to happen?

I stand behind my “upload-photo.php” script. Yes.

Not sure about the first point, though.

You either

  • pass their input into eval()
  • you permit them to store a file on your server and then have PHP execute it
  • permit the user to upload a file that is not an image and let them access it via your website (to execute it)

If you are not doing any of those things, you are safe. I highly doubt you are (or that your client is)

@cpradio,

When I let someone upload a photo, I do some of these things…

  • Check for uploaded file
  • Check file size
  • Check if file is unique
  • Check file format
  • Check for upload errors
  • Check upload method
  • Check file type
  • Manipulate original upload in GD

As far as forms, as long as someone can’t run PHP in a form by typing…

Hi Mary!  How are you?
eval(some-evil-script-here.php)
What are you doing this weekend?

…then I think I am okay there.

You can let people write that, it won’t do anything.

So long as you don’t do this, you are fine:

$myuserinput = 'retrieve user input from form, sanitize it, validate it, whatever';
eval($myuserinput);
1 Like

Thanks for the tips about eval(). :thumbsup:

BTW, since it is a related topic, could you please comment on my thread: How to sanitize Contact Us form

Thanks!

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.