How safe is it to store DB variables using SetEnv or php.ini?

I don’t like to store the encryption key keys and database access information in the document_root document, so I used the Apache SetEnv and php.ini files in conf.d to separate them from the code base. The big question is: which one is better? Internal 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 this vhost has access
-Visible with PHPINFO () - A hacker needs direct access / download the exploit to files

get_cfg_var:

+ Stored outside DOCUMENT_ROOT
+ Not displayed using PHPINFO ()
- (VERY BAD) All included ini variables are included, so each vhost can request them via (ini_get_all), therefore it cannot be used in a common vhost environment

+8
php
source share
3 answers

As long as * .ini and SetEnv are outside the root of the website (document root), this does not matter in any case. Just choose what you prefer. I like SetEnv, but it's really a personal preference. It makes sense to me to use SetEnv, since variables are placed in _SERVER . With .ini, I think it makes sense to leave it to the initialization settings specific to the code.

Not storing the document at the root is a good idea to prevent access to possibly protected data.

Note that phpinfo() will display all set server variables, so be very careful.

Finally, if you include files, make sure that you do not allow the free ../../ installed by the user, or that they will have access to potentially protected files (even including /etc/passwd !)

I think your main question is "How safe." Well, it is probably as safe as you, without serious headaches. PHP code has access to these variables, so if you print them, they are easily visible, so it depends on how secure your code base is. You might be able to use LDAP with MySQL, but that sounds like a huge pain.

+4
source share

Common practice is to use non-public store files outside of document_root. A typical layout may be as follows:

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

Store your PHP stuff in documentRoot and all nonpublic stuff in nonPublicFiles . documentRoot will be Apache document_root from vHost. Since nonPublicFiles is located outside, Apache does not respond to the request.

Security Restore, SetEnv or *. ini tend to be equivalent: if someone gains the right to execute arbitrary PHP code, both methods provide reasonable information to that code.

I would prefer the SetEnv and * method . ini , since Apache will not disclose this data on its own. A script.

Misconfiguration can expose the contents of nonPublicFiles even without a script.

If you intend to use nonPublicFiles , prepare an upfront script that checks to see if everything is configured correctly and forwards the email if it detects a problem. Probably call it with CRON.

+1
source share

I prefer to store them in non-public folders, which can only be accessed through apache or outside of document_root.

+1
source share

All Articles