(Many thanks to everyone for their feedback on my first post in this series.)
Most of us started out hosting our code on shared hosting, whether it was on a box provided by an ISP, something we rented ourselves, or something we built so that we had somewhere to host the websites we built for our customers. Love it or loathe it, shared hosting has some unique security challenges, and understanding those challenges is a good way to learn the fundamentals of how your web server actually works.
This article is looking squarely at Linux systems running Apache, which is by far the most common shared hosting platform, but the principles involved apply to Lighttpd or any other Apache alternative running on Linux.
What Is A Shared Server?
For many web developers, their first experience of hosting code on the Internet comes on a shared server. Shared servers offer cheap hosting, but that’s because there are many different people sharing the same server and therefore sharing the costs.
A shared server is a single server that hosts more than one website. Each website may be owned by a different company, group, or person. Typically, each customer on the box has a user account which they log into to upload new files for the website. Each file that the customer uploads is owned by the customer’s user account:
ls -lh ~thecube/public_html
drw-r--r-- thecube public 4K images
-rw-r--r-- thecube public 1.2K index.php
Apache Needs Access To Your Files
On your classic shared hosting server, there’s one copy of the Apache web server running, and PHP is installed either as mod_php, or as a CGI executable. That one copy of Apache handles all the incoming HTTP requests for all the websites that are sharing the server. When Apache is running in this way, it runs as a specific user – normally www, or apache (or nobody on badly-configured systems).
In order to serve up your website, Apache needs to be able to read your HTML files, CSS files, images, PHP scripts and so on. Some web applications (blogs, content management systems and so on) also need write access to your website’s directories.
Read and write access is normally granted by setting the group permissions on a file or directory. Each customer’s user account, and Apache, are members of the same group. By default, the FTP daemon will be set up to ensure that the group has read access to all of the files that are uploaded, so that Apache can serve the website.
Apache Has Access To Everyone’s Files
There is one copy of Apache, and it runs as a single user – no matter which website is being served. This single user has read access to every single website on the shared hosting server, and it probably has write access to most (if not all) of the websites too.
An attacker from the outside only needs to break into one website on the server, and that will give him access to every other website hosted on the same box!
But here is the rub. The attacker doesn’t need to break into the box. He can just as easily become a customer, get a legitimate account on the box, and then just upload PHP scripts to access the other websites hosted on the box. Provided he’s careful and doesn’t change anything, he can steal whatever data he wants, and no-one will even notice.
Why does that work? It’s possible because the PHP code is executed by Apache – and Apache has access to all of the files from all the websites on the box. That includes all the PHP scripts that contain the usernames and passwords for all the MySQL databases.
This is the worse-case scenario – but it’s also the default scenario. Slap Apache + mod_php on a box, start putting websites on it, and these security problems will exist, unless you (as the server administrator) take additional steps to prevent them.
The Challenge
The challenge with securing a shared hosting server is this: how do we put as many websites as possible onto the one machine without each customer being able to steal sensitive information, or interfere with, any of the other customers that they are sharing with?
There are a few ways to tackle this, which I’ll cover in the next article or two.
This article is part of The Web Platform, an on-going series of blog posts about the environment that you need to create and nurture to run your web-based application in. If you have any topics that you’d like to see covered in future articles, please leave them in the comments on this page.
14 Comments
November 21st, 2007 at 9:38 am
[...] You can read the rest of this blog post by going to the original source, here [...]
November 21st, 2007 at 12:22 pm
Will you be talking about “caged” environments and how to set them up?
I believe Site5 is configured that way.
November 21st, 2007 at 8:31 pm
Personally, I use apache with mpm_itk and it works like a charm.
November 21st, 2007 at 11:35 pm
@Nicolas: mpm_itk is one of the solutions I’m going to cover in the next article. It solves the problem, but at a cost that won’t be acceptable to everyone.
November 23rd, 2007 at 6:01 pm
How can you keep us waiting?
It’s shaping up to be an interesting series.
November 27th, 2007 at 3:13 am
Will you be looking at mpm_peruser? It probably has some of the same drawbacks that mpm_itk has, but it would be interesting to get more information about it.
November 27th, 2007 at 9:12 am
[...] my last article, I covered the fundamental security problem that exists when you have multiple websites owned by [...]
November 27th, 2007 at 4:50 pm
[...] up on a previous article, Stuart Herbert has posted some of the things that PHP can do to help solve the previously [...]
December 18th, 2007 at 9:10 am
[...] The challenge with securing a shared hosting server is how to secure the website from attack both from the outside and from the inside. PHP has built-in features to help, but ultimately it’s the wrong place to address the problem. [...]
January 18th, 2008 at 8:10 am
[...] The challenge with securing a shared hosting server is how to secure the website from attack both from the outside and from the inside. PHP has built-in features to help, but ultimately it’s the wrong place to address the problem. Apache has built-in features too, but the performance cost of these features is prohibitive. [...]
March 20th, 2008 at 5:34 pm
[...] The challenge with securing a shared hosting server is how to secure the website from attack both from the outside and from the inside. PHP has built-in features to help, but ultimately it’s the wrong place to address the problem. Apache has built-in features too, but the performance cost of these features is prohibitive. [...]
April 19th, 2008 at 1:00 pm
[...] The challenge with securing a shared hosting server is how to secure the website from attack both from the outside and from the inside. PHP has built-in features to help, but ultimately it’s the wrong place to address the problem. Apache has built-in features too, but the performance cost of these features is prohibitive. [...]
July 12th, 2008 at 2:21 pm
[...] is such that its impossible to make it secure in a per user way. After reading Stuart Herbert discussion of the pros and cons of different solutions to this problem, i decided to look into it further.On [...]
September 14th, 2008 at 9:23 pm
Hello,
We currently run a PHP/FastCGI + suexec setup. Our main problem now is safe_mode_exec_dir configuration that is going to be removed in PHP6. It allows to only use exec, system from a specified directory. And we can make sure that that directory is safe and only root can write there so scripts there are safe to execute.
And the only available solution to this afaik is chroot. But to chroot your web application you must copy some of the libraries .. mysql, dns, libm, libz and so on. The problem is it’s very hard to know which required libs are needed. So you copy them all. You use a lot more disk space. And you need some kind of updates system to update your libraries when system libraries get updated. So it doesn’t seem elegant and clean.
Do you know a better solution for this problem? If not .. It is really sad safe_mode_exec_dir is getting removed.