مشکل امنیتی که تا حمله بعدی متوجه آن نمیشوید
خیلی از مشکلات امنیتی فروشگاههای وردپرس/ووکامرس ساکت و نامرئی هستند — تا روزی که یک حمله واقعی رخ بدهد. وبنیوا این موارد را همین حالا، رایگان و بدون نیاز به دانش فنی نشان میدهد.
راهنمای تیم وبنیوا · آخرین بهروزرسانی: ۳ شهریور ۱۴۰۵
چه چیزی را بررسی میکنیم
شش بررسی واقعی — عمومی و اختصاصی وردپرس
تمام بررسیها passive و read-only هستند — هیچ درخواستی که بتواند به سایت شما آسیب بزند ارسال نمیشود.
HTTPS و محتوای مختلط
فعال بودن واقعی HTTPS روی صفحه اصلی، و بارگذاری هر منبعی (اسکریپت، تصویر، استایل) که هنوز از HTTP ناامن میآید — یک مشکل واقعی برای صفحاتی که ادعا میکنند HTTPS دارند اما محتوای مختلط هشدار مرورگر ایجاد میکند.
هدرهای امنیتی HTTP
بررسی Strict-Transport-Security (HSTS)، Content-Security-Policy، X-Content-Type-Options و Referrer-Policy — چهار هدر که اکثر فروشگاههای ایرانی اصلاً تنظیم نکردهاند، هرکدام با نقش دفاعی مشخص در برابر حملات واقعی.
افشای نام کاربری وردپرس
بررسی میکنیم آیا REST API وردپرس (wp-json/wp/v2/users) بدون نیاز به ورود، فهرست نامهای کاربری واقعی را در اختیار هرکسی قرار میدهد — نقطه شروع رایجترین حملات brute-force به پنل مدیریت.
XML-RPC فعال
فعال بودن xmlrpc.php در وردپرس — یک روش شناختهشده برای حملات brute-force و تقویت DDoS (سوءاستفاده از pingback) که اغلب فروشگاهها اصلاً به آن نیاز ندارند.
فهرست فایل عمومی (Directory Listing)
بررسی میکنیم آیا پوشه wp-content/uploads بهصورت عمومی قابل مرور است — نشانه یک پیکربندی نادرست سرور که میتواند فایلهای حساس بارگذاریشده را در معرض دید قرار دهد.
فایل پشتیبان wp-config.php
بررسی میکنیم آیا نسخه پشتیبان فایل wp-config.php (که معمولاً اطلاعات ورود دیتابیس را دارد) بهاشتباه در دسترس عموم قرار گرفته — یک خطای واقعی و جدی که در فروشگاههای واقعی دیده شده است.
راهنمای رفع
هر کدام از این مشکلات را چطور رفع کنیم؟
۱. محتوای مختلط (Mixed Content)
وقتی صفحه با HTTPS باز میشود ولی حتی یک تصویر یا اسکریپت هنوز از HTTP بارگذاری شود، مرورگر هشدار «ناامن» نشان میدهد و اعتماد کاربر — بهخصوص در صفحه پرداخت — آسیب میبیند. رفع معمولاً ساده است: افزونههای جستجو و جایگزینی آدرسهای http:// به https:// در دیتابیس (مثل Better Search Replace)، و بعد مرور کردن منابع باقیمانده در کنسول مرورگر (Console). اگر مشکل از قالب یا تنظیمات هاست باشد، آدرس سایت را در تنظیمات عمومی وردپرس هم با https چک کنید.
۲. هدرهای امنیتی HTTP
این هدرها در سطح سرور تنظیم میشوند، نه داخل وردپرس. روی اکثر هاستهای اشتراکی ایرانی میتوانید آنها را با چند خط در فایل .htaccess (آپاچی/لایتاسپید) یا پیکربندی Nginx اضافه کنید. شروع پیشنهادی: HSTS برای اجبار به HTTPS، دو هدر X-Content-Type-Options و Referrer-Policy که تقریباً بدون عارضه جانبی هستند، و در نهایت CSP که دقیقترین است اما باید مرحلهبهمرحله و با گزارش خطا تنظیم شود تا اسکریپتهای مجاز صفحه (آنالیتیکس، چت آنلاین و…) را نشکند.
۳. افشای نام کاربری وردپرس
اگر آدرس wp-json/wp/v2/users فهرست کاربران را نشان میدهد، مهاجم نام کاربری مدیر را رایگان میگیرد و فقط رمز عبور را باید حدس بزند. راهحلهای متداول: مسدودکردن مسیر users در REST API برای مهمانها (با افزونه امنیتی معتبر یا چند خط کد)، و مهمتر از آن — استفاده از نام کاربری غیرقابل حدس بهجای «admin». توجه کنید که برخی قالبها و افزونهها از همین API استفاده میکنند، پس بعد از تغییر حتماً عملکرد سایت را چک کنید.
۴. XML-RPC فعال
اگر از اپلیکیشن موبایل وردپرس یا سرویس خاصی که به XML-RPC وابسته است استفاده نمیکنید، این مسیر را کامل ببندید — بیشتر افزونههای امنیتی یک دکمه آماده برای همین دارند. این کار حملات brute-force متمرکز روی xmlrpc.php و سوءاستفاده pingback (که در DDoS های توزیعشده استفاده میشود) را همزمان خنثی میکند. اگر مطمئن نیستید آیا وابستهای دارید یا نه، ابتدا چند روز لاگ دسترسیها را بررسی کنید.
۵ و ۶. Directory Listing و فایل پشتیبان wp-config
هر دو معمولاً از پیکربندی اشتباه سرور میآیند و رفعشان در سطح هاست است: برای جلوگیری از مرور پوشهها، گزینه Options -Indexes را در .htaccess فعال کنید؛ و هر فایلی مثل wp-config.php.bak یا wp-config-old.php که در ریشه سایت مانده را فوراً از دسترس عمومی خارج یا حذف کنید — این فایلها معمولاً نام کاربری و رمز دیتابیس را داخل خود دارند و یکی از جدیترین یافتههای ممکن همین تست هستند.
سوالات متداول
همین حالا فروشگاه خود را بررسی کنید
فقط آدرس فروشگاه خود را وارد کنید — نتیجه واقعی، در چند ثانیه.