Earlier this year, a security vulnerability in WordPress and Drupal was discovered by a member of Salesforce’s security team, Nir Goldshlager.
Goldshlager co-authored an article on Mashable about the vulnerability, which Mashable waited to publish until after the issue was patched in WordPress and Drupal.
This is a great example of responsible disclosure of a security vulnerability in open source software. The issue itself was reported in private to those who could fix it. It was kept a secret only long enough for the affected software to be patched. Now the exploit (and how to fix it) is available for developers to learn from.
The details of the vulnerability were also made available to those who might use the information for evil rather than good. However, in this case they were used to perform coordinated denial of service attacks against WordPress and Drupal sites. There is nothing anyone can do to prevent that sort of knowledge from reaching the evil doers of the internet, however giving the good guys a head-start lessens the potential damage significantly.
As the WordPress ecosystem continues to grow, we owe it to ourselves (and to WordPress users) to not only be responsible about security vulnerability disclosure, but to be take proactive measures to minimize and avoid vulnerabilities in the first place.
Communication Is Key
If you create software, eventually someone is going to find a security vulnerability in it — minor or major. When it happens, you need to make sure that it is easy for the vulnerability to be reported. This is part of why it is important to host your plugin or theme on a site, such as WordPress.org, which has a trusted and respected security team. Hosting your plugin or theme on WordPress.org means anyone can report a security issue directly to [email protected].
I spoke with Matt Cohen, the chief product officer of WooThemes, about dealing with the disclosure of security vulnerabilities. He stressed the importance of being “upfront about how you disclose security issues, and how you wish to receive reports of security issues.”
For him, that means not only having a dedicated email address for security but also following through on promises to keep users updated during the process.
According to Matt,
This involves keeping customers updated as to when you expect to have the issue patched, and progress updates during the patching process, if necessary. Your customer needs to know that you are working on the patch. And if there are any action steps required by the customer (for example, changing their password or upgrading to a specific version of your software), the instructions for the required action should be clearly stated.
Earlier this year, I was working with a user in a support thread for Pods, the free WordPress framework that I work for, when I realized that his issue was really a security vulnerability. The user didn’t even realize that the issue was security related, so I don’t fault him for posting it publicly.
I then deleted the thread and emailed him directly asking him to not discuss it publicly until we’ve patched it.
I won’t go through the entire story of how we went from thinking we had a minor security issue, to realizing how the vulnerability could be used to take over a site, to patching and disclosing it.
What I do want to talk about is the hypothesis we worked under: that if we were honest, open, and personable we would maintain the trust of our users. I’m happy to say that this hypothesis proved itself true, and the overwhelming reaction to admitting to introducing this vulnerability was both positive and supportive.
Being honest and open about a security vulnerability is difficult, as it involves publicly admitting that you made a mistake. However, I believe the most important thing for building and maintaining a user community is relating to your users like a human. When you do, then you can ask for forgiveness for something humans do — make mistakes.
That’s why being personable is such an important part of the equation. The first draft of the post disclosing our vulnerability was written in the third person. We decided to rewrite it in the first person, as a letter from our lead developer Scott Kingsley Clark. The revision was personalized and read like an actual letter from Scott.
Security vulnerability disclosures are, in my opinion, an opportunity to show other developers how to avoid making the same mistake. That’s why in the letter we linked to the commits on GitHub that fixed the issue. Yes, it exposed the vulnerability for all to see, but the software is open source, anyone could have found it.
Hopefully, others learned from the mistake and will avoid making it.
Creating opportunities for users to report security issues responsibly is just as important as working to prevent the issues in the first place. For example, Yoast SEO and Sucuri recently announced a partnership that will include security audits of Yoast’s plugins by Sucuri.
Matt stressed that “Prevention is better than cure — recognizing that this is an important first step towards understanding the importance of security.”
In my opinion, this not only refers to the type of audits that Yoast SEO already does, but also about making sure that our themes and plugins are structured properly so that we don’t inherit the mistakes of other developers. For example, the recent discovery of a security vulnerability in the Revolution plugin was much harder to get patched for all affected users, as many theme developers had decided to include the whole plugin in their themes, instead of adding a plugin installer.
Beyond being smart about dependencies, writing secure code is, of course, the most important thing. The WordPress plugin developer’s handbook section on security is a great place to start. It’s something that all WordPress developers — plugin developer or not — should read.
What do you think is the best way to reduce security vulnerabilities in the WordPress ecosystem, and to encourage responsible disclosure when they happen?