HTML Logo by World Wide Web Consortium ( Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS. ocPortal 9 is superseded by Composr 10.

Head over to for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.

Ensure at least grade-school security for a website

Ensure at least grade-school security for a website You might not be aware of this, but some cheap PHP web hosts are hackable by just about anybody with a few dollars spare.

Heck, it's easier to hack these web hosts than it is to hack a Sony website ;).

PHP needs special configuration in order to add security on a shared web server.

There are 3 different things a web host can do to make things secure:

  • They can make the server 'SuExec', which means that PHP scripts load up under the user of your own hosting account, and are constrained as such too. Believe it or not, by standard Apache servers work as a user called 'apache', shared between all hosting accounts. In other words, without SuExec any file written by PHP is shared between all hosting accounts. At ocProducts we believe all hosts should use SuExec, it is just such a basic intuitive thing to expect to happen. It's not just enough to enable SuExec though, you have to restrict access to the home directories for the different accounts so that read access is blocked between accounts (by default, read access is always there).
  • They can set an 'open_basedir', to restrict PHP to only operate within the directory of the hosting account. If this is done, it is important to lock down access for PHP to run external system commands (otherwise PHP could just call up another program on the server that does not apply PHP's open_basedir restriction).
  • They can set PHP 'Safe mode', which kind of overlays some access control on top of PHP. Safe mode is lame, it is a horrible workaround that causes some really weird problems and doesn't actually solve the security problem fully: the PHP team are rightly getting rid of it.
If you don't have one of these things set, anybody with an account on the server can mess with anybody else with an account. In other words, if someone wants to hack your site, they just need to sign up with the same web host (assuming they only have one server, and many unfortunately do), or they just need to find any one single site on the server that is hackable (it's easy to find sites on the same server, and people are often running stuff that is very easy to hack).

There's a simple way you can test the security without needing a full understanding of LAMP (Linux/Apache/MySQL/PHP) configurations. Here's a very simple script that you can upload (just save it as filesystem_browser.php):

if (!isset($_GET['dir'])) $_GET['dir']='.';
if (is_dir($_GET['dir']))
if (!$h) return;
while ($f=readdir($h))
† $found[]=$f;
foreach ($found as $f)
echo '<a href="?dir='.
† † $_GET['dir'].'/'.$f.'">'.$f.'</a><br />';
} else
echo file_get_contents(stripslashes($_GET['dir']));

Load up the script by URL, and see if it lets you browse up the filesystem and then into other hosting accounts.

The script just tests read access. Depending on the server configuration, you might have access to write any file in another user's directory that has been given '666' permission or was originally created by the web server itself. Even if you don't have write permission though, you can probe into the configuration file for the PHP software they have installed and find MySQL access details, and then you can easily install phpMyAdmin on your hosting account and give yourself full read/write access to their database.

It's scary stuff, you probably never imagined security for a website could be so poor, so please make sure you check your host is competent before putting too much faith in them.

I am not exposing any security holes in LAMP software here, but what I am exposing is how inept many web hosts are. Hosting is cheap, they often cannot afford to hire people who have a good understanding of security for a website, so be wary.

This was article 2 of 8 in my "Web industry Exposť" series of blog posts.

If you think it's good advice, please share this link with others. If you think I'm wrong or have something to say, please discuss below.

View all


There have been no trackbacks yet