If you've subscribed to the Secunia's newsletter, you've surely noticed that the overwhelming majority of WordPress vulnerabilities mainly affect plugins. Most of the plugins hosted on the WordPress repository are unreliable and potentially dangerous because they're seldom or never updated. An obsolete plugin is a potential security hole and you should never trust WordPress plugins even if they work as intended. In this article I'll try to answer a simple question: what are the signs of an insecure WordPress plugin?
Update frequency
An insecure plugin is surely a plugin that is never or seldom updated. A good update frequency is about every two or three months or even less. A plugin's author should programmatically review his code to fix every possible security flaw. This implies the correct implementation of all the best practices recommended either by the WordPress community or security experts.
Also, a plugin's author should be constantly up-to-date with the most recent vulnerabilities and exploits in order to prevent attackers from hacking into his code.
If you notice that the update frequency of a plugin is too low, you should entirely remove that plugin from your website.
HTTP request handling
When handling HTTP requests (GET and POST), a plugin's author should assume that every request is potentially tainted and should always filter, escape and sanitize data before using it in WordPress.
In order to prevent the malicious case of unexpected input, authors should never rely only on the internal processing made by WordPress but be ready for the worst-case scenario.
A plugin that doesn't take into account all these considerations is potentially vulnerable to many kinds of attacks and should never be used on your websites.
File handling
WordPress already provides a way for handling file uploads in the form of the Media Library. Media Library is a misleading name: the WordPress utility can handle any kind of files, including PDF files, text files and so on.
Plugins should use the Media Library to handle files. Using a custom upload system is potentially dangerous, because it exposes your website to many other attempts of remote file inclusions.
A plugin that creates its own directory system within your WordPress installation adds an extra level of complexity, thus increasing the level of danger for your website. Such plugins should never be used.
SQL queries
SQL queries executed against a WordPress database should be used sparingly and only when it's absolutely necessary. If there's a WordPress function that performs the same task, then this function should be used instead of a custom query.
Queries should be always prepared before executing them. Further, the same principles of filtering, sanitizing and escaping mentioned earlier also apply here, especially when a plugin deals with user's input.
Includes
If a plugin makes use of the PHP's include function, it should always make sure that the included file cannot be included outside
the plugin's code, e.g. with a direct inclusion.
A common pratice is to define a global constant and then check if this constant is defined within the included file. If the constant is defined, it's very likely that we're handling a legitimate inclusion, otherwise the inclusion should be rejected.
if( !defined( 'MY_PLUGIN_CONST' ) ) {
exit();
}
Further readings
Web Application Security Guide
This guide attempts to provide a comprehensive overview of web application security. Common web application security issues and methods how to prevent them are explained. Web server and operating system security are not covered. The guide is intended mainly for web application developers, but can also provide useful information for web application reviewers.
The checklist gives a short summary containing only the individual guidelines. It is recommended to take the time and read the full version, where the guidelines are explained in detail, especially if any questions arise. Most web application developers probably (hopefully) already know some or even most of the points mentioned in this guide.
However, there will probably be something new for every developer. Remember, as a developer it is your responsibility to develop your application securely, and a single mistake may be enough to allow an attack.
