When it comes to the security of WordPress plugins there are a lot of misconceptions out there (many times they are being repeated by security companies). One of them is that a more popular plugin is going to be more secure because it has been reviewed for security. Here is an example of this claim from a recent thread on Reddit:
it is important to note that there are many thousands of WordPress plugins available, and many of them have only been installed on a handful of websites. Lesser known or less popular plugins will often not have been reviewed for security, and may contain flaws.
For that reason, I recommend avoiding plugins or themes that don’t have several thousand installs (10k+ is a good rule of thumb) on security-conscious installs, unless you can have a developer inspect and vet the code for you.
As is true of so much security advice, there isn’t any evidence presented to back that claim up, which should be a red flag. In our compiling data on WordPress vulnerabilities for our service we haven’t seen evidence that there are many security reviews being done of WordPress plugins, so assuming that more popular plugins have had a security review is not a good idea.
Another way to look at is to see if there are easy to spot vulnerabilities in say a plugin 10,000+ active installations, which happen to have an example of from some checking we were doing related to our tool for doing limited automated security checks of WordPress plugins. One of the checks included in the tool is when user input is being directly output, which could lead to reflected cross-site scripting (XSS). That is something it would have detected in the plugin WP Customer Area up until we notified the developer of the issue and it was fixed.
Before we get the details its worth mentioning that this plugin has a couple of other attributes that get cited as being ones that should be used to decide if a plugin is secure, those being that it was recently updated (as of when we went to notify the developer) and with having positive reviews:
In three files the plugin contained the following line:
<input type="hidden" name="page" value="<?php echo $_REQUEST['page'] ?>"/>
Now there is little bit more to this vulnerability, which gets to why simply using an automated tool, like ours, isn’t enough to determine if there are vulnerabilities. In this case to get that code to run the value of the GET input “page” has to be set to a specific value, in the case of one of the files, /src/php/core-addons/admin-area/templates/private-post-list-page.template.php, it would have to be set to “wpca-list,content,cuar_private_fil”. So that couldn’t also be used for malicious code, but you can set the POST input to another value and it looks like normally the $_REQUEST variable would contain the value of the POST input instead of the GET input.
After we notified the developer of the issue, they released version 7.4.3, which fixes the vulnerability escaping the user input:
<input type="hidden" name="page" value="<?php echo esc_attr($_REQUEST['page']) ?>"/>
There Isn’t an Shortcut to Determining if a Plugin is Secure
With all the claims we have seen so far relate to determining if a plugin is secure, none of them have pointed to a way that you can truly determine if a plugin is secure without actually having a security review done. For example, even using a much more popular than one with 10,000+ active installations, isn’t going to mean that it is secure, as can be seen with another plugin with 300,000+ active installations we looked at recently that had five different vulnerabilities (and still has them, as they still haven’t been fixed).
Our aforementioned tool is able to detect some possible issues and we are continuing to expand what it can do, but it won’t catch a lot of issues, including any of those in 300,000+ active installation plugin at the moment.
If you want to get plugins you use checked over, that is something we offer. If you are paying customer of our service one of the things you get is the ability to suggest/vote for plugins from the Plugin Directory to receive a review from us and you can also order a security review separately from us.
Proof of Concept
The following proof of concept will cause any available cookies to be shown in alert box, when logged in as an Administrator. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.
Make sure to replace “[path to WordPress]” with the location of WordPress.
<html> <body> <form action="http://[path to WordPress]/wp-admin/admin.php?page=wpca-list%2Ccontent%2Ccuar_private_file" method="POST"> <input type="hidden" name="page" value='"><script>alert(document.cookie);</script>' /> <input type="submit" value="Submit" /> </form> </body>
- November 21, 2017 – Developer notified.
- November 21, 2017 – Developer responds.
- November 24, 2017 – Version 7.4.3 released, which fixes vulnerability.