SetEnv is passed to all cgi scripts for which that part of the .htaccess file is evaluated (although those scripts may also be able to access a config.php file). Furthermore, it may appear on print_r's of the _SERVER variable, such as in phpinfo().
–
LegolasApr 17 '12 at 7:34

(Of course, with this suggestion, the database password is not stored in the .htaccess file; instead, it is stored in a separate configuration file. But the difference is inconsequential.)

Important: Make sure that sql.cnf is not stored within your web root. If it is stored in your web root, maybe anyone who knows the right path to it will be able to request it just by sending a GET request.

There is an additional risk with storing passwords in a sql.cnf file within your webroot, which is a bit obscure but can be easily avoided by placing the file outside of your web root. Consider: if you are editing sql.cnf using a text editor, and your connection drops while you are editing it, your editor will automatically save a copy of the sql.cnf file in some backup file: e.g., sql.cnf~ (in the same directory). Now the backup file has a different extension, so if someone tries to fetch that file, the Apache server will happily serve up a copy of the file in plaintext, revealing your database password. See 1% of CMS-Powered Sites Expose Their Database Passwords for details.

There are some caveats with this, first one would hope that the path: /home/ilia/sql.cnf is not located within the webroot of your website, or an attacker could simply visit the url http://ilia.ws/sql.cnf to view your database credentials.

Additionally one would hope that your website did not include various information disclosure bugs or a phpinfo page as phpinfo will dump the $_SERVER array and thus disclose your database credentials to any visitor of this page.

Further more the assumption that it would be harder for an attacker to obtain the information if it's stored in a PHP file versus environment variables is rubbish. Your example sets the environment variables for every page request. That means that a directory traversal attack which may not have permissions to read your sql.conf file will still probably have permission to read /prof/self/environ and obtain the credentials that way.

I would ensure that your database server is bound to the loopback interface, that your database credentials have the lowest possible privileges and that your web application and server software are patched in a timely manner and just store the credentials in the php file.

The recommendation is predicated on the fact that PHP files will be world-readable but .htaccess files / httpd.conf won't. The author rightly points out that using encryption to hide these values doesn't help - since that means the encryption key needs to be accessible to PHP code. But storing the values in the environment only avoids some issues which are also avoidable by other means. Values in an httpd.conf file will be readable by any PHP code run on the server. Moving them into a vhost defn narrows the visibility. You can keep them as PHP code within the document root by simply prepending the filename with '.ht'.

Certainly it's good practice to maintain the tokens indepently of the bulk of the code. Since

they will have a different lifespan than the code (i.e. may need changed independently of the code and vice versa)

should not be exposed via code management facilities such as the version control system

should vary depending on where the code is deployed (i.e. different tokens for test / stage / live)

However using the webserver config is only one way to achieve this - there are other valid approaches.

Regardless of which route you take, the security of the solution will come from considering all aspects - file permisssions / accessibility of the file, restrictions on DB connection, access controls at the DB