safety of password in config file

mfacer

if I use an include such as "config.php" - how safe is it?? if I stored a username and password for example? Can people access the file in anyway??

bodzan

...if it is not protected someow by a htacces file or some other way...

It is recommended that you place that file somewhere outside www root so nobody can access it via web protocols...

For example (if your using Linux): say your www is placed in somewhere like /usr/name/www/...
Then, if you place that file in /usr/name/ you still can access it through your PHP files by calling to it like this: /usr/name/config.php

Hope this helps you...

Kudose

How can someone view the contents of this file?

Filename :: config.inc.php

Contents:

<?php
$myDb->dbLoc = "localhost"; //this is the location of your database.  Most often localhost
$myDb->dbUser = "xxx_xxx"; //this is the username to your database
$myDb->dbPass = "xxx"; //this is the password to your database
$myDb->dbName = "xxx_xxx"; //this is the name of the database used
?>

Accessing it directly simply displays a blank page.

???

TIA.

Sayian

Just so you know , if your including a file of importance such as config.php , you should require it once , not include it. Both Include and Require pretty much use the same thing , but to require the file is better if it's of top importance b/c if you accidently forgot / mis-included it it would produce a fatal warning.

Replace all your Include('config.php');
with
require_once('config.php);

It's just better practice.

bodzan

...if for nothing else, because it can be accessed by anyone. Or am I mistaken big time?

I figure that one might want to use the URL on from their own web server to access it and then there might be trouble, isn't it?

I'm not a hacker, but that seems to me like an unnecessary risk...

Besides, like this guide says:

Of course, one simple solution is to place all modules outside of document root, and this is a good practice. Both include and require can accept a filesystem path, so there's no need to make modules accessible via URL. It is an unnecessary risk.

Anyways, I'm not sure on any of this since I'm not any security guru of any kind, but it's just my common sense...

Sayian

Here's an example of security in action.

make a file called test.php

upload it into your document root.

now type in your web address ..
http://www.yourdomain.com/test.php

you can accesss it right?
Now move test.php up one level above your web root to /home/whatever

How would you access the file test.php?

you cant , at least not via a web browser

But , for your php script's you can still use this file simple by
require_once('/home/whatever/test.php');

But the file Cannot be accessed via a web browser ... Much more secure.

bodzan

...I don't know how to missuse a file or whatever hackers do, but I figured that much...

nemik

Originally posted by bodzan
...I don't know how to missuse a file or whatever hackers do, but I figured that much...

i think i have an idea...what if you found someone's config.php. you could make your own test.php somewhere on yourdomain.com/test.php and do an include("http://www.victim.com/config.php")
and inside your test.php you write echo $pass; echo $password; etc to see if you can find any of them.

that is if the config.php is located in the root directory, no? or does include() and require() only accept files from your root directory and not other domains?

either way, by putting the config.php somewhere in usr/private or something like that inaccessible to the outside world, it should be much more secure.

just my 2 cents...

bodzan

I know that there is a way to read a file from other server (not sure how or why would one do that)but I just didn't do that not once and I really have no idea whether it can be defended against...

I figure it could I'm just saying that the script like you describes is one way to expose access credentials I was thinking about...

So why risk it? Place it outside the web root and you could be pretty safe from outside interference. Or is there more efficient way to defend one's config.php file?

Kudose

Good responses.

Thanks.

nemik

Originally posted by bodzan
I know that there is a way to read a file from other server (not sure how or why would one do that)but I just didn't do that not once and I really have no idea whether it can be defended against...

I figure it could I'm just saying that the script like you describes is one way to expose access credentials I was thinking about...

So why risk it? Place it outside the web root and you could be pretty safe from outside interference. Or is there more efficient way to defend one's config.php file?

exactly, there is no need to risk it and i will be changing mine now too because i read this!

i already keep all my cron jobs in a private folder with no web protocol access since it would be VERY bad if anyone could just call my scripts by loading them in a URL no matter in how many subfolders i hide them in. security through obscurity is not security. 😉

bubblenut

Originally posted by nemik
i think i have an idea...what if you found someone's config.php. you could make your own test.php somewhere on yourdomain.com/test.php and do an include("http://www.victim.com/config.php")
and inside your test.php you write echo $pass; echo $password; etc to see if you can find any of them.

that is if the config.php is located in the root directory, no? or does include() and require() only accept files from your root directory and not other domains?

either way, by putting the config.php somewhere in usr/private or something like that inaccessible to the outside world, it should be much more secure.

just my 2 cents...

No, you can't do that. If you're getting the file from another site (through http as you would have to in this scenario) it is the webserver that is serving up the file, it is the webserver which commands PHP to be executed on certain pages and therefore all you would be given is what the webserver serves up to you, not the file itself. In short, calling include('http....') would give you the same result as opening the same url in yor browser. There is a lot to be said for keeping important files out of your webroot though. As has been already been mentioned, there is no reason for it to be in the webroot so why have it there. Also, you are relying on your webservers recognition that that file is a php file to secure it which is unnecesarry when you can just leave it outside of the scope of files to be served.

I would say only keep files which are being served directly in your webroot as then you are only relying on your server to know which directories it's allowed to server, something far easier for it to di than to figure out which specific files should be served.

Let's look at a scenario. Let's say that for some reason the PHP install goes down (prehpase someone messes up an upgrade and it all goes doolaly) for that period the webserver would continue to attempt to server the files through PHP but there's no working PHP there. It may (depending on the webserver) decide to just serve them up as-is instead. if you had your config files in your webroot that would mean that, for the time that PHP is down they are being served up as plain text and therefore viewable to the public. Needless to say, that would be a bad thing.

mfacer

Originally posted by bubblenut if you had your config files in your webroot that would mean that, for the time that PHP is down they are being served up as plain text and therefore viewable to the public. Needless to say, that would be a bad thing.

I never thought of that! I think for this example, I might just use a database to store the username and password. Seems more secure. Also I will move the db files and any data such as that to off the http server and into another folder.

Some really good advice posted above - thanks guys 🙂

nemik

Originally posted by mfacer
I never thought of that! I think for this example, I might just use a database to store the username and password. Seems more secure. Also I will move the db files and any data such as that to off the http server and into another folder.

Some really good advice posted above - thanks guys 🙂

i agree, that was an excellent point even if it could be rare. keeping usernames and passwords on sql, i already do that, but it is protecting the database username and passwords i'm worried about. so got to go hide my config files in private folders. 🙂