This blog is a gripe. A whine. I'm bitching. Just a warning.
Sometimes it is necessary to deprecate functions and change how a programming language works. Other times, it makes little or no sense.
Manuel Lemos of phpclasses.org blogs about a coming change here: The Plot to Kill PHP MySQL Extension. Read his thoughts, they are better phrased than mine.
While not my personal choice, MySQL is without a doubt the most widely used RDBMS in PHP web applications. It has a long history with PHP and numerous web applications currently use the very PHP MySQL Extension that is on the chopping block.
As Manuel points out, there are other ways to connect to MySQL. Many web applications and classes however use the extension that the PHP developers wish to deprecate. Deprecating the PHP MySQL extension is a bonehead move. Are there better ways to do things? Absolutely. Should web developers update their code to use these better methods? Absolutely. Is it still a bone headed move to deprecate it? Absolutely.
From my point of view, the problem is cost. Someone has to go through the code and make all the changes. Then once all the changes have been made, the code has to be tested. If the web application is actively being developed, the developer should update their code base, but not all web applications are actively being developed and there are many cases where using updated versions from the vendor is not easily done.
For example, I use the search engine sphider on some web sites I maintain. I hacked the crap out of it to beef up security, make it output DOMDocument nodes instead of raw HTML, did some major hacks to the admin interface to fit sphider administration into the general web site administration and remove options that would only confuse the non tech people using the admin interface, and some other tweaks.
Sphider (at least the version I started with) uses the very MySQL extension that is on the chopping block. Now I will either need to fix sphider for these web sites, get an updated version of sphider and hack the crap out it as well, or implement a different solution to site search. I like to be a charitable guy, but I do not work for free. All three of those options are going to cost someone some real money when the next version of PHP released and the boss wants to know why the apache log is full of deprecation warnings.
Yes, this highlights the importance of using database abstraction. No, most web applications do not use database abstraction (wish they did, make it easier for me to run stuff on PostgreSQL without needing to hack it) and there are a lot of legacy web applications out there that will break when this module is no longer available.
This is the kind of move that makes PHP expensive for companies to use, and the PHP core developers really need to think about this.
Friday, July 15, 2011
Wednesday, July 13, 2011
Web App Security and Configuration Files
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.
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.
Subscribe to:
Posts (Atom)