Since we introduced our Plugin Security Checker, which does limited automated security checks of WordPress plugins, in late October we have had a lot of interest in that and it has brought in additional business for both our main service and our separate security reviews. That is good for us, but also for everyone using WordPress as it allows us to do more to improve the security of WordPress plugins (which it looks like we already doing much more than anyone else).

One of the things there has been a lot of interest by users of the tool involves an area of plugin security that we hadn’t really considered in the past, custom plugins. Unlike plugins in the Plugin Directory where they can be checked for a particular issues en masse by anyone (with the ability to handle the results being limited by the amount of time it would take to contact the developers and possibly work with them to fix the issues) or even commercial plugins that can be checked to some extent by outside parties, custom plugins can’t take advantage of that. With our tool, custom plugins can get closer to that kind of checking, while also helping to improve the security of publicly available plugins as the capability to check plugins in the Plugin Directory is freely available, while checking plugins not in it requires using our service.

While the added business gives us additional incentive to further improve the tool, we would have been making the improvements that have been made since its introduction even if that wasn’t the case. Below is an update on what we have been doing recently in that regard.

New and Improved Checks

As we are adding newly disclosed vulnerabilities in plugins to the data set of our main service we have been looking to see if it makes sense to add a check for those issues or to tweak existing checks to spot those issues as well. We also have been looking at how we can incorporate checks for more serious issues found in plugins in the past since those would be among those of the most concern if found in another plugin. As an example of that, after our recent posting about how thousands of websites are still using a plugin with an unfixed option update vulnerability more than a year after it started being targeted, we added a new check for that issue.

At the same time we have been working to reduce the number of instances where the tool produces false positives (which based on our testing are already pretty low) and also to reduce some instances where the tool is correctly identifying something that could lead to a security issue but where we can detect in an automated fashion that the particular usage is harmless.

Developer Mode

Back when we announced the tool we mentioned that we were looking to add to the tool the ability for customers of our service to see the details of what lead to the tool identifying a possible issue. Subsequently, we have had some customer interest in that. As part of work for something else that we will be announcing soon, we have added that and made those accessible as part of what we are calling the Developer Mode for the time being. As the name implies that is focused on things that would useful to developers of plugins, like say those custom plugins, but also would useful to security professionals.  That mode, which requires you to be a customer of the service to access, currently introduces two additional features to the tool.

The first being that you can see the details of possible issues identified by the tool. We are still working on how those are displayed (we are already added syntax highlighting), but that currently looks like this for a possible reflected cross-site scripting (XSS) issue:

Any feedback on further changes to the display of that information is welcome.

The second feature adds additional checks that while they can be useful, also are more likely to flag harmless code, so flagging them for the general public has more downside. The first of those checks is something that was previously included in the standard checks, but based on the results we were seeing, we were considering removing from the tool before coming up with the idea of the Developer Mode. That is a check for usage of variables that can lead host header injection, which has been an issue with the core WordPress software. While it is easy to identify those, a lot of the usage is probably harmless even if they are being used when there is a better option. The second check is for usage of the function create_function(), which is something we discussed before. The final one is a check for instances where the result of a SQL query is passed to the function unserialize(), which can lead to PHP object injection in certain instances and has been claimed to be something hackers are exploiting (though some of the evidence of that seems questionable), so usage should be scrutinized to make sure there is no chance of that and that security has been properly implemented in the code.

More Coming

In continuing to improve the tool we are looking out how we can leverage other things we can do to improve the tool and how the tool can be used to improve other things we do (the breadth of what we do sets us apart from other companies in the field). We have now included checking over any possible issue identified by the tool into our security reviews and we are looking at additions to the tool based on things that can be automated and that have been on the drawing board for future enhancements to those security reviews.

We have a number of new features currently being worked on, including providing information that could assist in more quickly identifying some instances of plugins containing intentionally malicious code.

If you have any ideas for further enhancements you would be interested in please leave a comment below or contact us.