I recently read this comment. What the commenter said is that a WordPress plugin can pose a security risk for your site. That is entirely true. You must remember my post about minimizing plugin use and doing whatever can be done by hand. That is one of the reasons. But how can this happen? Well, a WordPress plugin, as any piece of code, can be vulnerable to various kinds of attacks, if poorly written. Actually, even if taken well cared for, they can still have holes that the coder did not notice. That’s because he is a human after all. But how severe can this security risks be?

That is a difficult question and my first answer is that it depends on the piece of code that has the problem. The most common problems found in a website’s code can be divided in two main categories:

1. Code, that when exploited, can harm the database of the website system.
2. Code, that when exploited, can harm the filesystem that runs the website.

Here is a brief explanation on both of them. The database, as you all must know by now, is actually a place that all the dynamic information of the website is stored. The Content Management System (CMS) (WordPress at this point) queries the database and inserts or retrieves information. For instance, when you create a post and you save it, the CMS inserts all the text, title, tags etc on the database for storage. When a visitor hits your post’s page, the database is queried returning all this information to the CMS which renders it and sends it back to the browser. You can think of the database as a warehouse of information. This is what it roughly is. So, imagine a poorly written code segment, that would allow an exploiter to have full access to that warehouse. This happens when the code that will run a query get’s a user’s parameter and inserts it in the query without making sure it’s not malicious. An attacker can then form a specially formatted input that will insert his code allowing it to be executed by our plugin.

The image above illustrates the procedure of, what is called, an SQL Injection within the limits of WordPress. So, as you can see, the exploiter can malform a URL to pass what we call “malicious” GET variables. Then, the input is not properly “sanitized”. What does this mean? For instance, if  for an input variable, we expect it to be a number, then we should make a check to see if it really is. Poorly sanitized strings are passed, without checking, from our plugin to the WordPress database wrapper that actually executes the query on the database. What can that exploit be? Here are my worst case scenarios:

1. Malicious attacker trying to bring down your site, actually all he has to do is issue a query that will drop all the tables on the database! (ops! hope you have a back up!)
2. Sneaky attacker that can issue a query to find your administrator password or other information about you.
3. Another, not so common attack, can be performed from a spammer that can form a query to get all the email of your subscribed users or members!

There are many other things they can do, this is what i came up with.

Let’s move on to the filesystem harmfoul attacks. These kind of attacks can be disasterous for the server your site is running on, if not configured properly. They are called “remote file inclusion” and “remote file execution”. Their names are not pretty and nor are their effects. Roughly, what they do, is they give the opportunity to the attacker, through a maliciously formed URL once more, to execute commands on the server the site is running on. The results can vary from file deletion to password or configuration spoofing. You can find more on techniques attackers use to exploit both holes on this article i wrote back in April.

But how can a blogger protect himself? First of all, minimize your plugin needs! I know it sounds hard sometimes but, seriously, less plugins equals less danger and server load. Secondly, when you find a plugin you want to use start a small google “investigation”. See what others have to say or even better, write the plugin’s name along with the word “exploit”. For instance, before using my YAFootnotes plugin, you can google “YAFootnotes exploit”. If there is something out there, chances are you will find it this way. Finally, if you have some code knowledge, head over to the queries that the plugin issues and see if there is any input that is not sanitized.

To be honest, in the days of my WordPress experience, i haven’t found any plugin that poses a security risk. That doesn’t mean there are no such plugins out there. They are just not popular. My suggestion is, use as less plugins as possible and make a small research on them before installing. Also, keeping a full blog backup (files + database), is a practice of “being on the safe side”.

So, did you have any bad experience? Is there some help you need that i could provide?