WordPress Plugin Security Review: Query Monitor
For our 29th security review of a WordPress plugin based on the voting of our customers, we reviewed the plugin Query Monitor.
If you are not yet a customer of the service, once you sign up for the service as a paying customer you can start suggesting and voting on plugins to get security reviews. 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 service.
The review was done on version 3.3.4 of Query Monitor. 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 import/export functionality
- Security issues with usage of is_admin()
- Security issues with usage of add_option(), delete_option(), and update_option()
- 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 one really minor issue.
Lack of Protection Against Direct Access to PHP Files
Many of the plugin’s .php files that don’t appear to be intended to be directly accessed do not contain protection against direct access. We didn’t see anything that could be exploited in the files without the restriction in place.
I wish you’d stop calling direct access to .php files, when there’s nothing exploitable (even when that is noted) an issue (even if a “really minor issue”).
WP core already contains several such files. A genuine vulnerability/issue involves escalation of privilege; the ability to do something not possible before.
A vulnerability and an issue are two very different things. We refer to it as an issue, since we have seen vulnerabilities that were exploited due to the lack of that code, which would have been avoided if that code was in place. Part of the point of our reviews is to check for potential security issues, even if they don’t lead to vulnerabilities, because from looking at widely exploited vulnerabilities they often involve security issues that predate the vulnerable code being added.
We would say that if don’t like what we include in our reviews then don’t use our service, but the email address listed with this comment isn’t even tied to an account with our service.