If you’ve ever programmed anything in PHP before, you’ve probably had situations where you needed to be careful with your scripts to make sure they were secure. (and if you haven’t, you probably have but just haven’t noticed)

Making secure code is often times not as easy as you would hope, and while PHP does provide certain methods to help you in your task, it still lets much of the hassle be up to you as the programmer. This construction, combined with the amount of PHP sites out there, leads to the sad fact that many insecure websites are written in PHP. And while your own website may be totally secure, perhaps because you read guides like PHP Security Guide from PHP Security Consortium, there is absolutely no guarantee hosting users on your hosting server will do the same – so you need to protect yourself!

Protecting your server, and more importantly the users on it, is really a matter of several things. You need to make sure only the services you need are running, you need to secure access routes to the server (ssh, vnc, rdp etc.), you need to put in surveillance and detection systems (Nagios, Tripwire, Snort etc.), you need to make sure the data is backed up at all times, you need a proper firewall and tons of other things. Covering all these topics is way beyond this simple post however, so we’ll only focus on protecting yourself against badly coded PHP-scripts.

If a hosting user has a website on your server, say http://www.example.org/, and on this site he creates some PHP script that loads in a file and displays this in some way. Now this is obviously a stupid example, because when would you actually need this functionality? None the less, including files like this is sadly often times done indirectly, making it possible for an attacker to load in arbitrary files and gain full or partial access to the file content. In this example however we’ll simply look at a scheme like the following:

http://www.example.org/script.php?filename=test.txt

Where this script then loads in the content from test.txt.

This kind of setup is very problematic, because an attacker can easily take the request above and change it to load other files like:

http://www.example.org/script.php?filename=../../../../etc/passwd

http://www.example.org/script.php?filename=../../vhosts/someothersite.com/secretfile.php

Where the first one loads the password file on the server (it actually only includes usernames, passwords are in another file – but you get the point) and the second one could be perhaps a configuration file for another hosting user’s blog. This way the attacker could gain access to a complete list of users and some login information for another customer.

Both these situations are obviously unacceptable, and while you can’t protect your users from themselves (at least not easily), you can protect your good users from your more reckless users.

One way of doing this is by utilizing what’s called a chroot. Chrooting basically means taking an application and forcing it to do it’s work solely within a given directory, so that i.e. Apache was only allowed to function inside “/chroot/apache” and nowhere else. This prevents websites running on Apache from reading (and writing) files outside this chroot, so that an attacker can’t use the above attack to read the password file. Setting up such chroots aren’t always that easy, since everything Apache uses during runtime needs to be available in the chroot. One project has however attempted to make chrooting Apache much easier. This project is the Web Application Firewall Mod-Security, which can be found here. They use the so called SecChroot option to easily chroot your Apache.

Chrooting doesn’t however prevent a site in the chroot from reading data in another site stored in the same chroot. To prevent this kind of attack, you’d have to logically separate each running virtual host, by either setting up a dedicated Apache chroot for each virtual host (a bad solution) or use something called suPHP. By means of suPHP, which can be found here, we can make Apache run PHP scripts under the permissions of the owners of the scripts, instead of the normal Apache user which is shared between all virtual hosts. By doing this, we effectively make each virtual host able to only read/write files in its own directory and not spy on other virtual hosts data (assuming these have set correct permissions).

But what if we don’t trust this is enough? What if we want to be completely sure, that even if users set wrong permissions, a given user could still never read or write in another users virtual host? This can be accomplished by means of the php open_basedir option. The open_basedir option can be used to control in which directory the PHP scripts of a virtual host can work. This effectively means we’re actually chrooting the PHP scripts! The way you do this, is that you open up your virtual host configuration (which is probably stored somewhere like “/etc/apache2/vhosts/somevhostcom.conf”) and you then add the following within the <VirtualHost></VirtualHost> pair:

php_admin_value open_basedir /var/chroot/apache/vhosts/somevhost.com

Where “/var/chroot/apache/vhosts/somevhost.com” is the location of the virtual host directory. (be aware: If you’ve chrooted Apache, this path needs to be relative to the chroot and not the actual system).

Using open_basedir is not without it’s problems though. By making the PHP scripts run in what is effectively a chroot, they can’t i.e. write to the /tmp directory, which basically means file uploads won’t work. Be aware that chrooting in general can often lead to these types of issues, which is also why many server administrators just simply choose to take the risk and run Apache without chrooting.

Last but not least you can also use Mod-Security as what it was created as – a Web Application Firewall. A Web Application Firewall is a software firewall placed onto Apache, which then uses a complicated rule set to analyze traffic to the server and identify what kind of traffic is an attack and what is just normal use. These rules however have to be written, at least to some extent, manually and there are issues regarding making rules that catch illegal behavior but never stops legal requests – usually you have to accept some level of false-positives in attack detection if you want to be as secure as you can be.

That’s it! We hope you’ve become a bit more informed now and can get on with making your server secure against bad php scripts. Until next time – Keep safe!

NOTE: This is a technical post regarding Apache on Linux with support for Ruby on Rails. Basic understanding of these concepts is necessary!

Normally you want to make sure your server doesn’t give out any information about service versions, however mod_rails doesn’t provide any easy way of doing this within the module itself. There is however a fairly easy solution. Simply use mod_headers to remove the headers in Apache.

So how is it done? Very simple, just enable the module mod_headers and add the snippet below to httpd.conf or another included configuration file in Apache. Both actions have to be done as root of course.

Enable the mod_headers module (This example is Linux Debian – it might be different for your system)

# cd /etc/apache2/mods-available/
# a2enmod headers

Add these lines to httpd.conf

Header always unset "X-Powered-By"
Header always unset "X-Runtime"

Restart the Apache server (Again – this is Debian! It might be different for you)

# apache2ctl restart

And there you go. Try making e.g. a Nikto scan on the server and see if the headers aren’t there any more.