For our seventh security review of a plugin based on the voting of our customers, we reviewed the plugin BackUpWordPress.
If you are not yet a customer of the service you can currently try it free for your first month and then start suggesting and voting on plugins to get security reviews after your first payment for the service. For those already using the service that haven’t already suggested and voted for plugins you can start doing that here.
The review was done on version 3.6.3.1 of BackUpWordPress. We checked for the following issues:
- 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 are a common source of disclosed vulnerabilities these days)
- Persistent cross-site scripting (XSS) vulnerabilities in publicly accessible portions of the plugin
- Cross-site request forgery (CSRF) vulnerabilities in the admin portion of plugins
-
SQL injection vulnerabilities (the code that handles requests to the database)
-
Reflected cross-site scripting (XSS) vulnerabilities
-
Lack of protection against unintended direct access of PHP files
Results
During the review we only found one minor issue:
Lack of Protection Against Direct Access to Files
Numerous .php files that look like they are not intended to be accessed directly are lacking code at the beginning of the file to restrict direct access to the files. In the files we looked over we only found one minor issue, one of the files causes a full path disclosure vulnerability. That provides the full path to web sites’s location on the server’s filesystem. On its own that can’t be used to do anything, but it could be combined with vulnerability that requires knowing that information or in the case of cPanel based websites it would provide an attacker with the username for cPanel.
Unlike most full path disclosure vulnerabilities in plugins, this one would occur on servers where PHP’s error reporting is not set to show them since the file in question, /vendor/ifsnop/mysqldump-php/tests/test.php, enables all error reporting (which would override the normal setting for that):
What we also noticed about this is that the file is a testing file for a third party library, which didn’t look to be needed to be included with the plugin. It was in one of two test directories included with third party libraries that come with the plugin.
When we contacted the plugin’s maker about this we were told that the developers had been touched based with about it and “they plan to get this taken care of right away”. Several days after that an issue was started on the GitHub page for the plugin and then was closed and redacted a couple days after that. A month later the plugin hasn’t received any updates, so the issue remains in it for now.