The founder of ManageWP, Vladimir Prelovac, has published an open letter addressed to the WordPress community on the topic of security. In the letter, he cites the third-party ecosystem surrounding WordPress is not only its biggest strength, but also its biggest weakness.
He suggests a three-point plan to help mitigate security issues in themes and plugins.
- Weed out plugins with potential security issues.
- Enhance the plugin verification process in the WordPress repository so all new plugins/commits are scanned.
- Educate the WordPress developer community, which goes beyond what is done at the moment.
Although Prelovac urges the community to start addressing these problems today, most of what he suggests is already occurring and has been for years.
Weeding Out Plugins
This is a process that takes place 24 hours a day, 7 days a week. It’s largely a byproduct of so many people using WordPress and the code for plugins being open source. This gives anyone the opportunity to review the source code to check for vulnerabilities. My guess is that most vulnerabilities in plugins are discovered due to a security keen user or researcher reviewing the plugin because they want to use it on their site.
Samuel “Otto” Wood explains what happens when a plugin in the directory is discovered to have a security issue.
- The plugin is de-listed from the repository, to prevent further downloads of an insecure plugin.
- If the exploit is accidental or not obviously malicious, the developer is notified via email. The email comes from a valid address (plugins @ wp.org) and can be replied to.
- The plugin developer presumably fixes the exploit or tells us that it is an invalid exploit, updates the plugin in SVN, and emails back saying so.
- We check it out, and either provide advice or re-enable the plugin.
Enhancing The Plugin Verification Process
This is one area of the WordPress plugin directory I consider a weakness. After a plugin is reviewed and approved, a malicious plugin author can upload a different code than what was initially reviewed. This is considered a bait and switch technique. The only way to prevent this from occurring is more humans as there are several times more plugin committs than there are plugin reviews.
In an interview published on the Tavern earlier this year, Mika Epstein, who is a member of the plugin validation team, described how they try to combat the issue.
Someone submits plugin A, we approve it, but they upload plugin B to the repository. That’s something a lot of spammers like to do. Sometimes people upload the wrong version of the code by accident, other times they intentionally go back and add in code we told them to remove. We try to mitigate this by filtering emails (I actually get an email for every single plugin check in) and scan for known issues, but it’s never-ending.
The review team is constantly improving its checks, which help them scan for the most basic and unintentional violations. Unfortunately, there is no way to scan for bait-and-switch techniques, which require someone to go back and manually check for violations after the plugin is already sent to the repository.
Expanding Educational Resources For The WordPress Developer Community
Prelovac suggests that security information and best practices should be merged into a single resource. He also suggests that 2015 become the year of WordPress security. This includes WordCamps across the world where security would be the main theme.
The WordPress Plugin Development handbook project is still ongoing but is essentially what Prelovac is suggesting. There’s already a chapter dedicated to Plugin Security covering data validation, nonces, and checking user capabilities. If you’d like to contribute to the handbook project, check out this page for additional information
As for WordCamps, most of them already have a session or two on security. I don’t think a WordCamp or conference devoted to security in WordPress would work. It can be a dry subject and quickly go over the heads of users. I’ve attended a few different security sessions at various WordCamps and some people left the room in a panicked state.
There is no shortage of resources and tools to help developers write clean code. There are books such as WordPress Plugin Development and Professional WordPress Design and Development, 2nd Edition. Then, there is WordPress.TV with sessions like Kurt Payne and Josh Hansen: do_action(‘hack_me’) Advanced Security for Plugins or Mark Jaquith: Theme & Plugin Security. The knowledge is out there, plugin developers have to find it.
Most Of What Prelovac Suggested Already Exists
Just about everything Prelovac has suggested in his open letter either already exists or is an ongoing project. I agree that the biggest threat to WordPress and its reputation are the plugins and themes built for it.
The gatekeepers for the plugin directory and the theme review team have done a great job of protecting users from security issues when they’re discovered. On the other side of the coin, plugin and theme developers have for the most part, done a good job pushing out a patch once a security vulnerability is reported.
News Of Security Vulnerabilities In Plugins Will Be More Common
No software is perfect as it’s written by humans but the tools in place on WordPress.org make patching holes a quick process. Updates are sent to every user of the affected plugin and in most cases, updating is as simple as clicking a button.
With thousands of plugins available for WordPress both in and outside the official directory, I think reports, disclosures, and immediate updates for security issues will be more common. I think they already are but because no one has consistently reported on them, especially the minor ones, it doesn’t seem like they’re common. How a developer or business reacts to and notifies users/customers of a security issue is just as important as fixing it.
End User Responsibility and Auto Security Updates For Plugins
Education is a key component the helps users keep their sites safe and for developers to write clean code. At the end of the day, the user has a responsibility to make sure their website, themes, and plugins are up to date. If users fail to keep their sites up to date, everything else becomes a moot point.
While WordPress auto updates to point releases, could we eventually see auto updates for major security issues in plugins? This happened with Jetpack 2.9.3 which fixed a critical security bug and updates were pushed out through WordPress cores auto-update system.
Personally, I don’t want to see that happen as I like control and do a good job of keeping myself updated. I rarely leave an update notification stick around for more than an hour. Is the idea of updating plugins automatically from critical security bugs for the sake of keeping the web and users safe a justifiable one?
Site environments are far too varied for forced automatic updates to be particularly viable, but I think as an opt-in feature it could be very useful. For instance: due to the git workflow I use to develop and deploy most sites, it would be a nuisance for plugins to start updating themselves on the production sites – even if they are non-breaking updates. As well, there’s a lot of room for abusing such a feature (think a bait and switch being silently pushed to sites with the previous plugin).