The Challenge With Securing Shared Hosting

The Challenge With Securing Shared Hosting

Posted by Stuart Herbert @ 9:04 AM, Wed 21 Nov 07

Filed under: The Web Platform

14 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.

Share This

14 Comments

Web Hosting » The Challenge With Securing Shared Hosting says:

November 21st, 2007 at 9:38 am

[...] You can read the rest of this blog post by going to the original source, here [...]

Mislav says:

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.

Nicolas Grekas says:

November 21st, 2007 at 8:31 pm

Personally, I use apache with mpm_itk and it works like a charm.

Stu says:

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.

Jonathan Street says:

November 23rd, 2007 at 6:01 pm

How can you keep us waiting?

It’s shaping up to be an interesting series.

Samir M. Nassar says:

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.

PHP’s Built-In Solutions For Shared Hosting | Stu On PHP says:

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 [...]

developercast.com » Stuart Herbert’s Blog: PHP’s Built-In Solutions For Shared Hosting says:

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 [...]

Using suexec To Secure A Shared Server | Stu On PHP says:

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. [...]

Using suphp To Secure A Shared Server | Stu On PHP says:

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. [...]

Using mpm-peruser To Secure A Shared Server | Stuart Herbert On PHP says:

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. [...]

Stuart Herbert On PHP - » Using mpm-itk To Secure A Shared Server says:

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. [...]

Centos 5 and mpm-itk | hostby.net says:

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 [...]

Zilvinas says:

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.