WordPress Coding Standards is Failing to Warn About Missing Sanitization and Requiring Unnecessary Sanitization

One of the things that our new Plugin Security Scorecard uses to grade the security of WordPress plugins is a subset of the checks from our Plugin Security Checker. The subset is intended to be things that are always a security issue, which should be addressed. While the full set of checks will flag things that could be secure, but often are not secure and need to be checked. That subset involves checking for things you would expect to be issues with certain types of plugins and from certain developers. But the actual results of plugins checked so far tell a different story.

The 5+ million install plugin Wordfence Security has been found to be using “[t]he function filter_input() is used without a filter, so it doesn’t do any filtering.” Similarly, the 100,000+ install Jetpack Protect plugin is found to be using “[t]he function filter_var() is used without a filter, so it doesn’t do any filtering.” That plugin is from Automattic, the company so closely associated with WordPress that it now is not uncommon for WordPress to be seen as an arm of the company. That isn’t the only plugin from Automattic with issues. With the 4+ million install Jetpack and 7+ million install WooCommerce have been found to have both the previously mentioned issues. The threat posed by that would depend on what is done after the filter-less filtering is done, but the filter-less filtering shouldn’t be happening even if there isn’t a larger issue.

So what is going on here? The answer looks to be plugin developers relying on an automated tool that is misrepresented as more of a security solution than it really is, while failing to do the kind of manual security reviews that are needed for widely used plugins, especially for security and eCommerce plugins.

Based on a vulnerability we ran across in WooCommerce in June, it appears that there hasn’t been a security review of WooCommerce done in over four years. Instead of Automattic spending money on having that done, they have been funding PHP CodeSniffer, which along with the related WordPress Coding Standards, gets misrepresented being as much more of a security solution than the coding standards checker it is. They have so far funded that to the tune of $45,000, which would have paid for a lot of security reviews.

The problem of that tool not warning about those two issues in plugins has long been known about. It was warned about in January 2016 and has subsequently brought up multiple additional times, but never addressed.

Unneeded Sanitization wp_verify_nonce()

On the flip-side is the strange situation that is wasting a lot of developer time by the tool requiring that sanitization be done when it isn’t needed. That involves the function wp_verify_nonce(), which is used to verify nonces to prevent cross-site request forgery (CSRF). That problem was raised in July 2017, but still hasn’t been resolved. There is a thorough explanation of why that isn’t need that can be found here.

If there really were sanitization needed when using that function, then WordPress itself has a problem, as WordPress doesn’t do any sanitization when using that function. For example, here is its usage in the file /wp-admin/includes/ajax-actions.php:

3461	$nonce_state = wp_verify_nonce( $_POST['_nonce'], 'heartbeat-nonce' );

3976	} elseif ( ! wp_verify_nonce( $_POST['nonce'], 'update-user_' . $user->ID ) ) {

By comparison, the first of those would like this with the code required by that tool:

3461	$nonce_state = wp_verify_nonce( sanitize_text_field( wp_unslash( $_POST['_nonce'] ) ), 'heartbeat-nonce' );

That misinformation about sanitizing when using that function has bled on to the Word Press Developer Blog, which doesn’t appear to be written by the developers of WordPress, considering they clearly disagree with this misinformation.

When we politely suggested that the developers of that tool should be clearly laying out the limitations when it comes to its usage for security checking, because of a clear misunderstanding of what it is capable of. The response we got from someone involved in developing them, who works for Automattic, was to not take that advice. Instead, it was to say that we should fix the problem for them. Which we can’t, since it is outside the scope of what the tool can possibly do. (They also claimed the developers are volunteers, despite key members getting paid for the work and demanding more money.)

The lack of concern with the WordPress Coding Standards extends to not having a security policy.

For those looking to verify the security of WordPress plugins, the best option would be a good security review. You can also look for other options, like our Plugin Security Scorecard, where there is a focus on providing accurate security assessments.