حملات وردپرس فقط از صفحهٔ ورود شروع نمی‌شوند. کد آسیب‌پذیر، اطلاعات ورود افشاشده یا پیکربندی نامناسب میزبانی هم می‌تواند راه دسترسی ایجاد کند. در این مقاله چهار مسیر مهم را بررسی می‌کنیم؛ این دسته‌بندی رتبه‌بندی آماری حملات نیست و همهٔ تهدیدهای ممکن را پوشش نمی‌دهد.
آسیب‌پذیری، ضعف قابل‌سوءاستفاده است؛ حمله، تلاش برای بهره‌برداری از آن. وجود یک ضعف به معنی هک‌شدن قطعی نیست و مشاهدهٔ چند درخواست مشکوک در لاگ هم به‌تنهایی نفوذ موفق را ثابت نمی‌کند.
۱. حملات وردپرس از مسیر افزونه و قالب آسیب‌پذیر
افزونه و قالب می‌توانند در کنترل دسترسی، دریافت فایل یا پردازش ورودی ضعف داشته باشند. پیامد به نوع ضعف و دسترسی لازم برای استفاده از آن بستگی دارد. صرف محبوبیت یا تعداد نصب، تضمین امنیت نیست.
فهرست افزونه‌ها، قالب‌ها و نسخه‌ها را نگه دارید و هشدار مربوط به همان محصول و بازهٔ نسخه را بررسی کنید. اگر اصلاحیه منتشر شده، آن را با اولویت متناسب اعمال کنید. اگر هنوز اصلاحیه وجود ندارد، محدودکردن قابلیت آسیب‌پذیر یا جایگزینی ابزار باید بر اساس توصیهٔ معتبر و اثر آن بر سایت تصمیم‌گیری شود.
افزونهٔ غیرفعال معمولاً مثل افزونهٔ فعال در همهٔ درخواست‌ها اجرا نمی‌شود، اما باقی‌ماندن فایل‌ها می‌تواند در برخی ضعف‌ها همچنان مهم باشد. ابزار واقعاً بلااستفاده را پس از بررسی داده و وابستگی‌ها حذف کنید. راهنمای مدیریت وابستگی آسیب‌پذیر OWASP بر شناخت مؤلفه‌ها و رسیدگی متناسب به خطر تأکید دارد.
۲. حمله به حساب کاربری؛ حدس رمز و استفاده از رمز افشاشده
در Brute Force ترکیب‌های ورود امتحان می‌شوند. در Credential Stuffing، اطلاعات ورود لو‌رفته از سرویس دیگر آزمایش می‌شود. در حالت دوم حتی رمز طولانی هم اگر تکراری باشد می‌تواند مشکل‌ساز شود؛ طول رمز مصونیت مطلق ایجاد نمی‌کند.
برای هر حساب رمز یکتا و طولانی انتخاب کنید و از مدیر رمز معتبر کمک بگیرید. احراز هویت چندمرحله‌ای، محدودسازی تلاش ورود و بررسی رویدادهای غیرعادی لایه‌های مکمل‌اند. راهنمای احراز هویت OWASP این کنترل‌ها را در کنار هم توضیح می‌دهد.
قفل‌کردن حساب یا IP را طوری تنظیم کنید که کاربر واقعی پشت IP مشترک بی‌دلیل مسدود نشود. نام کاربری را راز اصلی حساب فرض نکنید؛ ممکن است از صفحات نویسنده مشخص باشد. حساب مدیریت را بین افراد مشترک نکنید و به نویسنده فقط دسترسی لازم بدهید؛ نقش‌های وردپرس سطح اختیار متفاوت دارند.
۳. هسته و اجزای قدیمی یا بدون پشتیبانی
به‌روزرسانی هسته، افزونه و قالب بخش اصلی نگهداری است. همچنین وضعیت پشتیبانی PHP و سایر اجزای سرور را با میزبان بررسی کنید. رفع ضعف در یک جزء، نسخهٔ قدیمی همان جزء را خودبه‌خود امن نمی‌کند.
برای اصلاحیهٔ امنیتی برنامهٔ سریع داشته باشید؛ برای تغییر عمده هم سازگاری و مسیر برگشت را مشخص کنید. صرف روشن‌کردن به‌روزرسانی خودکار کافی نیست: نتیجهٔ اجرا و خطاهای احتمالی باید دیده شود. راهنمای به‌روزرسانی خودکار وردپرس محل تنظیم و اعلان‌های نتیجه را توضیح می‌دهد.
به‌روزرسانی، کد سالم جدید را جایگزین می‌کند، ولی لزوماً همهٔ آثار نفوذ قبلی، حساب اضافه یا فایل مخرب در مسیر دیگر را پاک نمی‌کند. اگر شواهد نفوذ وجود دارد، علاوه بر اصلاح نسخه، بررسی حادثه لازم است.
۴. میزبانی، دسترسی فایل و دستگاه مدیر
امنیت سایت به وردپرس محدود نیست. دسترسی پنل هاست، حساب انتقال فایل، مجوزهای پوشه و امنیت رایانهٔ مدیر هم اهمیت دارند. سرور مجازی صرفاً به دلیل اختصاصی‌بودن منابع، خودکار امن‌تر نمی‌شود؛ مسئولیت نگهداری آن باید روشن باشد.
از میزبان دربارهٔ به‌روزرسانی سرور، جداسازی حساب‌ها و رسیدگی به رخداد سؤال کنید. فایل تنظیمات، لاگ دارای اطلاعات حساس و آرشیو سایت نباید در مسیر عمومی قابل‌دریافت باشند. راهنمای سخت‌سازی وردپرس این لایه‌ها را بخشی از دفاع کلی می‌داند. هیچ نوع هاستی تضمین حذف تمام خطرها نیست.
اگر به نفوذ مشکوک شدیم چه کنیم؟
- نشانه و زمان را ثبت کنید: کاربر ناشناس، تغییر غیرمجاز فایل یا انتقال ناخواستهٔ بازدیدکننده.
- لاگ و شواهد را پیش از پاک‌سازی نگه دارید و با میزبان برای تعیین دامنهٔ اثر هماهنگ شوید.
- راه ورود را ببندید و فایل‌ها، حساب‌ها و داده‌های تغییرکرده را بررسی کنید.
- پس از پاک‌سازی، اعتبارهای در معرض خطر را از دستگاه سالم عوض و نشست‌های نامعتبر را باطل کنید.
- کارکرد سایت و نشانه‌های بازگشت آلودگی را پایش کنید.
راهنمای رسیدگی به سایت هک‌شده نقطهٔ شروع مناسبی است. کندی یا خطای 500 به‌تنهایی دلیل هک نیست؛ تصمیم را بر اساس شواهد بگیرید، نه صرف ظاهر خطا.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
