open source web securityIf you were working on your WordPress website today, or casually reading the latest news about WordPress, you most likely got inundated with news about an XSS vulnerability, inaccurate documentation, and the infamous WordPress auto-update feature.

Each of these terms sometimes sound like four-letter words in the context of web security or user experience. The truth is, in fact, the exact opposite. What happened over the last few days and published widely today was a high-point for WordPress security and the Open Source philosophy. Let me explain a bit about how the Open Source philosophy went into full effect this weekend, and why I trust it with web security far more than proprietary philosophies.

Open Source Web Security Means Collaboration not Competition

open source collaboration and web security
Open Source Collaboration “Lifts all Boats”

Without the Open Source mentality a security vulnerability could very easily go unnoticed for months at a time. If the developers were to be notified of it, they very easily could use that to their monetary gain, fixing it on their platform, while highlighting it in others’. Without Open Source, when it comes to security and profits, it’s a dog eat dog world.

On the other hand the Open Source mentality believes that collaborating on security and best practices “lifts all boats”. Everyone benefits from collaboration — especially the end user.

This past weekend was a testament to that. On Friday, we were contacted by Joost de Valk, author of WordPress SEO and founder and CEO of yoast.com about the XSS vulnerability. He said that there were A LOT of plugins that were vulnerable and that he and several on the WordPress Core Team were trying to gather plugin authors to coordinate their efforts on this release. Why would they do that?

Two words: Responsible Disclosure.

Responsible Disclosure is a security practice by which a person or team that discovers a security vulnerability notifies the plugin author and allows them ample time to (1) Fix the vulnerability; and (2) notify their users, allowing their users to have enough time to update. Once those two things are done, the person/team that found the vulnerability can publish their findings “responsibly”. This ensures that people who do excellent bug finding and troubleshooting get the credit they deserve without putting thousands of sites at risk.

Joost was notified by the team at Scrutinizer CI about the vulnerability in their plugin. After digging into it, he realized that because the function was described in the WordPress Codex using several examples which were not secure, most likely it existed in many plugins, not just his. He knew that once his fix was out, that the Scrutinizer CI team would (or could) soon release their article about their discovery. If all the other plugins weren’t also notified and updated then the vulnerability would be public and thousands and thousands of sites could be compromised much more easily than before.

This is where is gets interesting.

So Joost then reached out to the WordPress Core Team and as many plugin developers as he could find to notify them of the vulnerability. From there, the collaboration caught quick fire. The Core Team created a Slack channel to collaborate with plugin authors (ourselves included). The result was getting plugin developers from across the globe the be able to quickly understand the vulnerability, reproduce it in their plugins, fix it, and coordinate a push early this morning.

So instead of one plugin being fixed, we saw a large and growing amount of plugins fixed in a very short time, all because of collaboration instead of competition.

How this Affected WordImpress

Every story has two sides of it though. We at WordImpress fully embrace the Open Source philosophy, including the freedom to use other GPL licensed code to give you a head start on your own plugins. For example, we’re proud of how Easy Digital Downloads sped up development of our latest plugin, Give. We were able to inherit a lot of really excellent code from them that powers our reports and several other things. We’ve also been thrilled to see the EDD team contributing even more to our plugin on Github.

But… we also inherited this vulnerability. That is not a statement of blame in any way. We should have dug into those functions more ourselves, we should have cross-checked with the Codex (which wouldn’t have helped in this case). This is an example of how Open Source actually spread the vulnerability.

So you might think that would be a weakness. But the truth is, that:

  1. What we gained in security in 99% of the code outweighs this one example; and
  2. The collaboration to fix the problem far outweighs the inheritance of the problem

As you might know, we have been busy continuing development on Give so we’re actually excited that this came up so early in our development phase. For good measure, here’s the updates we included in this latest release besides this security fix:

= 0.8.5 beta =

  • Fix: Global vs Form Payment Gateways https://github.com/WordImpress/Give/issues/86
  • Fix: Setting Section Title Not Displaying Proper Text https://github.com/WordImpress/Give/issues/87
  • Fix: Prefixed “icon” and “icon-question” classes to mitigate conflicts: https://github.com/WordImpress/Give/issues/103
  • Fix: {name} isn’t correctly rendered in test email: https://github.com/WordImpress/Give/issues/100 – Thanks @sumobi
  • Fix: When exporting a report, apostrophe’s are not correctly shown: https://github.com/WordImpress/Give/issues/96 – Thanks @sumobi
  • Fix: PHP warning when exporting PDF: https://github.com/WordImpress/Give/issues/93 – Thanks @sumobi
  • Fix: Property of non-object on Forms Report: https://github.com/WordImpress/Give/issues/91 – Thanks @pippinsplugins
  • Fix: PHP Notice: Undefined variable: unlimited: https://github.com/WordImpress/Give/issues/89 – Thanks @sumobi
  • Fix: Prefix .icon class to prevent conflicts #103: https://github.com/WordImpress/Give/issues/103 – Thanks @stevengliebe
  • Update: Removed unnecessary contextual help files until we decide how we are going to approach this with the plugin
  • Update: Inline code comments improved to be more specific to Give – some were incorrectly describing old EDD functionality
  • Security: Hardened URLs with esc_url() across the plugin core

But Why So Public?

For many, this is yet another “BIG” security issue with WordPress, or with Open Source. I don’t see it that way. Vulnerabilities like this need to be discussed publicly because information is King, and Open Source is about the spreading and sharing of information. Posting about these security issues doesn’t make WordPress less secure, it makes all of us more informed. And truth be told, we humans are the most insecure thing about WordPress. It’s not things like this that will tear our sites apart. It’s laziness, or lack of due dillegence. Like John Oliver said to Edward Snowden:

You’re right, I get how important it is, the problem is:
I’m not going to do it, because it seems hard even though I know it isn’t.

Additional Resources on this Vulnerability

Matt is Head of Support and Community Outreach at WordImpress.com. He’s the author of many free WordPress plugins, a popular blogger at his website, an admin of the Advanced WordPress Facebook group, co-organizer of the San Diego WordPress Meetup, and a frequent WordCamp speaker and attender.

Follow Matt:

Leave a Reply