One of my biggest pet peeve's since I got into php web application development is the insecurity of many popular web applications out of the box. I am not going to detail all the issues in this post, just one that really gets under my skin: The security of the configuration file.
Most web applications use some sort of database backend. At a minimum, the application needs a configuration file to tell the application what host the database is running on (often localhost), the name of the database the web application is using, and how to authenticate with the database. Usually the configuration files contain a lot more than just that.
In the interest of trying to get the web application installed on as many servers as possible so the developers can have bragging rights, they often spend a great amount of time developing web based administration tools to these configuration files so that people who do not know what they are doing can throw the web application up on a server somewhere and start using it. Unfortunately, many if not most of these developers do it wrong, putting their users at an un-necessary risk.
The problem? The config files are written in PHP, parsed by the web server as PHP, and the web server has write permission to the configuration file.
Never ever give the apache user write permission to a directory it serves or a file it executes. This is very basic security, so let me repeat that. Never ever give the apache user write permission to a directory it serves or a file it executes. Doing so opens you up for the possibility of a remote exploits.
Unfortunately, that is exactly what many of these web developers do, often even instructing the user to chmod 777 the configuration file.
When installing a web application, there are several things you should do before the web application ever goes live:
A) Always make sure configuration files are outside the web root. If you do not know what this means, either educate yourself or hire someone who does know. If configuration files are in the web root, a mis-configuration of the apache server or a bug in the apache server could result in the configuration file being served to a cracker. Making this change may require you tell the web application the new location of the configuration file, but that can usually be accomplished with a simple sed expression.
B) Always make sure the the web server does not have write permission to the configuration file. This may break web based admin tools, but most configuration files are easy enough to understand that you should be able to simply edit them with a text editor (ie emacs, vim, etc.) when you need to make a configuration change.
Do those two steps, and your web application install will be a lot more secure.
Unfortunately, it sometimes isn't that simple. You may need to make the admin interface available to other people who do not have shell access to the server, or otherwise should not be hand editing a configuration file.
In those cases, what I tend to do involves porting the configuration file to XML. XML is a great way to store configuration information.
You will need to write a php script that loads the XML configuration file and extracts the configuration settings. This is easily done with the DOMDocument facilities that should be available in any modern php install.
Once you have properly created an XML format for storing the configuration options and a script to load it and take what it needs, you will need to re-write the admin interface to change settings within the XML file. Again, this is easily done with the DOMDocument facilities of php.
Finally, you need to protect your admin interface from potential system crackers. The admin interface should only be accessible over an SSL connection. It is a good idea to use apache authentication to protect the directory that contains your admin interface. I like to use AuthType basic authentication with a .htpasswd hash. If the web application has its own user authentication, you can use that as well but do not use it in place of apache authentication. If your web applications authentication system has been compromised, use of apache authentication may still prevent the cracker from modifying your web applications configuration.
No comments:
Post a Comment