WordPress の権限処理メカニズムは、主にロールごとに異なる機能を提供することで実装されています。ストア管理者のロールが定義されると、このロールに edit_users 関数が割り当てられ、ストア管理者ができるようになります。ストアの顧客アカウントを直接管理します。権限の割り当てプロセス全体は、プラグインのインストール プロセス中に行われます。 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, ⋮ ));
ロール権限情報は WordPress コア設定としてデータベースに保存されます。つまり、ユーザー ロールはプラグインから独立しています。プラグインは有効になっていないため、関連するロールの権限には影響しません。
認証されたユーザーが他のユーザー情報を変更しようとすると、 current_user_can() 関数が呼び出され、特権ユーザーのみがこの操作を実行できるようにします。 Current_user_can() 関数呼び出しの例:
$target_user_id= $_GET['target_user_id'];if(current_user_can('edit_user',$target_user_id)) { edit_user($target_user_id);}
呼び出しの検証ロジックは次のとおりです: このユーザーは、ID $target_user_id を使用して特定のユーザーを変更したいと考えています。実行する権限を持っていますか?
デフォルト設定では、edit_users 関数により、権限を持つユーザー (ストア管理者など) が他のユーザー (管理者ユーザーであっても) を編集し、パスワード更新などの操作を実行できます。セキュリティ上の理由から、WooCommerce ではストア管理者がユーザーを編集できるかどうかを指定する必要があるため、プラグインはメタ権限を追加する必要があります。メタ関数は current_user_can() によって呼び出すことができます。デフォルトの動作で関数によって返される値は true ですが、メタ権限関数によって返される値によって、現在のユーザーがそのような操作を実行できるかどうかが決まります。以下は、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');
たとえば、current_user_can('edit_user', 1) が呼び出されるとき、フィルターは ID が 1 ($target_user_id) であると判断します。ユーザーは管理者であり、その結果に基づいてユーザーに操作を許可するかどうかを決定します。
デフォルトでは、管理者のみがプラグインを無効にできます。ただし、この脆弱性により、ストア管理者はサーバー上の書き込み可能なファイルを削除できるため、WooCommerce のメイン ファイル woocommerce.php を削除することで、WordPress がプラグインを読み込まないようにすることができます。
このファイル削除の脆弱性は WooCommerce のログ機能に存在し、ログは .log ファイルの形式で wp-content ディレクトリに保存されます。ストア管理者がログ ファイルを削除したい場合は、ファイル名を GET パラメータとして送信する必要があります。以下に示すコード スニペットは脆弱な部分です:
class WC_Admin_Status{ public static function remove_log() { ⋮ $log_handler = newWC_Log_Handler_File(); $log_handler->remove(wp_unslash($_REQUEST['handle']));}
class WC_Log_Handler_File extends WC_Log_Handler{ public function remove($handle) { ⋮ $file = trailingslashit(WC_LOG_DIR) .$handle; ⋮unlink($file);
ここでの問題は、ファイル名 ($handle) がログ ディレクトリ (wp-content/wc-logs/) に追加され、その後 unlink() に渡されることです。関数。 「$handle../../plugins/woocommerce-3.4.5/woocommerce.php」を設定する場合、ファイル wp-content/wc-logs/../../plugins/woocommerce-3.4.5/woocommerce.php削除され、WooCommerce が無効になります。
以上がWordPressプラグインWooCommerceにおける任意のファイル削除の脆弱性を解決する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。