Page 2 of 2

Posted: Sat Jun 04, 2005 4:26 pm
by Burrito
Ambush Commander wrote:::Puts on Tin Foil Hat::
lol :lol:

too late, they've already got you...and me :?

Posted: Sat Jun 04, 2005 4:58 pm
by timvw
The point of the solution offered in the article is the following: If you want to know the db credentials you have to be root... And trust me, someone who can gain root... Doesn't even need your db credentials :p

So, not even you or the www daemon need access to the file. All you have to take care of is avoiding print_r'ing $_ENV :)

Posted: Sat Jun 04, 2005 6:30 pm
by Roja
Pyrite wrote:I did read it, and it seems it is focused on remote exploits. I am concerned about a cracker having access to my server, through whatever means and viewing my config.php to find the db credentials and viewing my database. Has nothing to do with remote exploits.
It depends on what you mean by a cracker "having access to your server". If you mean he can read some files, but not all, then you'll need to specify which.

If however, he can read *all* files on the server, then you are totally screwed no matter what, because he can just read the db files directly, or the password file, or.. Any number of other things.

Thats why the #1 recommendation in security when your box is "rooted" is rebuild. Because you can't be certain of anything being secure after that.

Security is about balance: Balancing the risk with the cost of protection.
Pyrite wrote: The fact of the matter is, my db credentials are sitting there on my server in a plain text file. That is not good! Even Windows doesn't do that. :wink:
Yes, windows does, sortof. (Long story to that - it involves the /etc/hosts file, and the windows update mechanism).

Remember, that plain text file *IS* protected. First, its got ownership permissions - its not world readable. Second, you can put it outside of your webtree.

Thats a pretty reasonable amount of security. Just what are you trying to protect, a banking site??!

Posted: Sun Jun 05, 2005 2:27 pm
by Pyrite
:cry:

Ok, I have a Windows Server 2003 Web Server (Apache/PHP) and a "seperate box" for my database (MySQL). I guess either nobody knows what I'm asking or nobody knows the answer. But my config.php looks like this:

Code: Select all

// The Database Parameters
$dbhost     	= "192.168.23.56";
$dbuser     	= "lox1";
$dbpass     	= "a$42ksL2Mj;#2Hi";
$dbname     	= "loxley";
$dbtype         = "mysql";

// Dont edit past here (ADOdb)
$db = NewADOConnection($dbtype);
$db->debug = false;
$db->Connect($dbhost, $dbuser, $dbpass, $dbname);
So, my point is if somebody can view this file, through whatever means, either by sitting down at the machine physically, or hacking in, they can see what is needed to connect to my database and do a SELECT * on all my sensitive data. That is the problem. Simply put, I don't like that fact that my database credentials (what I mean by that is user/pass/host) are in a plain text file (not encrypted or hashed), therefore human readable.

Posted: Sun Jun 05, 2005 2:35 pm
by Ambush Commander
External database! Ah... that could be a problem. Have you limited queries to the IP your PHP server is on (that way, they'd have to execute scripts off your server to mess things up)?

Furthermore, you really shouldn't have too much sensitive data on your databases. Passwords can be hashed, SS numbers, well, I don't know why you'd have those, IP addresses aren't too bad (I guess...)

Let's look at it this way. At some point, we have to talk to the database. The database goes, "You need a password." Now, obviously, you're not opening the connection, so the program that does the connections has to know the password.

Now, during the communication, we could use some secure connection to make sure that user/pass doesn't get intercepted, because we have to send it to the db server. But let's say they've compromised the database server. They have no clue what the user/pass is, but they've "rooted" the system, and they have the ability to manipulate the secure connection.

As soon as your application comes along and sends the user/pass, they've got it, encrypted on your server or not.

Posted: Tue Jun 07, 2005 10:03 am
by Pyrite
sorry to say this, but just forget it!

(throws his hands up in the air) :evil:

Posted: Thu Jun 16, 2005 5:48 am
by thomas777neo
You could probably encode the config.php file with something like ioncube.
Which is inexpensive. So if I hacked into your server and looked at your php files. They wouldn't be human readable. Then I would have to decrypt the code, which would take some skill. Nothing is 100% secure, but you can make it a pain in the ass for someone who is trying to do something malicious.

Hope this helps.

You could record the values encrypted in the config.php. But, if your username or password changes. You would have to encrypt the values then copy it back. Whereas you could only keep the encoded source on the server, then change the values in your non-encoded source. Encode the file, and upload it.

Posted: Thu Jun 16, 2005 6:31 am
by Syranide
timvw wrote:So, not even you or the www daemon need access to the file. All you have to take care of is avoiding print_r'ing $_ENV :)
But that is pretty much the same, anyone with access to that user can print $_ENV ... or am I missing something? (With other words, it can be just as easily done without root, just that now you have to make a script in 1 sec)

EDIT: and if you could commonly see the credentials you can just as well create that script, unless you really made something dumb with the credentials-file.

Posted: Thu Jun 16, 2005 6:38 am
by thomas777neo
What does $_ENV have to do with the config.php that he was originally talking about?

Posted: Thu Jun 16, 2005 7:29 am
by Syranide
timvw wrote:The point of the solution offered in the article is the following: If you want to know the db credentials you have to be root... And trust me, someone who can gain root... Doesn't even need your db credentials :p

So, not even you or the www daemon need access to the file. All you have to take care of is avoiding print_r'ing $_ENV :)

Posted: Thu Jun 16, 2005 11:17 am
by timvw
I've never talked about a config.php

I asked to read http://shiflett.org/articles/security-corner-mar2004... Perhaps it's a bit hard to grasp at first... But after a while you will see that it's really different than a config.php..

With config.php the www-daemon needs access to the file. With the file, when apache is started (at this moment apache is run by root, and thus has access to _all_ files) and afterwards www-daemon doesn't need (and shouldn't have) access to the file...

Posted: Thu Jun 16, 2005 3:31 pm
by Roja
timvw wrote: With config.php the www-daemon needs access to the file. With the file, when apache is started (at this moment apache is run by root, and thus has access to _all_ files) and afterwards www-daemon doesn't need (and shouldn't have) access to the file...
That makes several assumptions, to wit:

- httpd.conf can be edited to include that specific file (something very few virthosting customers can get)
- Apache isnt chroot'd (OpenBSD, some FreeBSD, and some linux distros do so)
- The file permissions (which arent listed in the article) have to be 400
- The apache server configuration has to be set to allow user includes (rare) AND allow setenv settings - which is even more rare, and more insecure.

All told, its pushing the problem from the very reasonable filesystem security level to the apache server config security level, which is not at all reasonable.

Stick with the common solution - set your filesystem permissions right, and get your virt host to seperate users with chroot/safemode/openbasedir. (which is actually fairly common now)