robinadr

Tagged security

If you haven’t signed up for a VPN service yet, you need to. I’ve been a customer of Private Internet Access for more than a year now, and the annual $40 has been more than worth it.

Here’s a quick list of what I’ve used it for:

  • Tunneling torrents through it
  • Connecting to IRC networks that don’t use SASL and/or mask your IP
  • Watching Netflix outside the US1
  • Connecting securely to public wifi

Especially that last one. Every time you sit down at a Starbucks, a public library, or anywhere with a publicly available wireless network, there could be someone listening in on your wireless transmissions. It doesn’t require much knowhow to pull off either.

Note this matters even more when you log in to websites that aren’t using a secure connection (http://). Your credentials transmit in plain text. That should scare you.

So get a VPN account, set it up, and start browsing securely.


  1. This goes both ways: sometimes you want access to the US catalog from outside the country, and sometimes you want access to another country’s catalog (e.g. Canada’s) from inside the country. 

Thanks to the free [Namecheap]( http://www.namecheap.com/?aff=75412)[^1] SSL certificate included with the GitHub Student Developer Pack, I’ve moved my site over to HTTPS permanently.

After dealing with infinite redirect loops for almost an hour, it turns out on NearlyFreeSpeech you need this extra block of code in your wp-config.php:

if ( $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' )
    $_SERVER['HTTPS'] = 'on';

Beyond that, it’s simply a matter of setting your WordPress URLs to the https version. I also have the following in my .htaccess file:

Header set Strict-Transport-Security "max-age=10886400; includeSubDomains" "expr=%{req_novary:X-Forwarded-Proto}=='https'"

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301]

The first line sets an HTTP Strict Transport Security header that tells the browser to always use https for the specified time (10886400 seconds is 18 weeks). The next two lines permanently redirect any insecure URL to the https version.


Feature creep, creeping featurism or featuritis is the ongoing expansion or addition of new features in a product, such as in computer software. Extra features go beyond the basic function of the product and so can result in over-complication rather than simple design.

Feature creep on Wikipedia

Automattic recently acquired the BruteProtect plugin, and announced that they would make the premium service free but plan to roll it into the Jetpack “meta-plugin.” For me, this highlights a trend I dislike, starting with the WP.com Stats2 plugin back in the day.

I get the appeal of doing this: it bundles these plugins in a “meta-plugin” that dumps the extra features WordPress.com users have access to onto your self-hosted blog, in one shot. However, I dislike this approach for two reasons:

  1. It introduces bloat. I can count on one hand the number of Jetpack modules I’m using. Not to say the rest aren’t useful; I just don’t have a need for them.

    It’s unnecessary to have to install a huge meta-package when all I really wanted in the beginning was to keep using the stats plugin. Maybe Jetpack modules could be downloaded only as needed?

  2. WordPress comes with a great plugin finder built into the admin (Plugins – Add Plugins), and the plugin repository is an immensely useful resource for finding what you want.

    Jetpack is a package manager within a package manager. Using what has already been built, Jetpack could be a “guide” plugin to discover those other plugins.

Either way, I highly recommend installing BruteProtect. Attacks on wp-login.php URLs have become so prevalent my web host even monitors for this specifically, and locks access automatically.


  1. This is the link on the list of Automattic plugins, but it appears the plugin is no longer listed there. 

Slashdot just linked to an article citing a study about widespread vulnerabilities in a lot of popular WordPress plugins. I’m not going to link to the study itself because it seems to partially for selling the company’s services; however, the point still stands: a lot of WordPress plugins are written without security in mind. This only gets worse when code is abandoned but still running on production sites.

WordPress has generally gotten a tough rap when it comes to security (which hasn’t been without merit in the past). That being said, the team that works the WordPress core itself have really stepped it up in the past few big releases, likely because of the implications of running the code on WordPress.com. I have faith in the security of the core, but when it comes to plugins it’s a complete crapshoot. How can you try to deal with this?

Stay updated. Sure, it can be annoying. But it’s worth it. Since WordPress launched the plugin repository, updates show up right in the admin, so there’s no reason not to update. Also, if a plugin seems abandoned, you should abandon it too.

Get rid of the cruft. If you’re not using a plugin, deactivate it. Better yet, delete it. Consider every plugin you install a risk, and minimize these risks.

Install the popular options. I’m hesitant to suggest this, because popularity absolutely does not imply good code. However, when more people use a plugin, it isn’t crazy to think there is a better chance of a security hole being found and subsequently plugged. Do not use this as a rule, but more as something to keep in mind.

The WordPress Codex (documentation site) also has some tips for “hardening” your WordPress installation.

If you don’t want to deal with it, don’t host it. WordPress.com offers a great service you can even use your domain with, and they can do all the work of maintaining the back-end. Gone are the days where the only way to run WordPress is to host it yourself.

A Real Solution

If you think about these points, they really only involve minimizing your risk with band-aid solutions. They only cover up the real problem: there is no auditing or accountability when it comes to WordPress plugins. Plugin authors don’t have any incentive to patch their free plugins, other than goodwill.

The article also brings up another interesting point:

“First of all, Web admins think that if they are downloading these plug-ins from a reputable source, then there is an assumption that they are receiving a secure plug-in,” said Maty Siman, CTO of Checkmarx, in an interview. “In our opinion, that is the biggest factor.”

While there is no mention of any security process on the official plugin repository, this statement does have some truth in it. Downloading plugins from the official source for plugins gives a sense of confidence to an everyday user. WordPress is very easy to set up and use these days, and a lot of people won’t have the knowledge to know otherwise.

Any kind of real solution will require code auditing and regular checks of website, all of which is a lot of work. Perhaps it might be time to do what Apple does with their App Store, at least with regards to security. Audit the most popular plugins on the repository, and make it very clear that they are secure and will get patched promptly in the event a vulnerability is found.

However, this takes a lot of manpower (or womanpower), and is a tedious, time-intensive process. It’s hard to find people and pay them to get this done in the context of an open source project with open source plugins.

WordPress 2.2.1 has been released, which includes many fixes for bugs that sprung up, and most importantly of all, fixes a few rather major security holes:

As always, it’s recommended you download it now.