Before we start using a new WordPress plugin on our website, we do a security review of it, which led to us doing one for GN Publisher.

If you want a security review of plugins you use, when you become a paying customer of our service, you can start suggesting and voting on plugins to get security reviews from us. For those already using the service that haven’t already suggested and voted for plugins to receive a review, you can start doing that here. You can use our tool for doing limited automated security checks of plugins to see if plugins you are using have possible issues that would make them good candidates to get a review. You can also order a review of a plugin separately from our main service.

The review was done on version 1.5.1 of GN Publisher. We checked for the following issues during this review:

• Insecure file upload handling (this is the cause of the most exploited type of vulnerability, arbitrary file upload)
• Deserialization of untrusted data
• Security issues with functions accessible through WordPress’ AJAX functionality (those have and continued to be a common source of disclosed vulnerabilities)
• Security issues with functions accessible through WordPress’ REST API (those have started to be a source of disclosed vulnerabilities)
• Persistent cross-site scripting (XSS) vulnerabilities in the frontend portions of the plugin and in the admin portions accessible to users with the Author role or below
• Cross-site request forgery (CSRF) vulnerabilities in the admin portion of the plugin
• SQL injection vulnerabilities (the code that handles requests to the database)
• Reflected cross-site scripting (XSS) vulnerabilities
• Security issues with functions accessible through any of the plugin’s shortcodes
• Security issues with functions accessible through the admin_action action
• Security issues with functions accessible through the admin_init action
• Security issues with functions accessible through the admin_post action
• Security issues with import/export functionality
• Security issues with usage of the is_admin() function
• Security issues with usage of the add_option(), delete_option(), and update_option() functions
• Security issues with usage of the update_user_meta() and wp_update_user() functions
• Security issues with usage of the extract() function
• Lack of IP address validation
• Proper usage of sanitize_callback when using register_setting() to register settings.
• CSV injection
• Host header injection vulnerabilities
• Lack of protection against unintended direct access of PHP files
• Insecure and unwarranted requests to third-party websites
• Any additional possible issues identified by our Plugin Security Checker

Results

We found the plugin contained a minor vulnerability and several places where security could be improved, which are detailed below. The developer released version 1.5.2, which addresses the vulnerability, but didn’t address the other issues.

Missing Nonce Check and Capabilities Checks

One AJAX accessible function in the plugin lacked a nonce check to prevent cross-site request forgery (CSRF). Based on what is accessible through that, that doesn’t seem to be a big concern. The function was gnpub_send_feedback() in the file /includes/mb-helper-function.php.

That was addressed by checking for a valid nonce (and sending a valid nonce when the plugin is accessing it):

52
53
54
55
56
57
58
59

function gnpub_send_feedback() {
 
    if ( ! isset( $_POST['gn_security_nonce'] ) ){
        return; 
    }
    if ( !wp_verify_nonce( $_POST['gn_security_nonce'], 'gn-pub-nonce' ) ){
    return;  
    }

What wasn’t addressed is a lack of capabilities check to restrict what users have access to that function and another AJAX accessible function in the same file, gn_send_query_message().

The nonce check would normally restrict access to both of those functions, as access to the nonce is limited, but that isn’t its intended role, as mentioned in the WordPress documentation for that.

Lack of Protection Against Direct Access to PHP Files

Most of the plugin’s .php files that didn’t appear to be intended to be directly accessed contained protection against direct access, but two others were missing that. We didn’t see anything that could be exploited in the files without the restriction in place, but restricting access to them would ensure that there isn’t any issue with that.