WordPress Security – The Big Picture and What You Need

I’m pretty passionate about WordPress, I’m pretty passionate about security, and I’m heavily involved in both. I’ve been working with WordPress for over ten years and helping build WordPress for over eight. I’m also on the WordPress core security team and have recently taken a lead role working on the iThemes Security plugin.

There has been a lot happening around WordPress security lately. Even the Federal Bureau of Investigation (FBI) has weighed in with a Public Service Announcement. An article by The Register covering that PSA was recently brought to my attention through Facebook, and honestly caused quite a stir.

First, the URL itself ends in “word_press_is_atrocious”. Ignoring the fact that WordPress is a single word, the word atrocious is never used in the article itself. It’s just a good, scarey URL. Even without using that word though, the article scared a lot of people. It ends with this gem:

WordPress hacking is a favourite pastime of lazy hackers and exploit kit -slingers who seek to achieve maximum carnage for minimum effort.

Is that really the case?

I think that the maximum carnage part is obvious. Numbers put WordPress at somewhere between 20 and 25 percent of the web, so if you want to be able to affect literally tens of millions of sites at once, you want to compromise WordPress.

Having said that, minimum effort is also accurate and explainable. Minimum effort because you only have to target a single system. Minimum effort because when you find an exploit, even one that’s already been patched, there are going to be sites out there that are vulnerable because people don’t upgrade. Minimum effort because you can stand on the shoulders of giants, since so many people are working to do exactly what you’re doing.

Sound scarey? It’s really not. Especially not for you! It’s tougher for the project as a whole…I’ll try to explain.

In the last couple years, the target on our back has grown because we’ve grown. But we’ve made a lot of progress toward being more secure. It goes FAR beyond patching a security hole. The biggest insecurities come from those that don’t update and from insecure plugins or themes. So we focused on those.

Now we have auto updates. When a new security release of WordPress is released (the y in x.x.y), WordPress updates to it automatically. Of course, some people complained about this, but ultimately (and statistically) WordPress sites on the whole are much more secure now.

We’ve also put some pretty serious systems in place for handling plugin vulnerabilities. We have plugins@wordpress.org and security@wordpress.org that can be E-Mailed if a problem is discovered. We have a plugin team that can review it, and if necessary remove it from the repo while a fix is worked on. When a fix is released, if it makes sense, we can even push the update automatically like we can with security releases of core.

We take this EXTREMELY seriously. We don’t want to update a plugin and break a site, so we don’t force everyone to the latest version. Instead we require a security patch be applied to each branch of the plugin and only update you to what you already had…but SECURE! BOOM! Isn’t that nice? I mean, people complain, but again: WordPress sites as a whole are more secure.

In the specific case sited in the Register article, they are talking about WP Super Cache. If we use their numbers, there are one million sites affected by this vulnerability. Remember, that’s out of over sixty million sites that run WordPress. And what do you need to be secure again? Simply update the plugin. A few clicks in your dashboard. Unfortunately, some people will put off the update, leaving their site vulnerable to attack rather than installing the update quickly and fixing the problem.

The good news is, we can push out patches to all one million sites in ONE DAY. All those sites will be secure again, even though it was a plugin that had the vulnerability.

So that’s the big picture, but I said it was easier for you, didn’t I? What can you do? There are lots of things, but let me list out the biggest ones for you so you can tick them off:

  1. Check your site daily and update things.
  2. Use strong passwords. This means getting something like 1password or Lastpass because you can’t have 50 character random passwords that are different for every site without having a way to manage those. In this same vein, usernames aren’t secret. Don’t worry about your username, just make sure your password is strong.
  3. Limiting login attempts is great. It’s NOT a replacement for a strong password, but it helps with brute force attacks. None of the recent big (meaning affecting lots of sites) vulnerabilities were from brute force attacks, but they still happen. If you have a strong password, brute force is more likely to take down your server than result in a compromised site. Obviously you still want to avoid this.

There’s obviously more you can do. Security is complex, nuanced, and tedious. But if you do those three things, you’ll be most of the way there.

Disclaimer: I work for iThemes now. We have products to help with these things, but I’m not pushing those specific products here because what’s important is that these things get done, not what tool you use to do them.

Header image credit smlp.co.uk, on Flickr

Adding your WordPress Plugin to GitHub

I’ve started putting my plugins on Github so it’s easier for developers to contribute. One of the big benefits of version control is the history, so I would hate to lose that on the move to git. The good news? I didn’t have to. The better news? It was actually easier than you might think. The instructions below are for GitHub but could easily be adapted to any git repo.

Start by setting up svn2git. You need to have git-svn, ruby, and rubygems istalled to use it:

sudo apt-get install git-core git-svn ruby rubygems

Then you can install the svn2git ruby gem:

sudo gem install svn2git

Now create your new repo on Github, but make sure to create an empty repo. Do not check the “Initialize this repository with a README” checkbox, and do not have it set up a .gitignore file or a license file. If the repo isn’t empty, the import process will not work.

GitHub New Repo

Now clone your new repo to your local system, and don’t worry about the warning that the repo is empty:

$ git clone git@github.com:{username}/{repository-name}.git
Cloning into '{repository-name}'...
warning: You appear to have cloned an empty repository.
Checking connectivity... done

Now you need to create an authors.txt file so that the users that committed to your plugin get proper credit in the Github repo. You can get the list of authors using this command, making sure to fill in the correct location of your WordPress.org plugin repository:

svn log --quiet  http://plugins.svn.wordpress.org/{your-plugin} | grep -E "r[0-9]+ \| .+ \|" | awk '{print $3}' | sort | uniq > ~/authors.txt

You’ll get a file that looks something like this:

aaroncampbell
plugin-master

If you see “plugin-master” in there, that’s the account that created your WordPress.org repo. I usually just credit that to myself. Now you need to modify that authors.txt file, setting a Github account for each username. You can set the github account E-Mail as well as the display name. The format should look like this:

aaroncampbell = Aaron D. Campbell <aaron@example.com>
plugin-master = Aaron D. Campbell <aaron@example.com>

Now that you’ve updated and saved the authors.txt file, you can use it in the next step. Start by changing to the directory you cloned the Github repo into. Now for the magic. There are two options, one is simpler and takes longer to run, one is faster and more complex. Read both and choose which makes sense for you:

The simple option is to run this svn2git command, making sure to fill in the correct location of your WordPress.org plugin repository and the authors.txt file you created:

svn2git http://plugins.svn.wordpress.org/{your-plugin} --authors ~/authors.txt --no-minimize-url

This command will take quite a while. The WordPress.org repository is quite large and it takes a long time to process that much history. The good news is, if you’re willing to take a couple extra steps, you can speed this process up a lot. We can do this by giving svn2git a subset of revisions to check. Start by running this command:

svn log --limit 1 -r 1:HEAD http://plugins.svn.wordpress.org/{your-plugin}

The item listed there should have a revision number like r41107, which was when your plugin was started. Run this command to similarly find the most recent revision for your plugin:

svn log --limit 1 -r HEAD:1 http://plugins.svn.wordpress.org/{your-plugin}

Now you can plug those into the command below, using just the numbers and dropping the leading r, and run the same magic but in a fraction of the time:

svn2git http://plugins.svn.wordpress.org/{your-plugin} --authors ~/authors.txt --no-minimize-url --revision {oldest-revision}:{newest-revision}

Once that runs, everything has been imported and committed, and all you need to do is push it to up to Github. Make sure to push the tags as well:

git push
git push --tags

That’s it! Your WordPress plugin, along with all it’s history, is now on Github.