Shared hosting. It’s the cheap option, isn’t it? And for a huge swathe of the population, it’s all they’ll ever need to host their website or web application. And when done well, shared hosting is scalable, fast and secure.
But what happens when it’s not done well?
Well, that’s when dangerous security issues start to creep in. That’s when your site is at risk of being defaced, or the private data you hold being leaked. But don’t fret. The vast majority of web hosts have decent security measures. It’s only the fly-by-night, bargain-basement hosts you have to be wary of.
We’re going to explore the security issues surrounding shared hosting. But first, let’s talk about what makes a shared hosting platform secure.
What Makes A Secure Web Host
There are a few standout security considerations that should be made with respect to shared hosting.
- Each user on the server should be isolated from other users, and should not be able to access or modify the files of other users.
- A security vulnerability in the logic of a website hosted on the server should not be able to impact other users.
- The server is regularly patched, updated and monitored to address architectural security issues.
- Each user should have their own isolated database access, and should not be permitted to make changes to the stored records or table permissions of other users.
Again, most web hosts meet these requirements for their shared offerings. But if you’re looking at hosting multiple websites on one server, or are curious to see how your hosting company stacks up, or even thinking of launching your own hosting company and are eager to work out how to secure your users, then please read on.
But First, A Disclaimer
Before we get into the meat of looking at common attacks leveled at shared hosting, I just want to state that this post will not be (and should not be read as) an exhaustive list of potential security issues.
Security is, in a word, big. There’s a lot of ways in which you can compromise a site. This goes double for shared hosting. Covering them in a single article was never on the cards.
If you are paranoid about your security, get a VPS or dedicated server. These are environments in which you have (for the most part) absolute control over what goes on. If you’re not sure about the different kinds of web hosting, check out this post from my colleague, James Bruce.
I should also stress that this post isn’t to be construed as an attack on shared hosting. Rather, it’s a purely academic look at the security issues surrounding this category of web hosting.
Let’s start off with directory traversal (often known as ‘path traversal) attacks. This kind of attack allows you to access files and directories that are stored outside of the web root.
In plain English? Well, let’s imagine that Alice and Bob use the same server to host their websites. Alice’s files are stored in /var/www/alice, whilst Bob’s documents can be found in /var/www/bob. Furthermore, let’s pretend that there’s another folder on the server (/usr/crappyhosting/myfolder) that holds an unencrypted plaintext file (we’ll call it pwd.txt) containing system usernames and passwords.
With me so far? Good. Now, let’s imagine Bob’s website serves PDF files that are generated locally, and the local file is referenced in the URL. Something like:
What would happen if I replaced the ‘report.pdf’ with the some UNIX parameters that change the directory?
If the server is configured incorrectly, this would then allow you to see Alice’s document root. Interesting, but, we’re far more interested in that juicy passports file. Accio passwords!
It really is as easy as that. But how do we deal with it? That’s easy.
Ever hear of a little-known Linux utility called chroot? You’ve probably already guessed what it does. It sets the Linux/UNIX root to an arbitrary folder, making it impossible for users to exit it. Effectively, it stops directory traversal attacks in their tracks.
It’s hard to tell whether your host has this in place without breaking the law. After all, to test it, you would be accessing systems and files that you have no permission to access. With that in mind, perhaps it would be sensible to speak to your web host and enquire about how they isolate their users from each other.
Are you operating your own shared hosting server and not using chroot to protect your users? Admittedly, chrooting your environments can be hard. Thankfully, there’s a wealth of plugins that make this easy. Take a look at mod_chroot, in particular.
Let’s get back to Alice and Bob. So, we know Bob’s web application has a few… Ahem… Security issues in it. One of these is the command injection vulnerability, which allows you to run arbitrary system commands.
Bob’s website allows you to run a whois query on another website which is then displayed in the browser. There’s a standard HTML input box which accepts a domain name, and then runs the whois system command. This command is executed by calling the system() PHP command.
What would happen if someone inputted the following value?
example.com && cd ../alice/ && rm index.html
Well, let’s break it down. Some of this might be familiar to you if you’ve read our ‘Getting Started Guide To Linux’ e-book, which we previously published in 2010, or have glanced over our Linux Command Line Cheat Sheet.
Firstly, it’ll run a whois query on example.com. Then it would change current working directory to Alice’s document root. Then it would remove the file called ‘index.html’ which is the index page to her website. That’s not good. No sir.
So, as system administrators, how do we mitigate against this? Well, going back to the previous example, we can always put every user in their own isolated, sanitized, chrooted environment.
We can also approach this from a language level. It is possible (although, this can break things) to globally remove function declarations from languages. That’s to say, it’s possible to remove functionality from the languages users have access to.
Looking at PHP in particular, you can remove functionality with Runkit – PHP’s official toolkit for modifying the functionality of the language. There’s a wealth of documentation out there. Read into it.
You can also modify PHP’s configuration file (php.ini) to disable functions that are often abused by hackers. To do that, open a terminal on your server and open your php.ini file in a text editor. I enjoy using VIM, but NANO is also acceptable.
Find the line which starts with disable_functions and add the function definitions you wish to ban. In this case, it would be exec, shell_exec and system, although it’s worth noting that there are other built-in functions that are exploitable by hackers.
Language And Interpreter Based Attacks
So, let’s look at PHP. This is the language that powers a startling number of websites. It also comes with a number of idiosyncrasies and weird behaviors. Like this.
PHP is usually used in conjunction with the Apache web server. For the most part, it’s impossible to load multiple versions of the language with this configuration.
Why is this a problem? Well, let’s imagine Bob’s web application was originally built in 2002. That’s a long time ago. That’s back when Michelle Branch was still topping the charts, Michael Jordan was still playing for the Washington Wizards and PHP was a much different language.
But Bob’s website still works! It uses a whole bunch of discontinued and deprecated PHP functions, but it works! Using a modern version of PHP would effectively break Bob’s website, and why should Bob rewrite his website to cater to the whims of his web host?
This should give you an idea of the dilemma some web hosts face. They’ve got to balance keeping an architecturally sound and secure service, whilst keeping that in harmony with ensuring the paying customers are happy.
As a result, it’s not uncommon to see smaller, independent hosts use older versions of the PHP (or any language, for that matter) interpreter.
It’s not uncommon to see smaller, independent hosts use older versions of PHP, potentially exposing users to security risks.
Why is this a bad thing? Well, firstly, it would expose users to a number of security risks. Like most major software packages, PHP is constantly being updated to address the plethora of security vulnerabilities that are constantly being discovered (and disclosed).
Furthermore, it means that users can’t use the latest (and greatest) language functions. It also means that functions that have been deprecated for a reason remain. In the case of the PHP programming language, this includes the laughably terrible (and recently deprecated) mysql_ functions that are used to interact with the MySQL Relational Database System, and dl(), which allows users to import their own language extensions.
As a user, you should be able to see what version of an interpreter is running on your service. If it’s outdated, or containing a number of security vulnerabilities, contact your host.
What about sysadmins? You’ve got a few options here. The first (and most promising) is to use Docker for each of your users. Docker allows you to run multiple, isolated environments concurrently, much like a virtual machine does, albeit without having to run another operating system. As a result, this is fast. Really, really fast.
In plain English? You can run the latest and greatest bleeding edge interpreter for the majority of your users, whilst the customers who are using old applications which use ancient, deprecated interpreters to do so without compromising other users.
This also has the advantage of being language agnostic. PHP, Python, Ruby. Whatever. It’s all the same.
Don’t Have Nightmares.
This post was intended to do a couple of things. Firstly, it was to bring to your attention the number of security issues that web hosting companies have to face in order to ensure the security of their customers and their data.
It was also intended to show you how sites hosted on the same server can affect each other. Want to put a dent in this? Start obeying good, secure coding standards. In particular, start sanitizing your inputs on both the front-end and in the back-end.
A good start is with the new HTML5 form validation functionality. We’ve talked about this before in our HTML5 guide. Collectively, we can make websites more secure by being better, more conscientious programmers.
As always, I’m up for hearing your thoughts. Drop me a comment below.
Photo Credit: Everybody Needs A Hacker (Alexandre Dulaunoy), Sticker On Taxi Window (Cory Doctorow), Server room (Torkild Retvedt), Linux Books And Magazines (library_mistress), PHP Elephant (Markus Tacker)