Last month, more than 2,000 attendees from around the world came together in Vienna at WordCamp Europe to share their affinity for WordPress. As I sat there, sweating profusely and sharing ideas and thoughts with attendees, it hit me that we still have a long way to go with security in the community. I spent the next couple of days thinking through it and decided to share my takeaways in an open forum.
This article highlights five issues I believe to be plaguing the WordPress security community and provides some thoughts on how we can work together to overcome them. These thoughts come from my experiences working at Sucuri for the better part of six years, and actively engaging with the WordPress community around the world. They’re designed to generate discussion, introduce a new perspective, and hopefully, bring about good ideas and further engagement.
If we look back over the past few months, WordPress has been spared from any major attacks. With that, the media has slowly steered away from the onslaught of attacks it had fixated on the platform. This in part is because the platform itself has made a number of changes, embracing a more security-by-default model.
We’ve seen improvements like better password generation by default in 4.3, the auto-update feature by core in 3.7, and even the quick reaction tactics taken by the security team to auto-update critical security issues in plugins in the repo. We can probably accredit the generally good state we find ourselves in today to these changes.
Even with these improvements, however, WordPress sites are still getting hacked. In the Sucuri 2016/Q1 website hacked trend report, in which 77 percent of the 11.5k infected websites we analyzed were WordPress, we found that over 56 percent of WordPress installations were out of date. We also discovered that 25 percent of the compromises had either Gravity Forms, RevSlider or TimThumb installed. This points to a general administration problem with WordPress sites and spotlights challenges introduced by premium plugins.
Although a number of advancements have been made to the platform itself, there is still need for improvement in the realm of education and awareness. For instance, at WordCamp Europe, there were only two security-focused sessions — one was 10 minutes and the other was 20 minutes. This speaks volumes to how we as a community look and appreciate website security.
When it comes to WordPress security, we need to change our perspective. The core software is not responsible for site hacks. It’s us. It’s the way we pitch our projects, teach new users, and manage our websites. This is challenging, because unlike code, it can’t be debugged as it relies heavily on an unmanageable variable – people.
The WordPress Security Challenges
1. The Biggest Vulnerability In WordPress
In 2012 I wrote an article in which I shared my thoughts on the real WordPress vulnerability. Today, four years later, it hasn’t changed. The lowest common denominator is still the website owners themselves. The platform by design is built for end users, which has directly contributed to WordPress’ massive adoption and growth. Conversely, it’s also the weakest link in terms of security.
As a community, we have enabled a mindset of indifference amongst WordPress users. The process has been oversimplified and there has been an overemphasis on ease of use. While these things are innate in WordPress itself, they are also part of the problem.
There are no absolutes in security, yet this is what we communicate and it’s become an expectation. It’s not to say that we should lead with fear, uncertainty or doubt (FUD), but we shouldn’t diminish reality. Websites get hacked, bad things will happen to your web property. You will be panicked. You will curse every provider you use. It will be everyone’s fault but your own. Your online business could be offline for days or even weeks. These are real experiences, they are not exaggerations of the truth.
2. Continued Drop In Technical Aptitude
The platform was built for the end user. It’s at the core of every decision the platform makes, it’s engraved in its philosophy. The challenge we are faced with is how do we maintain this end-user focus, while encouraging a more effective security by default model. How do we work with our users to increase their technical aptitude?
In WordPress, more than in any other platform I collaborate with, I have noticed that the technical aptitude continues to drop. Fewer website owners know the basics of hosting, how the internet works, or basic administration of their web property. I can’t decide whether this is good or bad. On one hand, it’s great for the platform’s growth, but from a service provider’s perspective, we are faced with the challenge of educating users on security issues which they may not have the technical capacity to understand.
3. Education And Awareness Aren’t Scaling
WordPress’s growth is incredible, however, with it, we need to continue to educate and bring awareness to website security. The security market has grown, and the amount of noise that floods the internet is difficult enough to decipher as a security professional let alone a website owner.
This challenge is further complicated by the quality of education available. In addition to the basic website security tips, we need to start having more comprehensive security conversations. By taking a more holistic approach to security, we can focus on the entire threat landscape and start conversations that include increased emphasis on basic concepts like administration functions.
We need to revisit InfoSec’s three core tenants: People, process, technology.
4. The Effects of Vulnerability Disclosures
Today a lot of disclosures are opportunistic, with incorrect classifications and awareness, which creates more noise in an already noisy domain.
I believe that healthy research brings about good improvements and propels the platform forward.
For example, look at WordPress’s security posture, compared to 2014. We’ve seen huge strides both from core and plugin developers to overhaul and improve security development practices and overall responsiveness and awareness to potential issues.
I feel like the way vulnerability disclosures are being treated today put the emphasis more on marketing potential than true disclosure. Most disclosures, while correct in that they are a “vulnerability,” fail to emphasize the real threat they pose to the website owner.
“If everything is a priority, then nothing is a priority.”
A perfect example of this can be found when thinking about a Cross Site Scripting (XSS) vulnerability. Other examples can be seen in the lack of weight applied to vulnerabilities that require authentication versus those that don’t. While something at the surface might be severe, when you take the authentication requirement into consideration, the severity value may drop. Not all vulnerabilities are equal, and they don’t all require the same level of amplification.
With the current configuration, it’s possible that we are doing more harm than good, both in the way we’re sharing information and more importantly how that information is syndicated. Fortunately, it can be addressed by placing more emphasis on the way we classify and categorize vulnerabilities.
5. Regurgitation Of Bad Advice
We need to do a better job of self-governing when it comes to what we tell website owners about security. We can’t keep regurgitating what others are saying, without first thinking through the recommendation itself. We also need to do a better job of updating our Top 10 lists as the landscape continues to evolve.
In a future post, I will deep dive into some of the bad advice that exists, and how to eradicate it. But for now, we can start by agreeing that removing the “powered by WordPress” tagline is perhaps the most ridiculous of all recommendations. It’s difficult enough to sift through the noise, let’s do a better job of better streamlining the process.
Thinking Through The Security Challenges
It’s going to be an uphill battle for the community, especially at WordPress’s current growth trajectory. We need to start having serious conversations around WordPress security and how we are communicating and pitching projects and what we are telling website owners. The change won’t come from any one person or vendor but as a collective group.
As for who is responsible, I honestly have no idea. I think it’s unfair to put this on the shoulders of the core team. Besides, as I mentioned before, it’s not a programmatic issue. I do wonder where the appointed security czar fits into the grand scheme of things.
We have to start holding ourselves and others more accountable, and we need to be better stewards of the type of information we disseminate and place more emphasis on value-based articles and discussions. We have to stop coddling our customers and need to have a focused security presentation at every WordCamp.
Let’s think about the responsibilities we have as website owners. The responsibility to be a good steward of the internet. The responsibility to ensure our users have a safe experience.
How do these thoughts align with yours and the challenges you see in the community when it comes to security?