Posted on December 7, 2007 at 9:03 am | 
By 
A recent hack of our blog made me realise that blogs based on older versions of WordPress are at great security risk. I said “older version”, because the company’s developers are making security fixes as soon as they’re found. WordPress Trac is where bugs are reported and tracked.
By releasing immediate security fixes they honour their end of the deal, but do we by upgrading our WordPress accordingly? I have to say, the majority of us don’t. Apart from upgrading WordPress, there are other server related issues which may look simple, but can be your saviour or doorway to destruction.
Exploits are inevitable; you will come across them every now and then. Exploits are an unavoidable by-product of major projects; they are part of the bargain: you fix them and move on. Here is what can be done to stay safe
- Subscribe to WordPress development blog . That should keep you alert of the latest security patches and versions. Don’t just read it act on it too. So, upgrade accordingly. Upgrading might force you to take down your blog/site temporarily for few hours, but it’s still better than your server being brought down for forever, right?
- Not only do you have to upgrade WordPress, keep an eye on your plugins. I had experienced persistent XSS Vulnerability (Plugin responsible-wp-feedstats 2.4) and SQL Injection Vulnerability (Plugin responsible- WP-Stats 2.01), fortunately these were taken care of.
- Stop anonymous comments and trackbacks, why? There’s history of WordPress Trackback Charset SQL Injection Issue and other Non-WP related spam flood.
- Check your server files and folder permission accordingly. Especially Config.php file, which is an open text based file in a Web accessible directory. Not only is it Web accessible, but it contains the login and password for your blog’s database. No need to be a rocket scientist to figure out what will happen if someone naughty can get access to that.
- Directories should have permissions of 755. NEVER 777. All files should have permissions of 644. If you do want to use the built-in editor; theme files should have permissions of 666. NEVER 777. Do not use any plugin that needs to write anything to the server. No matter how drastic it sounds, trust me it will save your ass.
- Last but not the least, if you are building your own theme/or asked someone to do that for you, please do try to consult/check for latest PHP security holes or common security flaws before using that as template.
All of the above do’s and don’ts are common sense, but unfortunately we get lazy and tend to ignore most of them. Learn from my mistakes.
4 Comments
So far,
December 10, 2007 @ 
Mike
Also if you can:
- Have your webserver and database running in a chroot / jail. Then even if someone gets into your server they face a significant barrier to doing more damage.
- The ownership of files on the webserver and the process the webserver runs on should be different. Also makes its harder for a hacker to do more damage even if they do break in.