Dear WordPress Community,
It hasn’t been a full month since we discussed the MailPoet security breach, and another disaster struck just a few days ago.
It Slider Revolution that , the popular slider plugin used by over 1,000 themes has a serious security issue allowing hackers to gain control of the affected site.
The Problem
The major problem is the global WordPress community’s current mindset and approach to security. After the Slider Revolution incident, its developers released a statement that, among other things, said:
The problem was fixed 29 updates back in 4.2 in February. We were told not to make the exploit public by several security companies so that the instructions of how to hack the slider will not appear on the web.
Saying “we were told to keep our mouths shut” makes me want to scream. It also seems to be on the border of being legally pursuable. Cases like this—with a major one occurring almost every month—have really hit a point of no return, at least for me.
Frankly, I am getting sick of this. I am getting sick of people calling WordPress an unauthenticated remote shell that, as a useful side feature, also contains a blog. This negative sentiment about WordPress is creating millions of dollars’ worth of damages for the thousands of businesses that rely on WordPress.
The problem affects millions of users, bloggers, and families whose sites are being hacked. It also slows down the worldwide adoption of the WordPress platform due to negative press in the media.
But things could be different. Things are different.
Thanks to the incredible effort of the community of contributors, I would say that today, the WordPress core is as safe as any CMS can be. The rough journey it faced over the past 11 years is also one of the key strengths of WordPress today. An incredible number of issues have been ironed out, and the project bearers have gained a vast amount of knowledge about web application security.
It is clear that the biggest threat to the project today lies in third-party plugins and, to a lesser extent, themes (which is ironically its biggest strength). I had the opportunity to witness this myself recently when I had to repair a bunch of hacked sites.
While MailPoet and Slider Revolution are examples of vulnerable plugins that were actively maintained, most of the danger lies in the thousands of plugins that are left alone and not updated anymore or in developers’ poor coding practices and lack of web application security knowledge, which causes them to write vulnerable code.
The WordPress repository currently includes 33,000+ plugins, with approximately 3,000 others in Envato. My rough estimate is that 2% of these have potential security concerns, ranging from the simplest forms of XSS/CSRF vulnerabilities to more dangerous broken authentication and session management issues. In other words, around 800 plugins at this moment could present a future danger to the WordPress community and the reputation of the WordPress platform.
What’s Being Done
There are security plugins such as iThemes Security and services such as Sucuri that help identify and fight hacks. I have also made it a personal quest to include a full suite of security tools in ManageWP by 2015. But we need to extinguish the fire at its source.
I cannot speak for Envato, but the WordPress plugin repository has undergone a number of improvements in recent years that help with this issue.
The Version Compatibility and Last Updated features tell the user if the plugin is actively being maintained. The longer a plugin goes without an update, the more likely it is to be a ticking bomb.
An effort to perform code reviews was introduced in the form of automated reviews (as far as I know) when new versions of plugins are submitted to the repository.
As a plugin developer, I was pleasantly surprised by a recent email when WordPress 4.0 came out notifying me that I need to check and update compatibility for my submitted plugins; the email provided a list of my plugins and their current compatibility.
However, people often don’t check to see when a plugin was last updated. Vulnerabilities, such as those described earlier, are difficult to find with automated code scans. I have 30+ plugins in the repository; how I can find time to update all of them to 4.0 compatibility let alone carefully check them against all the changes is beyond me at this point.
What Can Be Done
I think the community needs a scalable solution that will help create/enhance the perception of WordPress as a secure platform. This would involve a large-scale effort—no doubt about it. But the sooner we start, the better.
I propose a three-step process. The first step involves weeding out plugins with potential security issues. Given the sheer number of plugins to check, the wisest thing to do would be to call on the power of the masses and launch a crowd-sourced, white-hat security effort. This has been done before with success, and all the major web companies, including Facebook, are doing it. We had a lot of experience and success running our own white-hat security reward program, so I can tell you that this works. Over the years, it helped us find potential issues with the software, and we learned a great deal about this area. As a result, in the four years that ManageWP has existed and with over 200,000 managed websites, we have not suffered a single security incident.
This is exactly what WordPress needs, only on a larger scale. Luckily, it has a large community that can help achieve this. I do not want to go into detail about how to organize a white-hat program, but in my experience, the system needs to have strict set of rules and an automated process to avoid being overwhelmed with low-quality submissions.
If such a call for help was issued, I am sure that many would jump in, even without any promise of compensation or other incentives. A simple Hall of Fame (like this) in a prominent place on WordPress.org could do wonders. Simply by being on this list, those individuals will establish their reputation in the community, and they could get numerous job/consulting offers in the future.
To further improve the chances that the effort will succeed, the second step in the process involves a monetary reward for finding vulnerabilities. For example, $50–100 could be offered for finding XSS/CSRF issues, and $500 could be offered for finding a major vulnerability that exposes the entire website to hackers. Earlier, I estimated that 800 plugins are potential risks; assuming that the majority of the rewards would be for low-risk security issues, I estimate that around $150,000 would be needed to cover the rewards.
Once a vulnerable plugin is found, it would be quarantined. The plugin would immediately be suspended from the repository, a note would be sent to its developer, and the plugin would be placed on a public list with an explanation of the vulnerability and its effects. Developers (or the community, in another opportunity for a Hall of Fame) would be given a few weeks to fix the plugin; if it is not fixed, it would be removed permanently.
This also opens door for the WordPress Foundation to recruit people who perform well on this part of the challenge.
At the same time, an effort should be made to enhance the WordPress repository plugin verification process so all new plugins/commits are scanned. A good example of this is the way in which the theme review process advanced through the years. The last time I tried to submit a theme, which was two years ago, I was met with very strict requirements; eventually, I gave up (it required too much effort, and I wasn’t that keen on the theme). That really is a huge, fantastic thing. If you really want your theme in the repository where it will be exposed to millions of WordPress users, you should be required to put forth a lot of effort.
Plugins should absolutely get the same treatment. A great example is the tool from Symfony (which is a great PHP framework) that allows you to check your project for security vulnerabilities.
The third step involves making a conscious effort to educate the WordPress developer community beyond what is currently being done. The Foundation can do two things. First, it can create a vast knowledgebase on security (best coding practices, tools, tutorials) located on WordPress.org. Second, it can call 2015 “The Year of WordPress Security,” making this the main theme of all the WordCamps worldwide.
I estimate that the total cost of the project, including reviewers, process automation, software, and rewards, would probably be around $500,000. Given how much is at stake here, I think that amount is completely reasonable. Even if I am off by a lot and the cost is ten times more, it would still be reasonable to start this action today because of the huge effect it would have on the WordPress project and economy.
While most would expect Automattic to fund this, I think that does not necessarily need to be the case. This problem affects many WordPress-based businesses (plugin and theme shops, hosting, web design and development, etc.) as well as businesses that simply run their sites on WordPress. Why wouldn’t we all join the effort to make “our” platform better so our businesses can thrive in the future? As a start, I am ready to pledge $10,000 in the name of ManageWP to help fund this effort.
To recap:
- The perception that WordPress is insecure is the greatest threat to the WordPress project today.
- This is a large-scale problem that requires a crowd-based solution.
- A combination of a white-hat security program, stricter code review, and investments in educating WordPress developers is the solution to this problem.
- The cost may range from $500K to $5M, but the funds could be acquired from interested WordPress businesses.
You do not have to pledge funds to this effort; simply offering your time, experience, or opinion would be a great help. Please do not wait for your site/business to be compromised before you decide that this is something our community must do.
Sincerely yours,
Vladimir Prelovac
J.D. Grimes
This is a good idea, and I really wish it would happen. However, I think your estimation of the number of vulnerable plugins is backward. Think 98%. Seriously, I’d be very, very surprised if the number was less than 50%. And I’m talking about fairly easy to spot vulnerabilities, too, not really complex hard-to-detect ones.
Asad
The problem is within all the people calling themselves “WordPress Developers”. Seriously, any PHP developer with a year or two of experience should have known about the vulnerability in Slider Revolution. Instead of trying to come up with a quick-fix for the issue, we should really be educating more developers about basic Web or PHP security.
Sure you may love the WordPress Abstraction Layer, but it’s still essentially PHP. Learn the PHP best practices first: http://www.phptherightway.com/
Vladimir Prelovac
Thats a great resource, thanks Asad!
David McCan
I very much appreciate that you are speaking out about an important issue and that you are willing to contribute to the effort. I have had thoughts about this topic, some of which might not be that popular, but in the spirit of brainstorming and looking to improve security, here they are:
-When I hear that a theme or plugin has a security issue I don’t automatically think that WordPress is insecure. It annoys me that some people create link-bait articles that suggest that. I realize that for some people there is no difference between a theme, a plugin, and core. I also realize that they are all part of the same ecosystem, but I think it is important that more experienced users make the distinction. With that in mind, a bounty on security issues in WordPress core makes good sense to me. It does not make as much sense to have a bounty for user contributed plugins or themes.
-Having good security reviews for contributions to WordPress.org also makes sense, but we have to be careful that we do not create a bottleneck that ends up discouraging people from contributing or leads them to host them elsewhere, thereby avoiding the security check altogether. There needs to be a balance and of course, any automated checks that can be done are great. I have seen some projects have a security team that reviews code independent of submissions as well. If WordPress.org, ThemeForest, and other repositories have a strong review policy then that is not only good security but also good marketing.
-There has recently been a lot of discussion about ways to strengthen the marketplace, with suggestions such as raising prices and doing away with lifetime upgrades. This is an area where lifetime upgrades removes a barrier to using the latest and presumably most secure version. Certainly, people making purchases need to be aware of the responsibility of renewing their subscription, if lifetime upgrades are not included.
-I think that the automatic update to WordPress core is fantastic. I really appreciate that the WordPress team saw the importance of keeping things current and went out on a limb to make it happen. There was a lot of uneasiness when it was proposed and some still are wary.
-There are some security functions in common plugins that perhaps should be included in core. Limiting failed login attempts comes to mind.
-I think the idea of color-coding plugins and themes hosted by WordPress.org is a good one, though it is something that needs to be done carefully.
-Allowing plugin and theme authors to mark a project as no longer being maintained would have a lot of benefits. It would tell users not to expect updates and support and might help in the color coding. Users sometime vent frustration when their support questions are not answered. This would also flag projects as available if someone else was willing to take them over.
Thanks again for the good thoughtful article and your willingness to contribute.
Vladimir Prelovac
Hi David
Thanks for the thoughtful feedback. You make some great points. I think WordPress core is at this point mature and very unlikely to be a source of security vulnerabilities. In all recent cases the source was third party plugins which is expected.
I am all for creating a bottleneck with the review process as getting into this repository should be incredibly hard. Yes an alternative one may spawn but who would use the repo that owes its existence to a weak (if any) plugin security verification process?
Obviously it is a large topic, for me it is important to keep the movement going.
David McCan
Hi Vladimir,
Bottlenecks and community do not go well together. Initiatives that dampen community involvement are death to an open source project. None of us could feel good about that. While I understand the sentiment behind your comment about “creating a bottleneck”, I would urge you to be careful so that you do not sound like an extremist who people might write-off or ignore. Practical solutions that find a middle way are more likely to garner support. Please do keep the ball rolling.
While I agree that WordPress core is mature, I would not assume that there are no security vulnerabilities. If there were none then we would have a bounty that could not be claimed, which would be awesome in its own right.
Maybe a consortium of theme and plugin authors would be willing to contribute a small portion of their sales to a bounty fund for their products, say $1 for each sale. Perhaps a security minded WordPress company might be willing to sponsor / coordinate some bounty programs. For plugin and theme authors that might mean a “Scanned by” or “Secured by” company XYZ badge that would offer confidence to buyers.
Vladimir Prelovac
I certainly do not support any extreme view. I gave an example of theme review process which is already much more advanced and demanding than the current plugin review process. In my view the plugin review process should follow that example.
Lisa
If you’re going to visually designate this, be sure to use symbols not just colors – red, yellow, green – because there are quite a few folks who will not be able to clearly distinguish by color alone.
Aurélien Denis
What a great initiative! Let me know if you need a French information relay. I could support it my way.
Aaron B. Hockley
I too would be willing to make a financial contribution to this effort.
jim
I would add that a color scheme should be developed based on user input and reported security issues. This color scheme would appear within the WordPress plugin list, like the below example.
This would make it easier for all when installing plugins to identify those with “issues,” so clients can make a somewhat more informed decision.
Example: http://goo.gl/Qxm0Af
Green – No reported security issues (based on reports from security companies) and client’s love it (based on a formula that takes into account percentage of positive to negative remarks, and last update date, etc.).
Yellow – Some reported issues, or not currently compatible with latest version (see above).
Red – Known security issues or outdated by more than 2 years (see above).
These color codes can be corrected by plugin author, through a suitable review request process (ala Google), to bring plugin back to green status.
The process above would be a great deal more management than a wholesale turning off of plugins or other drastic actions.
Vladimir Prelovac
Hi Jim
Color coding makes a lot of sense. But if there was a known security issue the plugin should not be in the repo 🙂
Mark Gavalda (@MarkGavalda)
This is an awesome proposition, Vladimir and I (and my company) fully support it! Hopefully the great gals and guys behind wordpress.org will organize (or let us organize) something similar as this would truly benefit _everyone_ related to WordPress!
Alex Ivanovs
I could write a blog post to help further promote.