In December 2008, Ian gave a talk covering the basics of WordPress Security for the Tucson Digital Arts Group (TDAC).

Download a PDF of the talk

This is a rough summary of the talk:

WordPress Security

Anything on the web is vulnerable, but sites that run applications like wordpress are more powerful, and that leads to vulnerability. Moreover, any time you use well-known software you’re likely to be the target of programmatic attacks, i.e. robots, etc. It’s a tradeoff, but one that tends to be worth it. There are known vulnerabilities for every system out there, WordPress, Drupal, Joomla, etc. One can argue about which are more or less secure, but in practice it’s unlikely to make much of a difference if the system you’re using has 5 or 15 vulnerabilities in any given month. Besides, everyone here has already sat through two hours of WordPress presentations, so I’ll assume that you’re going to use WordPress and want to know what you can do to secure it.

So what is the threat? First of all, let me say that I’ve launched 50s of websites with WordPress, and only three or four that were compromised. In most case the compromises involved link injections — my clients’ sites were dumping tons of links to viagra and cialis vendors in hidden blocks on every page (what’s interesting is that you could only see the links if the hacked code thought your were google — you could manually check the site and never see the issue). This made the sites load really slowly, but more importantly, they were knocked out of the google rankings because of the anti-spam measures that google takes. So it does have an impact. Theoretically a targeted attack could also simply delete all your content or maliciously deface your site, but I’ve never actually seen that happen.

There are lots of things that can be done to make sure your sites don’t get compromised. Some are things you have to do repeatedly, like upgrading software, and some are just little things you can do to make your site not exactly like every other WordPress site, and therefore not likely to be cracked by bots. Here are just a few:

Stay up to date! This is the easiest and most obvious, but it bears repeating. In every case of compromise that I’ve seen, it has been sites with versions several months out of date, often six months or more. Now with version 2.7 the auto-update feature should help quite a bit, making it possible for your clients to update their sites without your help, but it’s pretty new and I’m holding my breath to see if this causes more problems than it solves. The WordPress dev team has been really good about responding quickly to vulnerabilities, and the dashboard will notify you or your client when new versions are released. I always address security updates with potential clients before even beginning work to ensure that there’s an understanding.

Plugins can also be vulnerable to compromises, though I haven’t seen this personally. They’re their own bodies of code, and can have serious flaws as well. They should be updated as often as possible, and as with the core updates, this has been automated as well. If you’re writing your own plugins, of course, try to adhere to good coding practices and to good WP standards (addressed earlier) and you should be set.

Use htaccess files. Apache has its own security scheme that allows you to limit access to wp-admin by user/pass (popup), by IP number, or a variety of other means. This eliminates a host of security issues all by itself, though it does force you to enter passwords twice in some instances.

This is obvious, but use real passwords! If you give your admin account a password like “password” you’re asking for trouble. This goes for all passwords for any system. Password guessing bots are really, really good — much better than you realize.

Turn off comments and features if you don’t need them. If you don’t intend to use comments on your site, turn off the functionality in WordPress. Or if you’re only using the system as a CMS, turn off the ability for users to register. No reason to expose yourself if you don’t need to.

This is a minor one, but arguably helpful one: rename your master admin user account to something else. You have to do this through the database, but it’s an easy and quick one, and a pretty good idea if you’re worried about automated guessing routines. Or if you don’t trust your clients not to use common words as passwords.

Some people recommend putting your WP files in an folder below the root level, so that scripts looking for

http://www.yoursite.com/wp-admin/something.php

won’t find what they’re looking for; the files would actually be in another location like

http://www.yoursite.com/cms/wp-admin/something.php

Again, this protects you from bots more than an individual.

Testing scripts: Set up testing scripts! As you discover ways your site can be compromised, you can enhance testing scripts to scan all your sites. For instance, when I discovered that a client’s site had been stuff with cialis links, I set up a script that would pretend to be google and go to every wordpress site I had created looking for cialis in the html. I found 2 other sites that had been compromised without anyone knowing it.

Assume that you will be compromised at some point, and do good backups. We have special routines we use to complement the ISP backups that backup all the files and the database for all our sites on a weekly basis, and then keeps them around for 90 days. This way we almost always have clean backups whether the site is compromised or the client breaks it.

Stay informed.  Subscribe to
http://wordpress.org/development/
and to
http://blogsecurity.net/wordpress/wordpress/
I’m sure there are others, but these are the ones I know about.

There are a lot of good security plugins out there.  I like the wp-security plugin.
http://wordpress.org/extend/plugins/wp-security-scan/
It’s not a great plugin, but it helps you remember to do a number of things that are useful. It also prevents WP from dumping the version number in the header, which is nice.

You can find a bunch here:
http://wordpress.org/extend/plugins/tags/security
AskApache Password Protect — helps you with the htaccess methods mentioned earlier.

Anybody else?