Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm interested in comments and strategies for protecting PHP config files, particularly those with Db credentials.

The stock advice, set the file extension to *.php, is fine as far as it goes, but it does not protect against directory perusal attacks. The particular scenario I'm considering:

  1. We have a server that hosts a variety of third party apps.
  2. We cannot thoroughly vet all apps
  3. If an attacker compromises an app, they can potentially use that app to read files from other directories. Db config files are an obvious target.

I have a solution, one that seems to have merit, but I'm not entirely comfortable with it. I'd love to hear comments on it, as well as

  1. find what php_include is set to
  2. place the config file in that directory
  3. make sure the require/include statements that load the config do not specify hard path (no leading ./ etc.)

GOALS

  • hides the config file completely from an errant sister web app (and more importantly from the webserver itself).

  • obscures the actual location of the config file. It cannot easily be determined from reading the code. This is opposed to specifying a path outside of the web tree.

  • minimal intervention, both on a server level and on an app level.

  • Avoids hard coding the path.

This does not address config file name conflicts, although more then a few apps it's probably worth changing the include config file name.

Unfortunately a lot of our web apps appear to require hard coded paths.

What approaches have others come up with?

share|improve this question
add comment

1 Answer 1

Standard advice applies:

  • Place config file above the web root
  • Use .htacess or similar to deny access to these folders
  • Use file permissions to protect folders

Even better advice:

  • Ensure your DB server can only be accessed by your webserver by both network/firewall ACLs and by it's own host based authentication
  • Don't use passwords, use certificates/Kerberos/PKI (a brief google has this suggestion for implementing this in MySQL)
  • If you don't trust an app, run it on it's own webserver that doesn't have access to other apps files
  • Use a tripwire for intrusion detection

Hiding config files as you suggest seems futile, once an attacker has control of your system in this way, it's game over anyway. You are just making your own job harder of maintaining your webs apps harder with little security gain.

share|improve this answer
    
Thank for the PKI suggestion. I was unaware of this possibility. –  Joe Fortier Nov 11 '11 at 18:55
    
I appreciate the response. That said, I do think there is some point to "hiding the config file". Essentially I'm cutting one class of attack (compromised sister web app that can be used to read FS). What I'm attempting to do is pretty much bullet point 1, "Place config file above the web root". The point of loading it in the default include directory is to avoid changing the code of the third party web apps. Unfortunately most of the web apps go through some pains to keep you from moving the config file. –  Joe Fortier Nov 11 '11 at 19:03
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.