17 Nov

The Developers of WordPress Security Plugins Should Be Setting the Example of Good Security Practices

Recently someone left a negative review of the companion plugin for our service, which seemed more like it was just someone looking to bash us than a legitimate review of the plugin (based on another review of theirs they are a paying customer of Wordfence, which explains a lot). The reviewer didn’t even seem to be all that aware of what the plugin did as they said “just tells me that something is bad” or what we do. Part of their review was:

Maybe it’s just the authors continued bashing of every competitor in the security industry that turns me off. Why isn’t the author doing more to help with the security community instead of bashing everyone?

We are not sure if they meant that we should be helping other companies to do their job, but that is how it reads. If that is the case, a better solution seems to be for companies to not to offer to do things they don’t have the capability to do, instead of expecting more capable companies to do their work for them. Beyond that, it isn’t like we can force companies to improve their practices. We can suggest things, but others have to choose if they want to be setting an example of what to do instead of what not to do.

An example of where a company in the security industry is not following advice we have given comes from an unfixed reflected cross-site scripting (XSS) vulnerability that has been disclosed in the plugin Appointments, which was discovered by Ricardo Sanchez. That plugin is developed by WPMU DEV, who also makes the Defender security plugin. They also promote their plugins as:

Guaranteed to work, always updated, top quality plugins. Beautifully coded, packed with features, and easy to use.

When we went to look at the underling code causing that so that we could provide a suggested solution when we notified WPMU DEV of the disclosure (we actually can help other security companies as well as pointing out the problems with them), we noticed that file probably shouldn’t have been included with the plugin.

The file is a test file that comes with a third-party library, which isn’t hard to spot based on the directories it is inside of: /bower_components/jquery-ui-multiselect-widget/tests/visual/formsubmission.php

After spotting an issue just like this during a security review we wrote a Security Tip for Developers post back in April titled Remove Testing Files from Third Party Libraries Included in Your Plugin.

Leave a Reply

Your email address will not be published. Required fields are marked *