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 Stats1 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:
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?
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.
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.
With a bit (a lot) of spare time over the holidays, I’ve done some housekeeping around here. Including updating plugins (more on that in a bit), deactivating plugins that I haven’t used in, well, years, and poking around in cPanel. I can’t tell if it’s just a Placebo or not, but it definitely feels a lot faster. Continue reading →