How secure is storing DB variables with SetEnv or in php.ini?

Question

I don't like storing sitewide crypto keys and DB access information under document_root, so I was using Apache's SetEnv and php.ini files under conf.d to separate these from the codebase. The big question is, which one is better? Inside environment variables under apache vhost files (SetEnv SITEKEY 'oinkoink!') or inside conf.d/xxx.ini files (db_pass="oink?")? Maybe something else?

PROS n CONS:

SetEnv:

+Stored outside DOCUMENT_ROOT
+Only the given vhost has access
-Visible with PHPINFO() - Hacker needs direct access/upload exploit to files

get_cfg_var:

+Stored outside DOCUMENT_ROOT
+Not visible with PHPINFO()
-(VERY BAD) All the defined ini variables are included, so each vhost can query them via (ini_get_all), so not usable in a shared vhost environment

Surprise

Answer 1

As long as *.ini and SetEnv are outside of the web root (document root) it doesn't matter either way. Just choose whichever you prefer. I like SetEnv, but it's really just personal preference. It makes more sense to me to use SetEnv since the variables are put into _SERVER. With the .ini, I think it makes more sense to leave it for initialization settings specific to how the code works.

Not storing under the document root is a good idea to prevent access to possibly secure data.

Note that phpinfo() will list any server variables that are set, so be very careful about that.

Finally, if you are including files, make sure that you don't allow gratuitous ../../ set by the user somehow or they will have access to potentially secure files (even including /etc/passwd!)

I think your main question is "how secure." Well, this probably about as secure as you can get without causing major headaches. The php code has access to these variables, so if you print them out they are easily visible, so it depends on how secure your code base is. It might be possible to use LDAP with MySQL, but that sounds like a huge pain.

Kaspar

Answer 2

It's common practice to use store non-public files outside of document_root. A typical layout could be this:

.../myProject
.../myProject/documentRoot
.../myProject/documentRoot/.... 
.../myProject/nonPublicFiles
.../myProject/nonPublicFiles/...

Store your PHP stuff in documentRoot and all non-public stuff in nonPublicFiles. documentRoot would be the Apache document_root of the vHost. Since nonPublicFiles is outside, Apache won't answer request.

Recarding security, SetEnv or *.ini tend to be equivalent: In case someone gains rights to execute arbitrary PHP-Code, both ways provide the sensible information to this code.

I'd prefer the SetEnv and *.ini method, since Apache won't disclose these details itself. A script is required.

Misconfiguration may disclose the contents of nonPublicFiles even without a script.

If case you are going to use nonPublicFiles, prepare upfront a script, which checks if everything is set up fine and forward an email, if it found problems. Probably call it using CRON.

Medor

"In case someone gains rights to execute arbitrary PHP-Code..." -- If this happens all bets are off and you are thoroughly pwned no matter where you store the db creds. – Keyser

Answer 3

I prefer storing them in either non-public folders, which can be accessed only by apache, or outside the document_root.

Neckerchief