آسیب‌پذیری وردپرس: کلاس‌های واقعی نقص در افزونه و قالب

این مقاله همتای فنی امنیت وردپرس است: به‌جای فهرست اقدامات، کلاس‌های واقعی آسیب‌پذیری وردپرس را می‌شکافد — آن الگوهایی که در کد افزونه‌ها و قالب‌ها تکرار می‌شوند و بیشترین سهم را در نفوذ به سایت‌های وردپرسی دارند. برای هر کلاس سه چیز را می‌گوییم: الگوی کدی که مشکل را می‌سازد، روش کشف آن در تست نفوذ، و اصلاح درست. مخاطب این متن هم توسعه‌دهنده‌ای است که افزونه یا قالب می‌نویسد و هم مدیر سایتی که می‌خواهد بداند دقیقاً به دنبال چه چیزی باشد.

چرا این نقص‌ها در اکوسیستم وردپرس تکرار می‌شوند

سه ویژگی معماری وردپرس، الگوی خطاها را شکل می‌دهد و شناختن آن‌ها باعث می‌شود بدانید کجا را بگردید:

• هوک‌ها دسترسی را کنترل نمی‌کنند. ثبت یک تابع روی wp_ajax_nopriv_* یا register_rest_route() فقط می‌گوید «این تابع را روی این درخواست اجرا کن». هیچ بررسی مجوزی به‌صورت خودکار انجام نمی‌شود؛ این وظیفه‌ی خودِ توسعه‌دهنده است.
• سیستم قابلیت‌ها (capabilities) قدرتمند اما اختیاری است. current_user_can() باید صریحاً فراخوانی شود. فراموش کردنش هیچ خطایی تولید نمی‌کند و افزونه کاملاً کار می‌کند — تا وقتی کسی آن را آزمایش کند.
• nonce با مجوز اشتباه گرفته می‌شود. wp_verify_nonce() در برابر CSRF محافظت می‌کند، نه در برابر دسترسی غیرمجاز. کاربر با سطح پایین هم می‌تواند nonce معتبر داشته باشد. این دو بررسی مکمل‌اند و هر دو لازم‌اند.

نتیجه‌ی این سه ویژگی: بخش بزرگی از آسیب‌پذیری‌های افزونه‌ها نه «باگ‌های پیچیده» بلکه بررسی‌های جاافتاده هستند. همین باعث می‌شود هم بسیار رایج باشند و هم بسیار ساده قابل رفع.

کنترل دسترسی شکسته در اندپوینت‌های AJAX و REST

پرتکرارترین کلاس، و ریشه‌ی بسیاری از موارد دیگر. الگو ساده است: افزونه یک عملیات حساس را روی یک اندپوینت قرار می‌دهد و فراموش می‌کند بررسی کند چه کسی آن را صدا زده است.

الگوی معیوب در AJAX

add_action( 'wp_ajax_myplugin_save', 'myplugin_save' );
add_action( 'wp_ajax_nopriv_myplugin_save', 'myplugin_save' ); // بدون احراز هویت!

function myplugin_save() {
    update_option( 'myplugin_settings', $_POST['settings'] );
    wp_send_json_success();
}

سه ایراد هم‌زمان: ثبت روی nopriv که کاربر ناشناس را هم راه می‌دهد، نبود current_user_can()، و نبود بررسی nonce. اصلاح درست:

function myplugin_save() {
    if ( ! current_user_can( 'manage_options' ) ) {
        wp_send_json_error( null, 403 );
    }
    check_ajax_referer( 'myplugin_save' );
    update_option( 'myplugin_settings', sanitize_text_field( $_POST['settings'] ) );
    wp_send_json_success();
}

الگوی معیوب در REST

در REST API معادل همین خطا، مقدار 'permission_callback' => '__return_true' است. این عبارت یعنی «هر کسی مجاز است» و در اندپوینتی که داده می‌نویسد یا اطلاعات حساس برمی‌گرداند، مستقیماً یک آسیب‌پذیری است. permission_callback باید قابلیت واقعی مورد نیاز را بررسی کند.

روش کشف در تست نفوذ

• فهرست همه‌ی اکشن‌های AJAX را از سورس جاوااسکریپت افزونه و از کد PHP استخراج کنید.
• مسیرهای REST را از /wp-json/ فهرست کنید.
• هر اندپوینت را سه بار صدا بزنید: بدون احراز هویت، با کاربر کم‌دسترس (مشترک)، و با مدیر. اختلاف پاسخ‌ها همان یافته است. این همان روش استاندارد آزمون کنترل دسترسی است که در دانشنامه شرح داده‌ایم.
• به عملیات نوشتن دقت ویژه کنید؛ بسیاری از افزونه‌ها در GET بررسی دارند و در POST ندارند.

ارتقای سطح دسترسی بدون احراز هویت

شدیدترین کلاس آسیب‌پذیری در اکوسیستم وردپرس. مهاجم بدون داشتن هیچ حسابی — یا با یک حساب مشترک عادی — به سطح مدیر می‌رسد. از آنجا به بعد، ویرایشگر فایل، نصب افزونه و اجرای کد در دسترس است.

الگوهای رایجی که این را می‌سازند

• به‌روزرسانی پروفایل بدون فیلتر فیلد نقش. افزونه فرم ثبت‌نام یا ویرایش پروفایل می‌سازد و کل آرایه‌ی ورودی را به wp_update_user() یا wp_insert_user() می‌دهد. اگر مهاجم فیلد role را اضافه کند و افزونه آن را حذف نکرده باشد، خودش را مدیر می‌کند. این همان الگوی Mass Assignment است.
• تنظیم نقش پیش‌فرض ثبت‌نام از سمت کلاینت. افزونه‌ای که نقش کاربر جدید را از پارامتر درخواست می‌خواند.
• به‌روزرسانی متای کاربر بدون فهرست سفید. نوشتن دلخواه در wp_usermeta می‌تواند به نوشتن روی کلید قابلیت‌ها منجر شود.
• توابع بازنشانی رمز یا ورود خودکار که توکن را به‌درستی راستی‌آزمایی نمی‌کنند یا برای هر شناسه‌ی کاربری کار می‌کنند.
• اندپوینت نصب یا پیکربندی اولیه که پس از نصب غیرفعال نمی‌شود و هر کسی می‌تواند دوباره اجرایش کند.

اصلاح

• هرگز نقش و قابلیت را از ورودی کاربر نگیرید. نقش را در سمت سرور و بر پایه‌ی منطق برنامه تعیین کنید.
• در به‌روزرسانی پروفایل، فقط فیلدهای مشخص و مجاز را از ورودی بردارید (فهرست سفید صریح)، نه اینکه فیلدهای خطرناک را حذف کنید (فهرست سیاه).
• هر تغییر نقش را با current_user_can( 'promote_users' ) محافظت کنید.
• اسکریپت‌های نصب و پیکربندی را پس از اجرا غیرفعال یا حذف کنید — این مورد زیر A02:2025 پیکربندی نادرست هم قرار می‌گیرد.

توضیح مفهومی این کلاس را در دانشنامه‌ی ارتقای سطح دسترسی آورده‌ایم.

آپلود فایل دلخواه و مسیر رسیدن به اجرای کد

کلاسیک‌ترین مسیر از «یک نقص در افزونه» تا «کنترل کامل سرور». مکانیزم: افزونه‌ای امکان آپلود می‌دهد و نوع فایل را به‌درستی بررسی نمی‌کند؛ مهاجم یک فایل PHP آپلود می‌کند و سپس مستقیماً آن را در مرورگر باز می‌کند.

اشتباهات رایج در اعتبارسنجی

• اعتماد به $_FILES['file']['type']. این مقدار را کلاینت می‌فرستد و کاملاً قابل جعل است.
• بررسی پسوند با فهرست سیاه. فهرست سیاه همیشه ناقص است؛ پسوندهای جایگزینی که وب‌سرور ممکن است اجرا کند فراموش می‌شوند.
• اعتماد به بررسی سمت کلاینت. اعتبارسنجی جاوااسکریپتی با یک درخواست مستقیم دور زده می‌شود.
• بررسی محتوای فایل بدون بررسی پسوند نهایی. فایلی می‌تواند هدر یک تصویر معتبر داشته باشد و در ادامه‌اش کد PHP.
• حفظ نام فایل ارسالی کاربر، که به پیمایش مسیر و بازنویسی فایل‌های دیگر راه می‌دهد.

اصلاح، به ترتیب اثربخشی

1. از wp_handle_upload() و wp_check_filetype_and_ext() استفاده کنید و به فیلترهای وردپرس برای انواع مجاز تکیه کنید، به‌جای نوشتن منطق اختصاصی.
2. فهرست سفید صریح برای پسوند و نوع MIME واقعی (تشخیص از محتوا، نه از هدر ارسالی).
3. نام فایل را خودتان تولید کنید — تصادفی و بدون هیچ بخشی از ورودی کاربر.
4. اجرای PHP را در مسیر آپلود غیرفعال کنید. این تنها لایه‌ای است که حتی اگر همه‌ی بررسی‌ها شکست بخورند، فایل آپلودشده را از تبدیل شدن به اجرای کد بازمی‌دارد. برای هر سایت وردپرسی توصیه می‌شود، حتی اگر فکر می‌کنید آسیب‌پذیری ندارید.
5. بررسی مجوز قبل از آپلود: چه کسی حق آپلود دارد و در چه محدوده‌ای.

توجه: آپلود .htaccess یا فایل پیکربندی هم باید مسدود شود، چون می‌تواند رفتار وب‌سرور را در آن پوشه تغییر دهد.

تزریق SQL در کوئری‌های افزونه

وردپرس با $wpdb ابزار درستی در اختیار گذاشته، اما استفاده از آن اجباری نیست و همین‌جاست که مشکل ساخته می‌شود.

الگوی معیوب

// آسیب‌پذیر — الحاق مستقیم ورودی به کوئری
$id = $_GET['order_id'];
$row = $wpdb->get_row( "SELECT * FROM {$wpdb->prefix}orders WHERE id = $id" );

// درست — جداسازی داده از دستور
$row = $wpdb->get_row( $wpdb->prepare(
    "SELECT * FROM {$wpdb->prefix}orders WHERE id = %d", $_GET['order_id']
) );

نکته‌ای که معمولاً گفته نمی‌شود

$wpdb->prepare() فقط مقادیر را پارامتری می‌کند. نام جدول، نام ستون و جهت مرتب‌سازی قابل پارامتری‌سازی نیستند. اگر افزونه‌ی شما مرتب‌سازی پویا دارد (ORDER BY $column $direction)، پارامتری‌سازی کمکی نمی‌کند و باید از فهرست سفید استفاده کنید: ورودی کاربر را به یک نگاشت ثابت از نام‌های مجاز تبدیل کنید و اگر در فهرست نبود، مقدار پیش‌فرض بگذارید. همین نکته دقیقاً همان چیزی است که در دانشنامه‌ی تزریق SQL با جزئیات آمده است.

نقاط پرخطر برای جست‌وجو

• فیلترها و جست‌وجوهای سفارشی که ورودی کاربر را به شرط WHERE تبدیل می‌کنند.
• صفحات گزارش‌گیری در پنل مدیریت — اغلب کمتر بازبینی می‌شوند چون «فقط مدیر به آن دسترسی دارد» (که با نقص کنترل دسترسی نقض می‌شود).
• تزریق مرتبه‌دوم: مقداری که در نوشتن پارامتری بوده اما در خواندن الحاق می‌شود.
• کوئری‌های meta_query با کلیدهای پویا.

XSS ذخیره‌شده در متا، گزینه‌ها و پنل مدیریت

وردپرس توابع پاکسازی و کدگذاری خوبی دارد؛ مشکل، استفاده نکردن یا استفاده‌ی نادرست از آن‌هاست. دو خطای متقارن:

• پاکسازی هنگام ذخیره اما نه کدگذاری هنگام نمایش. پاکسازی و کدگذاری یک چیز نیستند: پاکسازی محتوای نامعتبر را حذف می‌کند، کدگذاری داده را متناسب با زمینه‌ی خروجی بی‌خطر می‌کند.
• استفاده از تابع نامتناسب با زمینه. خروجی در متن HTML، در مقدار یک صفت، در URL، و در بلوک جاوااسکریپت هر کدام تابع خودشان را دارند: esc_html()، esc_attr()، esc_url()، esc_js() و wp_kses() برای HTML محدود.

نقاط تزریق پرتکرار

• گزینه‌های افزونه در پنل تنظیمات که بدون کدگذاری در فرم بازنمایش می‌شوند.
• متای نوشته و متای کاربر که در قالب مستقیماً echo می‌شوند.
• ورودی‌های نمایش‌داده‌شده در پنل مدیریت — مثل نام فایل آپلودشده، User-Agent در جدول لاگ، یا محتوای فرم تماس. این حالت به‌ویژه خطرناک است: مهاجم ناشناس داده را می‌فرستد و کد در مرورگر مدیر اجرا می‌شود. با دسترسی مدیر و ویرایشگر فایل، مسیر تا اجرای کد روی سرور باز است.
• شورت‌کدها با صفت‌های تحت کنترل کاربر.

الگوی کلی و انواع XSS را در دانشنامه‌ی XSS شرح داده‌ایم. برای کاهش اثر، سیاست CSP کمک می‌کند اما جایگزین کدگذاری درست نیست.

جدول کلاس‌های آسیب‌پذیری، کشف و رفع

Object Injection، SSRF در واردکننده‌ها و زنجیره‌ی تأمین

Object Injection از راه unserialize

وردپرس در بسیاری جاها داده را به‌شکل سریال‌شده در پایگاه‌داده ذخیره می‌کند و همین باعث می‌شود توسعه‌دهندگان به unserialize() عادت کنند. مشکل وقتی جدی می‌شود که ورودیِ آن از کاربر بیاید: مهاجم یک شیء سریال‌شده می‌سازد که هنگام بازسازی، متدهای چرخه‌ی حیات (__wakeup، __destruct، __toString) را در کلاس‌های موجود روی سیستم فعال می‌کند. با ترکیب چند کلاس — یک «زنجیره‌ی گجت» — می‌توان به حذف فایل یا اجرای کد رسید. نکته‌ی مهم: کلاس‌های آسیب‌پذیر لازم نیست در افزونه‌ی شما باشند؛ هر کلاسی که در کل نصب وردپرس بارگذاری شود قابل استفاده است، و همین باعث می‌شود سطح حمله با هر افزونه‌ی جدید بزرگ‌تر شود.

اصلاح روشن است: برای داده‌ای که از کاربر می‌آید از JSON استفاده کنید و هرگز unserialize() را روی ورودی نامعتبر اجرا نکنید. مفهوم کامل در دانشنامه‌ی Deserialization ناامن.

SSRF در واردکننده‌ها و ابزارهای دریافت از URL

افزونه‌های واردکننده (import)، دریافت تصویر از URL، بررسی لینک و پیش‌نمایش، همگی یک الگو دارند: کاربر یک آدرس می‌دهد و سرور آن را درخواست می‌کند. اگر مقصد اعتبارسنجی نشود، مهاجم می‌تواند سرور را وادار کند به سرویس‌های داخلی، پنل‌های مدیریتی محلی یا اندپوینت‌های متادیتای ابری درخواست بزند. دفاع درست: فهرست سفید مقصدها، تفکیک صریح طرح‌واره‌های مجاز (فقط http و https)، عدم پیروی از ریدایرکت یا اعتبارسنجی مجدد در هر پرش، و برنگرداندن پاسخ خام سرویس داخلی به کاربر. جزئیات و روش‌های دور زدن فیلتر در دانشنامه‌ی SSRF آمده است. توجه کنید در OWASP Top 10:2025، SSRF دیگر دسته‌ی مستقل نیست و زیر A01 قرار گرفته است.

سازش زنجیره‌ی تأمین و افزونه‌های رهاشده

دو سناریوی متمایز که هر دو زیر A03:2025 قرار می‌گیرند:

• افزونه‌ی رهاشده: توسعه‌دهنده دیگر نگهداری نمی‌کند. آسیب‌پذیری کشف می‌شود و هرگز وصله‌ای نمی‌آید. این ریسک با گذشت زمان فقط بزرگ‌تر می‌شود و تنها راه‌حلش حذف یا جایگزینی است.
• تغییر مالکیت یا سازش حساب توسعه‌دهنده: افزونه‌ای که مدت‌ها معتبر بوده، در یک به‌روزرسانی کد ناخواسته دریافت می‌کند. دفاع در برابر این حالت سخت‌تر است: کاهش تعداد افزونه‌ها، ترجیح افزونه‌های با تیم نگهدارنده‌ی شناخته‌شده، پایش تغییرات غیرمنتظره، و — مهم‌تر از همه — داشتن لاگ و پایش یکپارچگی تا اگر رخ داد، سریع تشخیص داده شود.

و همان قاعده‌ی همیشگی: افزونه‌ی نال‌شده نصب نکنید. در آن حالت شما بدافزار را با دست خودتان و با دسترسی کامل نصب کرده‌اید.

چطور این نقص‌ها را در سایت خودتان پیدا کنید

یک مسیر عملی، از ارزان به گران:

1. موجودی‌برداری. فهرست همه‌ی افزونه‌ها و قالب‌ها با نسخه‌شان. هر مورد را در برابر CVEهای منتشرشده و تاریخ آخرین به‌روزرسانی بررسی کنید. این ارزان‌ترین و پربازده‌ترین گام است.
2. حذف و به‌روزرسانی. هر چیزی که استفاده نمی‌شود حذف، هر چیزی که می‌ماند به‌روز.
3. بازبینی کد سفارشی. اگر افزونه یا قالب اختصاصی دارید، به دنبال این الگوها بگردید: wp_ajax_nopriv، __return_true، $_GET/$_POST داخل رشته‌ی کوئری، echo بدون esc_، unserialize، و move_uploaded_file. روش‌شناسی در بازبینی کد امن.
4. آزمون کنترل دسترسی با دو حساب. یک حساب کم‌دسترس و یک مدیر بسازید، همه‌ی درخواست‌ها را ثبت کنید و درخواست‌های مدیر را با نشست کاربر کم‌دسترس بازپخش کنید. این کار با Burp Suite یا Caido انجام می‌شود.
5. آزمون منطق و تزریق روی جریان‌های حساس: ثبت‌نام، بازنشانی رمز، آپلود، فرم‌های عمومی، و اندپوینت‌های پرداخت.
6. تست نفوذ کامل وقتی سایت درآمد یا داده‌ی واقعی کاربر دارد. اسکنرها بخشی از موارد شناخته‌شده را پیدا می‌کنند اما — همان‌طور که در ابزارهای امنیت سایت توضیح داده‌ایم — نقص کنترل دسترسی و ارتقای دسترسی را عملاً پیدا نمی‌کنند، چون ابزار نمی‌داند «چه کسی باید مجاز باشد».

اگر سایت وردپرسی شما فروشگاه، درگاه پرداخت یا داده‌ی مشتری دارد، ارزیابی هدفمند منطقی‌تر از چک‌لیست عمومی است: تست نفوذ وب و خدمات امنیت وردپرس.

پرسش‌های متداول

WRITTEN BY

محمدرضا مقدم

توسعه‌دهنده ابزار

مغز خودکارسازی تیم؛ ابزارها و زیرساخت داخلی پی‌هانتر را می‌سازد تا اسکن و گزارش‌گیری سریع‌تر و دقیق‌تر انجام شود.

LinkedIn ↗درباره تیم ←