Most small websites on the ‘net sit on shared hosting of some kind or another  ((this is an educated guess)).  Shared hosting means that a small number of servers handle all the requests for a large number of web sites.  How that’s achieved varies, but the bottom line is that it’s a shared infrastructure.  It’s a bit like living in shared accommodation.  There’s a single door through which everyone gets into the building, then a number of apartments which have their own doors.  But they all share the same electricity supply and water and other utilities.

With shared web hosting, all the traffic comes into the same web host network and web server cluster, and is then handled by all the different web site configurations.  In the same way that there are people who would like to break into your apartment, there are people who’d like to break into your web site to steal stuff, deface it, or to try and gain further access to the shared infrastructure.

No matter how small your website is, someone, somewhere will try and break into it.  If your site is a collection of plain flat HTML files, then you’re fine, there’s not much they can do.  However, if you’re running any kind of code (PHP, Perl, etc.) then there’s an increased risk.  People will try and find a way to exploit the code, gain access to passwords or elevated privileges and get access to whatever it was they wanted in the first place.

All of my sites have been attacked in one form or another ((I have around 10 sites, from silly little plain HTML ones to WordPress blogs and phpbb forums for various things)).  If your site is on shared hosting, and attackers gain access, there’s an increased risk that other sites will be disrupted, that’s on top of your site being used to host attacks on other targets.  So it is essential that we all secure our sites as well as we can.

I was thinking about this recently from two angles.  Firstly, I had a few WordPress plugins that I wasn’t using but had not disabled and removed.  My thought at the time was ‘I may use them later and they’re not doing any harm’.   Then I was looking through the access logs for this site and noticed two attacks.  Someone used the search form to try an sql injection attack, and secondly someone else had tried to access URLs linked to four or five WordPress plugins I don’t have ((Spreadsheet plugin and ST newsletter plugin for example)), each of which was also an sql injection.  In both cases they’d tried to get the admin password for the site.  I’m not sure what they could have done with that other than blog about what they eat (like me) but it’s certainly not something I want people having.

The second type of attack really brought into focus for me that you have to maintain your website.  You have to keep it patched, and you have to disable and remove any features you’re not using because you never know if those things have exploitable code in them.  So I wrote myself a little list of things to keep in mind for all my sites,

1. Keep them patched, always, even if their use is starting to fade, if you can’t patch them, delete them.  If you can, sign up to your product’s security mailing list.
2. Keep plugins, modules, extensions, add-ons down to an absolute minimum and only keep them installed if you actually use them, you never know when someone will find an exploit in the obscure plugin you stopped using 3 months ago
3. Check your access logs for any weird requests (always check for queries which return 404’s, and check for stuff which passes any kind of parameter), you might just spot an attack vector that reveals something you forgot to check
4. Don’t assume you’re too small to be a target, it’s cheap to attack hundreds of thousands of sites and the more you attack the more chance you’ll find a hole, your site will be a target
5. Avoid moribund plugins, tools, and applications.  If your choice of application is current, well used and receiving regular updates then you would hope that any holes are found and fixed early, if no one has looked at the code in half a year and there were any issues, then you’re sitting on a time bomb
6. There’s a trade-off between choosing a well known application (like WordPress) which puts you into a pool of targets because people work harder to attack code with a big install base, and choosing a less well known, less well tested piece of software which might not be as obvious an attack target.  Personally, I choose well known, active applications, because I believe the development community is keen to protect them