Checkmarx, a company founded in 2006 that specializes in automated security code reviews has published a security vulnerability report on the top 50 plugins on the WordPress plugin repository. In the report published on June 18th, 2013 Checkmarx concluded that more than 20% of the 50 most popular WordPress plugins were vulnerable to common web attacks such as SQL injection. Furthermore, the report revealed that 7 out of the 10 most popular e-commerce plugins for WordPress contained vulnerabilities. First, some background information regarding how the report was put together.
The research in this survey has nothing to do with the core security of WordPress but rather, the plugins available for it. It’s important to consider this distinction when reviewing the report. An automated static code analysis developed by Checkmarx was used to scan the source code against the most popular plugins. These included the 50 most downloaded plugins as well as the 10 most popular e-commerce plugins. The scans occurred on two separate occasions. The first was during January 2013 while the second took place in early June of 2013.
During the first scan, Checkmarx discovered 18 vulnerabilities and notified the developers of four of the vulnerable plugins, then worked with them to apply fixes. After 6 months, the WordPress plugin repository indicated that all 18 plugins had updated versions. The scan was used on these updated versions to see if the vulnerabilities had been fixed. Their automated tool was set to notify when one of the following vulnerabilities was discovered:
- SQL Injection (SQLi). Allows the execution of commands on the back-end server, such as the extraction of sensitive information. In a hosted environment, a SQL Injection attack can further be used as a stepping stone for attacks against non-vulnerable sites. The attacker in this environment can manipulate the database shared by both vulnerable and non-vulnerable sites.
- Cross Site Scripting (XSS). Allows the running of a script on the client in order to bypass access controls. This kind of vulnerability targets all visitors to the site. In a hosted environment, this problem is exacerbated where an attack can also be used to steal the session cookies of the site admin. Effectively, it allows the attacker to imposter the admin.
- Cross Site Request Forgery (CSRF). Allows the attacker to perform an application-level transaction on behalf of the victim. In a hosted environment, an attacker can log onto the site on the admin’s behalf and perform nefarious activities such as re-directing users or performing admin transactions.
- Remote/ Local File Inclusion (RFI/ LFI). Allows the uploading of a potentially malicious file to the server. In a CMS environment this is a particularly critical vulnerability as the point of the CMS is to manage and deliver site-related files.
- Path Traversal. Allows the attacker to crawl the Web pages. In a CMS environment an attacker can exploit this type of vulnerability to access and map all hosted files.
Checkmarx tested the plugins for Path Traversal vulnerabilities only during the second scan.
- The findings from the second security scan were definitely an eye opener for me.
- 20% of the 50 most popular plugins contained one or more of the vulnerabilities listed above.
- 7 out of the top 10 most popular e-commerce plugins were vulnerable to common web attacks
There is no correlation between the number of Lines of Code (LOC) and the vulnerability level of the plugins. Every line of code has the potential impact of introducing a vulnerability. However, Checkmarx has found that the opposite does not hold true. Meaning, the smaller the codebase does not necessarily mean the safer the code. On the contrary – some plugins that included only a few thousand lines of code contained more types of vulnerabilities than plugins containing tens of thousands lines of code.
Only six plugins out of the 50 scanned in January were completely fixed during the six-month time period between scans. The following screenshot is taken from page 5 of the report that highlights which plugins were fixed. An important note to take away from these 6 plugins is that all of them were notified of their vulnerabilities by Checkmarx. Nowhere in the report is it mentioned that the authors of all the other plugins were afforded the same courtesy.
The report has sound advice some of which has been preached repeatedly over the years. For starters, only download plugins from reputable sources. The most notable is the WordPress plugin repository. By the way, I’ve noticed more plugin authors hosting their code on GitHub only. Take heed plugin authors that if you do this, by default, you’ve lost a degree or two of trustworthiness because GitHub is not the WordPress plugin repository. Instead, I highly recommend having a GitHub version that is kept in-synch with a WordPress plugin repository version. This article on WP Tuts+ does a good job explaining how to do that.
Their second piece of advice is to verify the security posture of a plugin by scanning it for security issues. I take issue with this piece of advice because it’s not like we as end users have a scanner in our back pocket. There is one plugin that is maintained by members of the core WordPress development team called Exploit Scanner. However, this plugin is not meant to be a security scanner for plugins, it’s more for monitoring suspicious activity on a website.
Three. Make sure plugins are kept up to date. Thanks to the ease of updating plugins, even in bulk, this is for the most part a painless process.
Fourth. Remove any unused plugins. If a plugin is no longer necessary, remove it instead of leaving it on the site deactivated. Use the option to delete the plugin along with its files from the WordPress plugin manager.
The report ends with recommendations to plugin developers and the WordPress plugin repository as well as any other application platform provider. Plugin authors are encouraged to integrate security within their development process.
The later a vulnerability is discovered, the higher the cost of fixing. But there’s more: a simple fix does not guarantee that the plugin users updated their sites. And until they do, these admins are left with the vulnerable plugins. The solution? Bake security within the plugin development as part of your secure Software Development Life Cycle (SDLC) process.
WordPress is not the only platform that has to deal with third-party issues like plugin security. According to Checkmarx, app marketplaces like the WordPress.org repository should:
- Enforce a security policy on apps that enter the marketplace. Although the security of a plugin may seem to be the developer’s problem, platform providers are held responsible in the light of users. Make security your competitive edge and build a marketplace where users can feel secure to return to.
- Authorize only apps that passed the security bar. Provide certification to those apps that stand up to the security policy.
There is more to the report than what I’ve covered in this post which you can download and read for free via their website.
Where Does This Report Leave Us?
WordPress plugin security has always been an issue that occasionally pops to the forefront of people’s minds. A good example is the W3 Total Cache and WP Super Cache plugin vulnerabilities in May of this year. It’s also a discussion we’ve been having for years. In 2009, I asked whether a plugin validation team was a pipe dream. The idea was taken from the phpBB project where the mod database would only allow mods to be hosted if they passed a strict code review process, ensuring the highest quality mods in an official, central location. Unfortunately, this method really hampered the growth of third-party extensions in their mod repository.
Today, there are at least a few members of the plugin review team for WordPress.org. These volunteers act as the front-line for plugins submitted to the plugin repository. (Thank you by the way for your work) Check out these detailed guidelines on what it takes to be hosted on the repository.
One of the arguments against having a dedicated team reviewing every line of code for submitted plugins is that there are already a large amount of eyeballs looking over code. Since everything is open-source, anyone can review the code. If the results of the report published by Checkmarx is any indication, there are not enough security minded folks dissecting plugins. It’s even more worrisome when you consider the results were based on the 50 most popular plugins. Those plugins should have had the most scrutiny considering their popularity yet, they contained vulnerabilities.
A Big Problem With No Easy Answer:
On the surface, plugin security is a big problem that can not be solved with one action. Instead, it’s going to take a multi-layered approach. Education is key. The plugin developer handbook being worked on as part of the handbook series of projects should be the starting point for all WordPress plugin developers. Especially part three which focuses on plugin security.
If Checkmarx is able to create an automated scanning analysis tool to discover vulnerabilities within the source code of plugins, why hasn’t the plugin repository come up with something similar that plugin authors could use as a tool or resource? At the very least, create a plugin that has the scanner built-in. Or, use the scanner as part of the process to review plugins and send them back to the author if a vulnerability is discovered.
The biggest impact and the one that would make all WordPress users safer would be implementing stricter policies with plugins on the repository. Unfortunately, restrictions and policies go against the open-source nature of WordPress. There is a fine line between the amount and difficulty of rules to be hosted on the repository versus going at it alone. I’d hate to see plugin authors give up hosting on the repository simply because it’s too difficult because of the policies. Some would even argue that the guidelines currently in place make it too difficult to be hosted on the repository.
By the way, if you think someone would be able to make a buck by reviewing code for themes and plugins, you’re wrong. Sites such as DevPress Code Review were launched only to disappear and ideas like WPCodeReview.com were discussed but never materialized. While a good idea that was backed by people on the WordPress Hackers mailing list, reality proved otherwise.
Throwing My Hands Up In The Air:
I don’t know what it’s going to take to solve the problem of plugin security. The more I think about it, the more it seems like it’s a necessary evil of open-source software. For as long as I’ve been active in the WordPress community, it’s been accepted by many that the plugin repository is filled with insecure code. The report by Checkmarx not only verifies that thinking, but shows that the problem could be bigger than anyone thought. One of the most unfortunate things about third-party plugins and themes is that if a site is compromised because of them, WordPress usually ends up taking the blame.
It’s depressing to think that so many people who love using WordPress are going to end up needing to hire someone to monitor their sites full-time or plunk down cash on something like VaultPress because of the epidemic of plugin vulnerabilities. The ease and joy of using WordPress quickly goes out the window with the introduction of the webmaster security hat. I think it’s reasonable to believe that the last thought on most WordPress users minds who add functionality to their site through plugins are not wondering if whether or not that plugin contains a security vulnerability. They just want that plugin to work without breaking anything else. To a point, I don’t think they should have to worry about it. WordPress users are repeatedly told to install/use plugins from a trusted source, the most trusted source being the WordPress plugin repository. What good is a plugin repository with thousands of plugins if all they end up being are ingredients to a toxic soup of disaster?
As the plugin repository continues to increase in size, so does the epidemic. WordPress community, what is the cure?
Interesting report. My takeaway is if they have this automated tool for WordPress plugins, why not offer it as a service for plugin devs? They already have put in the time to develop it, why not profit from it too? If the cost were within reason for smaller projects, I’d buy. Even better they could offer a litte seal that could be added to plugins.