robinadr

Posted in June, 2013

From the talk page for Yeezus on Wikipedia, about how a song is credited as (featuring God):

And what source, other than Kanye himself, indicates “God” is featured on the album? That would indicate there is proof that “God” exists, which is a debate that shouldn’t even exist here. Why is “featuring God” allowed? — Erroneuz1 (talk) 00:19, 19 June 2013 (UTC)

That’s how it is on every store, digital and physical, so that’s how it’ll stay. Distortiondude (talk) 01:51, 19 June 2013 (UTC)

Still not seeing how that makes it acceptable to list an entity which may or may not exist, and as such, is not a provable contributor to the track. — Erroneuz1 (talk) 04:16, 19 June 2013 (UTC)

That’s not even all of it. Wikipedia bureaucracy is such a clown car full of fuckery that takes itself way too seriously.

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.