Dear WordPress Community,
It hasn’t been a full month since we discussed the MailPoet security breach, when just a few days ago another disaster struck.
It was discovered that Slider Revolution, the most popular slider plugin used by staggering amount of themes (more than 1,000 themes include it) has a serious security issue allowing hackers to gain control of the affected site.
The Problem
The major problem is the current mindset and approach to security in the global WordPress community. 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.
“We were told to keep our mouths shut” makes me scream. It also seems to be on the border of being legally pursuable. And cases like this – a major one almost each month – have really hit a point of no return, at least for me.
Quite frankly, I am getting sick of this. I am getting sick of people calling WordPress unauthenticated remote shell that, as a useful side feature, also contains a blog. This negative sentiment about WordPress is doing millions of dollars worth of damages to thousands of businesses that rely on WordPress.
The problem affects millions of users, bloggers and families whose sites are being hacked. Finally, it slows down the worldwide adoption of the WordPres 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 WordPress core today is safe as any CMS can be. The rough path it had to go through in the past 11 years is also one of the key strengths of WordPress today. An incredible volume of issues have been ironed out and vast knowledge of web application security have been gained by the project bearers.
It is obvious that the biggest threat to the project nowadays lies in the third party plugins, and to the lesser extent themes (ironically again, that is 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 were examples of vulnerable plugins that were being actively maintained, most of the danger is in the thousands of plugins that are being left alone and not updated any more, or where simply poor coding practices and developers’ lack of web application security knowledge cause them to write vulnerable code.
There are currently 33,000+ plugins in the WordPress repository and some 3,000 more in Envato. My rough estimate is that 2% of them are a potential security concern; ranging from the simplest forms of XSS/CSRF vulnerabilities to more dangerous types of broken authentication and session management issues. That is around 800 plugins that at this moment potentially present future danger to the WordPress community and reputation of the WordPress platform.
What’s Being Done
There are security plugins like iThemes Security and services like 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 can not speak for Envato, but WordPress plugin repository has undergone a number of improvements in the recent years that helps with the issue.
The Version Compatibility and Last Updated features tell the user if the plugin is being actively maintained. The longer a plugin goes without an update, the more likely it is a ticking bomb.
An effort to perform code reviews was introduced (in the forms of automated reviews as far as I know) when new versions of the plugins are submitted to the repository.
As a plugin developer I was recently pleasantly surprised by an email when WordPress 4.0 came out, notifying me that I need to check and update the plugin compatibility for my submitted plugins, listing them with their current compatibility
However, people often don’t check when the plugin was last updated. Vulnerabilities such as those described earlier are difficult to find with automated code scans. And I have 30+ plugins in the repository; how will I 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 what the community needs is a scalable solution that will help create/enhance the perception of WordPress as a secure platform. We are facing a large scale effort here – no doubt about it. But the sooner we start, the better.
I propose a three way process.
First would be weeding out the plugins with potential security issues. Given the sheer number of plugins to check, the wisest thing to do would be to call the power of the masses and launch a crowd-sourced white hat security effort.
It has been done before with success, and all major web companies like Facebook are doing it. We had a lot of experience and success running our own white hat security reward program and I can tell that this works. Over the years it helped us find potential issues with the software and also educate us a great deal in this area. As a result, in four years that ManageWP exists, with over 200,000 managed websites now, we have not suffered a single security incident.
This is exactly what WordPress needs, only at a larger scale. Luckily, it has a large community that can help to achieve this. I do not want to go into details how to organize a white hat program, but from experience it needs to have strict set of rules and an automated process to avoid being overwhelmed with low quality submissions.
If such ‘call for help’ was issued, I am sure that many would jump in, without any promise of compensation or incentive. A simple Hall of Fame (like this) in a prominent place on WordPress.org would do wonders. Simply by being on this list, those individuals will be establishing their reputation in the community and presented with numerous job/consulting offers in the future.
To further improve the chances of the effort succeeding, monetary reward for finding vulnerabilities should be considered. For example, $50-$100 for XSS/CSRF and $500 for a major vulnerability that exposes the entire website to hackers. I estimated 800 plugins as potential risk earlier, and guessing that the majority of rewards would be lower risk security issues, I estimate it would need around $150,000 to cover the rewards.
Once a vulnerable plugin is found, it would enter a quarantine procedure. It would be immediately suspended from the repository and a note sent to its developer and placed on the public list, explaining the vulnerability and effects. A few weeks would be given to fix it by its developer (or the community; another opportunity for hall of fame) and if not fixed it would be permanently removed.
It also opens door for the WordPress Foundation to ‘recruit’ people that did great in this part of the challenge.
At the same time there should be an effort to enhance the plugin verification process in the WordPress repository so all new plugins/commits are scanned. A good pointer is the way the theme review process considerably advanced through the years. The last time I tried to submit a theme two years ago I was met with very strict requirements and at the end I gave up (it required too much effort and I wasn’t that keen on the theme). And that really is a huge, fantastic thing. If you really want your theme in the repository where it would be immediately exposed to millions of WordPress users, you should be rightfully required to put out a lot of effort.
The plugins should absolutely get the same treatment. A great example is how Symfony (a great PHP framework) has a tool that allows you to check your project for security vulnerabilities.
Finally, there should be a conscious effort to educate the WordPress developer community, which goes beyond what is done at the moment. The Foundation can do two things effectively. First is the creation of the vast knowledge base on security (best coding practices, tools, tutorials) on WordPress.org. The other is calling 2015 a year of WordPress Security where this would be the main theme of all WordCamps throughout the world.
I estimate the total cost of the project including reviewers, automation of the process, software and rewards would probably be around $500,000 USD. Given how much is at stake here, I think that is completely reasonable. Even if I am off by a lot and the cost was ten times more, it would still be reasonable to start this action today, for the huge effect it will have on the WordPress project and the WordPress economy.
While most would expect Automattic to fund this, I think that does not necessary need to be the case. This problem affects a great number of WordPress-based businesses (plugin and theme shops, hosting, web design and development etc.) as well as businesses that simple run their sites on WordPress. Why wouldn’t we all join the effort to make ‘our’ platform better so that our businesses can thrive in the future? As a start, I am ready to pledge $10,000 USD in the name of ManageWP to help fund this effort.
To recap:
The perception of WordPress being 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 white hat security program, stricter code reviews and investment in education of WordPress developers is the way out
The cost may range from $500K to $5M, but the funds could be acquired through the participation of interested WordPress businesses
You do not have to pledge funds to this effort; simply your time, experience or opinion will mean a great deal because there are so many of us. Please do not wait for your site/business to be compromised next before you decide this is something we as a community must do.
Sincerely yours,
Vladimir Prelovac
