9

I know that the question How do I secure my database connection credentials? has been asked and answered multiple times (e.g. How to secure database passwords in PHP?).

A commonly accepted answer to that question is to store the details outside of the web root. But I'm curious as to why this really makes much difference.

From what I understand, a person cannot download the source of the PHP file via HTTP (unless your web sever is not configured properly, but you would know about that right away). So you won't be able to see the credentials unless you have access to the source of the PHP file anyways. Correct me if I'm wrong, but doesn't this basically mean that you would need shell access? And if you have shell access, can't you just get to the file outside the web root anyways?

If the answer to that question is that the include file might have special permissions that don't allow anyone but the web server user to read it, then (considering that I have shell access), couldn't I just write (or modify) any PHP file to just echo out those credentials?

So the question is, does it really make any difference whether you store the credentials directly in the PHP script vs. in a file outside the web root?

Community
  • 1
  • 1
Travesty3
  • 14,351
  • 6
  • 61
  • 98

3 Answers3

8

Suppose, due to a error in the webserver, the webserver no longer processes php files, but treats them as html files.

In that case something like http://mysite.com/config.php would simple reveal the credentials of your database.

So the answer is: Yes, it does really matter, where and how you store the database credentials.

JvdBerg
  • 21,777
  • 8
  • 38
  • 55
  • 1
    Yes this actually happened to facebook once! http://techcrunch.com/2007/08/11/facebook-source-code-leaked/ – fire Oct 11 '12 at 13:51
  • Or prevent this bug: http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/ – Tchoupi Oct 11 '12 at 13:53
  • @Dev The question was: *why should we store db credentials outside the webroot?*. This answers the question. – Tchoupi Oct 11 '12 at 13:54
  • This is pretty much the answer that I was expecting, but I was also trying to find out if there were other, more hacker-related reasons to do this. Do you know if there is any way that the web server would develop such an error (aside from me screwing it up myself)? I agree that the possibility of me screwing it up is, by itself, a good enough reason to do this, so I'm not disagreeing...just trying to find out all the potential risks. – Travesty3 Oct 11 '12 at 13:57
  • There can always be a situation where the webserver will stop server the file extension. A segfault, a bug in PHP, without messing up yourself. You could choose a file extension that is not served by the webserver at all, and read the config by a file_get_contents or similar. – JvdBerg Oct 11 '12 at 14:07
  • Thanks for the info. Tough choice for the accepted answer between this and @NickiC's answer, but I chose this one since it was answered first, gave some detail (in the comments), and, well, NickiC already has a ton of rep. Both answers are very useful...thanks! – Travesty3 Oct 11 '12 at 14:13
5

The main issue is that the web server might break down later on. E.g. after a software update php might not work properly anymore and the server falls back to delivering the files directly. Or again after a software update the configuration might be reset, so PHP is no longer registered for the file extension. Or the server breaks down under heavy load and also starts delivering files plainly.

Many things can happen and it's rather easy to mess up the config at some point. Better be safe and keep it outside the document root.

NikiC
  • 100,734
  • 37
  • 191
  • 225
  • Very good point. That's more of what I was looking for. I hadn't thought of software updates and that sort of thing messing up configurations. Thanks! – Travesty3 Oct 11 '12 at 14:05
0

  1. Create an O/S user for your application, such as 'UserForMyApp'

  2. For that user, create an O/S user environment variable 'MY_APP_DATABASE_PASSWORD', and set the value

  3. Run your app as 'UserForMyApp'

  4. In MyApp, read the O/S user environment variable 'MY_APP_DATABASE_PASSWORD' and use that to login to the database

Other non-root users cannot read an O/S user environment variable for another user. This is default. You don't have to set anything, unlike w file permissions.

There is no chance of storing the password in source control by accident.

If db and app are on same machine could just let db trust local access without password.

Neil McGuigan
  • 46,580
  • 12
  • 123
  • 152