Why You Need To Upgrade WordPress Now (and Back It Up While You’re At It)

Last week, there was a big announcement in the WordPress world about a security vulnerability existing within many plugins.  Plugin authors scrambled to fix the issues quickly while the call went out for everyone to update their plugins and Word Press installations.  As a web developer, I understood what the vulnerability was all about, why it could be so dangerous, and what an attacker could use it to do.  As I thought about it, though, I realized that non-web developers might need a quick primer on just what the problem was.

The Problem

Word Press can be a wonderful tool for developers.  Not only is it a Content Management System, but it has a series of functions available to programmers to use in the course of writing code.  You don’t have to re-invent the wheel because Word Press has built in functions that can be used to complete the job.  A long time ago, there might have been security concerns with WordPress’s functions.  Thankfully, though, the WordPress team has put a lot of effort into security.  Unfortunately, the documentation for a couple of the functions were vague.  Developers thought that two of the functions were sanitizing the user’s input when they weren’t.

Clean That Input

What does sanitizing input mean?  It means that a developer should never trust what a user enters into a system.  If a user is prompted to enter a number between 1 and 10, it shouldn’t be assumed that they didn’t type 11.  Or abc.  Or ‘ and 1=1; Delete From Users.  If the wrong user input is blindly accepted, the program might give bad results, crash, or – even worse – allow a malicious user to run commands that could compromise the security of the server, its data, and subsequent users.  Luckily, before user input is used, it can be checked and potentially harmful contents can be neutralized.  In the case of the WordPress vulnerability, the lack of cleaning up user input meant that a Cross-Site Scripting (XSS) attack could be formed.

What is XSS?

Cross Site Scripting (or XSS) happens when malicious user input placed on a website and is used to run scripts on a user’s computer.  Suppose, a blog had a comment page that had a XSS vulnerability.  An attacker could craft a link in the form of

http://www.someblog.com/comment.php?Username=<script>document.cookie = "expires: Wed, 1 Apr 2015 12:00:00 UTC; path=/";</script>

This particular link would erase the person’s cookies – effectively logging the person out of the website.  Annoying, but ultimately harmful.  However, a more advanced form of this attack might read information stored in the cookie variables (e.g. usernames, passwords) and send them to the attacker (perhaps by using JavaScript to load an image with the data to send in the image’s link).  If the attacker sent this more advanced link to a user, he could take control of that user’s account.

Now, imagine a comment form.  The basic comment form is quite simple.  Just take the user’s comment and display it on the website.  Not hard, right?  If I input:

Very nice article.  I agree wholeheartedly.

then that should appear on the page.  What, however, should happen if I write:

Very nice article.  I agree wholeheartedly.  <form action=”http://www.somewebsite.com/”>Credit Card Number: <input type=”text” name=”CCNumber” /><input type=”submit” /></form>

Should that appear on the page as is?  In case you don’t “speak HTML”, that comment – if left unfiltered – would make a form appear on the page asking for a user’s credit card number. This phony form won’t fool anyone, of course, but a more advanced version of this could wipe out all elements on a page and display a real looking login page – with the usernames/passwords being sent to the attacker (and logging the users in if the attacker wanted to be extra sneaky).  The form could also ask for a user’s personal information or payment information – compromising the user’s credit card number or other details.

In all of these cases, the attacker uses not only the XSS vulnerability, but the trustworthiness of the website being used to fool users.  If your users usually pay for access to your website, they might not think anything is wrong when your website suddenly reports that it needs to confirm the users’ credit card numbers.

How Do I Stop XSS?

Stopping Cross-Site Scripting attacks is actually very simple.  I even had to resort to it while writing this article.  My blog post editor kept wanting to turn some of the HTML tags into actual HTML.  To keep it from doing this, I replaced all “<” angle brackets with &lt; (the HTML code for “<“) and all “>” angle brackets with &gt (the HTML code for “>”).  Doing this to user input should make the attacker’s HTML code show instead of being interpreted and run.  Of course, to do this, you need to know how to work with the code behind websites.

But What About WordPress Plugins?

When you use WordPress plugins, you need to have some level of trust as to the quality of the code.  Few users have the time (or the skill) to pour over all of the code in all of their plugins to spot all of the vulnerabilities.  The best most users can hope for is that the developers (or users with the time and skill) find the bugs and fix them.  This fixes will be posted as updated versions.  This is why it is essential to keep WordPress, its plugins, and its themes up to date.  It doesn’t matter if the vulnerability in Really Cool Plugin was fixed in version 1.3 if you’re still running version 1.2.  And don’t think you can hide behind people not knowing what version you are running.  Hackers can use automated tools to scan many sites for many different vulnerabilities – only giving their attention to the openings that they want to exploit.

How do you update?

To update your WordPress installation, log into your WordPress installation’s admin panel (usually http://www.yoursite.com/wp-admin/).  Under Dashboard on the left hand side is a menu option called “Updates.”  Clicking this leads you to a page where you can update the WordPress core installation, plugins, and themes.  (In the case of the latter, bad coding can lead to security holes within themes which might be patched with a new version of the theme.)

What about plugins with no updates?

Not every plugin author updates his plugins on a timely fashion.  Whether because he is busy on other projects or because the plugin you are using isn’t being actively developed anymore, you might still find yourself running vulnerable plugins.  Worse still, you might not know it until the plugin is exploited.  There are security plugins that can be used to mitigate the risk, but in the end one of the best defenses is a good backup.  Make sure that you have backups of your website files as well as your database.  With luck, you’ll never need them, but if you do you will be glad that you had them.

Techydad Backup & Update Service.

There are many WordPress plugins that one can use to backup ones WordPress sites.  If anyone needs any assistance, I’d like to extend an offer, though.  I’ll backup your website and database once a week as well as run monthly updates on your site for a monthly fee.  If you are interested, contact me and we can discuss pricing.

Stay safe online and happy blogging, everyone!