Comment résoudre la vulnérabilité de suppression arbitraire de fichiers dans le plugin WordPress WooCommerce

Détails techniques

Le mécanisme de traitement des autorisations de WordPress est principalement mis en œuvre en fournissant différentes fonctions à différents rôles. Lorsque le rôle d'administrateur de magasin est défini, il attribuera la fonction edit_users à ce rôle afin qu'ils puissent gérer directement le compte client de la boutique. . L'ensemble du processus d'attribution des autorisations se produit pendant le processus d'installation du 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,                ⋮       ));

Les informations d'autorisation du rôle seront stockées dans la base de données avec les paramètres de base de WordPress, ce qui signifie que le rôle de l'utilisateur est désormais indépendant du plugin, même si le plugin n'est pas activé , cela n'affectera pas les autorisations de rôle pertinentes.

Lorsqu'un utilisateur authentifié tente de modifier d'autres informations utilisateur, la fonction current_user_can() est appelée et garantit ensuite que seuls les utilisateurs privilégiés peuvent effectuer cette opération. Exemple d'appel de fonction Current_user_can() :

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

La logique de vérification de l'appel est la suivante : Cet utilisateur souhaite utiliser l'ID $target_user_id pour modifier un utilisateur spécifique. A-t-il l'autorisation d'exécuter ?

Dans la configuration par défaut, la fonction edit_users permet aux utilisateurs disposant d'autorisations (telles que les administrateurs de magasin) de modifier d'autres utilisateurs, même les utilisateurs administrateurs, puis d'effectuer des opérations telles que des mises à jour de mots de passe. Pour des raisons de sécurité, WooCommerce doit spécifier si l'administrateur du magasin peut modifier les utilisateurs, le plug-in doit donc ajouter des méta-autorisations. Les méta-fonctions peuvent être appelées par current_user_can(). La valeur renvoyée par la fonction sous le comportement par défaut est vraie, mais la valeur renvoyée par la fonction de méta-autorisation peut déterminer si l'utilisateur actuel peut effectuer une telle opération. Vous trouverez ci-dessous le code de fonction abstraite du filtre de méta-autorisation WooCommerce :

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');

Par exemple, lorsque current_user_can('edit_user', 1) est appelé, le filtre déterminera si l'utilisateur avec l'ID 1 ($target_user_id) est l'administrateur décide si pour permettre à l'utilisateur d'opérer en fonction des résultats.

Plugins désactivés par l'administrateur du magasin

Par défaut, seuls les administrateurs peuvent désactiver les plugins. Cependant, cette vulnérabilité permet aux administrateurs du magasin de supprimer tout fichier inscriptible sur le serveur. Nous pouvons donc empêcher WordPress de charger le plug-in en supprimant le fichier principal de WooCommerce, woocommerce.php.

Cette vulnérabilité de suppression de fichiers existe dans la fonction de journalisation de WooCommerce. Les journaux seront stockés dans le répertoire wp-content sous forme de fichiers .log. Lorsque l'administrateur du magasin souhaite supprimer un fichier journal, il doit soumettre le nom du fichier en tant que paramètre GET. L'extrait de code ci-dessous est la partie vulnérable :

woocommerce/includes/admin/class-wc-admin-status.php

class 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.php

class WC_Log_Handler_File extends WC_Log_Handler{    public function remove($handle)    {    ⋮        $file = trailingslashit(WC_LOG_DIR) .$handle;    ⋮unlink($file);

Le problème ici est que le nom du fichier ($handle) sera ajouté au répertoire des journaux (wp-content/wc-logs/) puis transmis à la fonction unlink(). Lors de la configuration de "$handle../../plugins/woocommerce-3.4.5/woocommerce.php", fichier wp-content/wc-logs/../../plugins/woocommerce-3.4.5/woocommerce php. sera supprimé et entraînera la désactivation de WooCommerce.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!