The Challenge With Securing Shared Hosting
Posted by Stuart Herbert @ 9:04 AM, Wed 21 Nov 07
Filed under: The Web Platform
12 Comments
(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.
Did you enjoy this article? If so, subscribe to my RSS feed.
12 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. [...]
Add Your Comments To This Article Using The Form Below
Your comments may not appear until they have been approved by a moderator.