According to Apache documentation:
.htaccessfiles (or “distributed configuration files”) provide a way to make configuration changes on a per-directory basis. A file, containing one or more configuration directives, is placed in a particular document directory, and the directives apply to that directory, and all subdirectories thereof.
Many PHP web applications use .htaccess files to restrict access to specific files or directories that may contain sensitive information. For example, in order to restrict access to all files in a specific directory you can create a .htaccess file in that directory containing the string “deny from all”. In many cases it is wrong to impose security restrictions using .htaccess files. The reasons are:
- The functionality of .htaccess files depends on the value of the AllowOverride Apache directive. If this directive is not configured properly, your security restriction will not work. You could have a web application that works perfectly on your Apache web server where AllowOverride allows the usage of .htaccess files. But when you install the web application on another server with disabled AllowOverride, the security restrictions will not work and your web application will become vulnerable.
- Most modern PHP based web application can be installed on other web servers that do not support .htaccess files such as nginx, a web server that is gaining popularity. There are other web servers that don’t support .htaccess files. When developing a web application which is going to be used by to the public, one should not expect that everybody will use Apache. If the security of your web application depends on restrictions imposed by .htaccess files, as soon as one of your customers installs the application on an nginx web server, they will be vulnerable.
Below are two real life examples of web applications that are affected by this problem, which unfortunately is a pretty common practice with PHP web applications.
Zen Cart log files contain database connection settings.
When installing Zen Cart an installation log file is created which contains sensitive information such as PHP configuration values, directory permissions etc. It also contains that database connection information, i.e. database server, database name, database username and password. Below is a screenshot of such log file:
Access to this installation log file should be restricted and as a matter of fact Zen Cart uses an .htaccess to restrict access, and filename obfuscation to make it difficult to guess. The first protection is rendered useless if Zen Cart is installed on a web server that doesn’t support .htaccess files or if AllowOverride is turned off. What about the second type of protection, i.e. filename obfuscation? The name of the file is:
As you can see the name of the installation log file contains a prefix zcInstallLog followed by the date when the files was created and a counter. It’s trivial to create a script that starts from the current date and moves back day by bay until it hits the correct filename. The number of combinations required is pretty low. Because the .htaccess protection doesn’t work the file will be accessible to an attacker.
I have contacted the Zen Cart author and reported this problem and it has been fixed in the latest version of Zen Cart.
Magento configuration file
Unlike Zen Cart, with Magento you do not need to do any guessing to get hold of the database connection details. The configuration for this application is stored in a file “/app/etc/local.xml“. This configuration file contains database connection information, i.e. database server, database name, database username and password and other sensitive information. To restrict access to this file an .htaccess file in the app directory is used, and on an Apache web server with proper AllowOverride configuration you cannot access this file. However, if you install the application on nginx web server, the directory restriction doesn’t work and it is possible to access the configuration file.
I have tried to contact Magento several times in the past 18 months but I didn’t receive any response from them. If you are running Magento on nginx you can apply the following workaround; insert the following code in the server section of your nginx configuration file:
location ~ /app/etc/local.xml {
deny all;
}
This should restrict access to the configuration file. Magento wrote a Wiki article about installation and configuration on nginx but their configuration file does not protect against this problem. If you are using Magento on Apache you must check if AllowOverride is turned On by checking your web server configuration.
In the end, I would like to suggest a solution about storing sensitive information without using .htaccess security restrictions. If you have configuration files, they should be stored as .PHP files and included for evaluation. The same can be done for log files BUT you need to make sure that your log entries will not be evaluated as PHP code. For this you can prepend the log file with code to terminate the script execution, as shown below:
<?php exit; ?>
----------------------------------------------------
This is a log entry (<?php phpinfo(); ?>)
Second log entry.
In this case, even if an attacker gets access to this file, the hacker still cannot see the contents of the file.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
