Shulou(Shulou.com)05/31 Report--

This article editor for you a detailed introduction of the "WordPress plug-in WooCommerce arbitrary file deletion vulnerabilities how to solve", detailed content, clear steps, details handled properly, I hope that this "WordPress plug-in WooCommerce arbitrary file deletion vulnerabilities how to solve" article can help you solve doubts, the following follow the editor's ideas slowly in-depth, together to learn new knowledge.

Technical details

The permission handling mechanism of WordPress is mainly realized by providing different functions to different roles. When the store administrator role is defined, it will assign the edit_users function to this role, so that they can directly manage the customer accounts of the store. The whole permission allocation process takes place during the installation of the plug-in. Woocommerce/includes/class-wc-install.php:

/ / Shop manager role.add_role ('shop_manager', / / Internal name of the new role' Shop manager', / / The label for displaying array (/ / Capabilities ⋮'read_private_posts' = > true,' edit_users' = > true) 'edit_posts' = > true, ⋮))

Role permission information is stored in the database with WordPress core settings, which means that user roles are now independent of the plug-in, and even if the plug-in is not enabled, it will not affect the relevant role permissions.

When an authenticated user tries to modify other user information, the current_user_can () function is called, and then ensures that only privileged users can do so. Sample call to the current_user_can () function:

$target_user_id= $_ GET ['target_user_id']; if (current_user_can (' edit_user',$target_user_id)) {edit_user ($target_user_id);}

The authentication logic of the call is as follows: if this user wants to use the $target_user_id ID to modify a specific user, does he have permission to execute it?

By default, the edit_users feature allows authorized users (such as store administrators) to edit other users, or even administrator users, and then perform operations such as password updates. For security reasons, WooCommerce needs to specify whether the store administrator can edit users, so the plug-in needs to add meta permissions. The Meta function can be called by current_user_can (). The value returned by the function under the default behavior is true, but the value returned by the meta permission function determines whether the current user can perform such an operation. The following is the abstract function code for the WooCommerce meta permission filter:

Function disallow_editing_of_admins ($capability, $target_user_id) {/ / If the user is an admin return false anddisallow the action if ($capability = = "edit_user" & & user_is_admin ($target_user_id)) {return false;} else {return true;}} add_filter ('map_meta_cap',' disallow_editing_of_admins')

For example, when current_user_can ('edit_user', 1) is called, the filter will determine whether the user whose ID is 1 ($target_user_id) is an administrator and decide whether to allow the user to operate based on the result.

Store administrator disables plug-ins

By default, only administrators can disable plug-ins. But this vulnerability allows store administrators to delete any writable file on the server, so we can disable WooCommerce from loading the plug-in by deleting WordPress's master file, woocommerce.php.

This file deletion vulnerability exists in WooCommerce's logging function, which is stored in the wp-content directory as a .log file. When the store administrator wants to delete the log file, he needs to submit the file name with the GET parameter. The code snippet shown below is the part of the vulnerability:

Woocommerce/includes/admin/class-wc-admin-status.phpclass WC_Admin_Status {public static function remove_log () {⋮$log_handler = newWC_Log_Handler_File (); $log_handler- > remove (wp_unslash ($_ REQUEST ['handle'])) } woocommerce/includes/log-handlers/class-wc-log-handler-file.phpclass WC_Log_Handler_File extends WC_Log_Handler {public function remove ($handle) {⋮$file = trailingslashit (WC_LOG_DIR). $handle; ⋮unlink ($file)

The problem here is that the file name ($handle) is added to the log directory (wp-content/wc-logs/) and passed to the unlink () function. When setting "$handle../../plugins/woocommerce-3.4.5/woocommerce.php", the file wp-content/wc-logs/../../plugins/woocommerce-3.4.5/woocommerce.php will be deleted, causing WooCommerce to be disabled.

Read here, the "WordPress plug-in WooCommerce arbitrary file deletion vulnerabilities how to solve" article has been introduced, want to master the knowledge of this article also need to practice and use to understand, if you want to know more about the article, welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.