- the php files are usually world-readable, meaning that anyone with shell access to the server has full access to your db passwords, even if they only have an unprivileged account
- if you are using version control, the passwords are needlessly replicated to all the tree checkouts. If someone's home machine gets compromised, you will have to change all the database passwords as well. Changing database passwords always involves a blip in uptime because changing the password in your db software is not simultaneous with changing it in your web scripts.
- the same applies if an employee in your organization leaves.
- if for some reason the apache configuration becomes screwed up and your php handler disappears, then the server will output the php code as text, exposing all passwords contained within.
The solution is to store these passwords separately from your main app tree and only readable by root. Doing a simple php include from somewhere outside the web tree will problem #4 above, but it still won't address the other concerns. If you have full admin control of your apache server, you can go further than that.
Apache reads config files as root, so we'll take advantage of that.
- Create a /etc/httpd/conf.d/passwords.conf
- Put your password information in the form:
# disable phpinfo, to prevent accidental leaks
php_admin_value disable_functions phpinfo
SetEnv mysql_user_password SecretPassXX
SetEnv some_other_password AnotherPassXX
- Set permissions on passwords.conf by doing:
chown root:root passwords.conf
chmod 0600 passwords.conf
Now this file is only readable by root.
- You can now access these passwords from your scripts using:
- The passwords are not accessible outside your application's immediate execution environment
- The only way an attacker can get these passwords is to execute arbitrary code in the context of your application, which is quite a bit harder than simply being able to output arbitrary files (e.g. via directory traversal vulnerabilities)
- Underprivileged accounts, including php scripts that are executed in another directory can't get to the passwords
There are caveats with this solution as well. E.g. you have to be careful about doing things like phpinfo() or var_dump($_SERVER) (which is why I include the code to disable the phpinfo() using the php_admin_value disable_functions phpinfo parameter).
I think overall this helps significantly tighten the security of web applications, especially in shared environments.