17 Sep 2024

WordPress Plugin Security Review: Two Factor

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 Two Factor. That is also now one of the plugins covered our new Continuous WordPress Plugin Security Review service to identify if updates to plugins have introduced new security issues after we have completed a review of it.

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 0.9.1 of Two Factor. We checked for the following issues during it as part of our standard 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 any of the plugin’s blocks
  • 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 with usage of determine_current_user filter
  • Security issues with usage of the wp_set_current_user(), wp_set_auth_cookie() and wc_set_customer_auth_cookie() functions
  • Security issues with usage of the reset_password() and wp_set_password() 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
  • Existence of register_uninstall_hook or uninstall.php file that removes any WordPress options and database tables added by the plugin
  • 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 two places where security could be improved.

We have reached out to the developer about the lack of proper uninstallation. This is the second review we have completed since we introduced a check for that and the second one lacking a proper uninstall process. That followed another review where that was an issue, which led to us to start checking for that. It is a problem even for some of the most popular plugins.

Lack of Proper Uninstallation

The plugin doesn’t implement one of WordPress’ methods for properly handling uninstalling the plugin. That leads to configuration information for users’ preferred second factor of authentication to be left behind in the WordPress database.

Lack of Protection Against Direct Access to PHP Files

The plugin’s .php files do not have code at the beginning of the files to restrict direct access to them. We didn’t see anything that could be exploited in the files without the restriction in place, but adding the code the plugin already has in other files would make things more secure.

2 thoughts on “WordPress Plugin Security Review: Two Factor

  1. How is “adding the code the plugin already has in other files would make things more secure” if there isn’t anything that can be exploited?

    There’s effectively no inherent logic behind this other than mindlessly following a standard for the sake of doing it. Imagine putting a guard in an empty room. It serves absolutely no purpose.

    It adds burden to the devs, and to people who are not familiar with what it means, it makes them feel as if the developers are doing something wrong when they aren’t.

    • There isn’t anything that could be exploited now. But if the code is changed, there could be.

      We develop plugins. It doesn’t add almost any burden to have at the beginning of files. Adding a couple of lines of code to files doesn’t seem at all equivalent to having a human in an empty room.

      A lot of security doesn’t matter until it does. We are not requiring plugin developers to implement this. We are checking on it during security reviews we do. We have no way to force developers to do anything. So they and anyone else can ignore this if they don’t think it matters.

Leave a Reply to Plugin Vulnerabilities Cancel reply

Your email address will not be published.