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

وردپرس پرکاربردترین سیستم مدیریت محتوا در بازار ایران است و همین باعث می‌شود بیشترین حجم حملات خودکار را دریافت کند. اما نکته‌ی کلیدی امنیت وردپرس این است: هک وردپرس تقریباً هرگز از هسته شروع نمی‌شود. نقطه‌ی ورود در اکثریت قاطع موارد یک افزونه یا قالب است — یعنی همان چیزی که OWASP در نسخه‌ی ۲۰۲۵ آن را زیر دسته‌ی A03:2025 نقص‌های زنجیره‌ی تأمین نرم‌افزار قرار می‌دهد. این مقاله اقدامات امنیتی وردپرس را بر پایه‌ی همین واقعیت اولویت‌بندی می‌کند و صادقانه می‌گوید کدام توصیه‌های رایج اثر واقعی دارند و کدام‌ها فقط احساس امنیت می‌سازند.

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

سه واقعیت ساختاری، تصویر ریسک وردپرس را می‌سازند:

1. سهم بازار بالا یعنی حمله‌ی مقیاس‌پذیر. مهاجم یک آسیب‌پذیری در یک افزونه‌ی پرنصب پیدا می‌کند و همان یک اکسپلویت را روی صدها هزار سایت اجرا می‌کند. حمله هدفمند نیست؛ شما «انتخاب» نشده‌اید، فقط در دامنه‌ی اسکن بوده‌اید.
2. اکوسیستم افزونه باز است. بخش بزرگی از قابلیت‌های سایت را کدی می‌سازد که شما ننوشته‌اید، بازبینی نکرده‌اید و کیفیت امنیتی‌اش را نمی‌دانید. مخزن رسمی فرایند بازبینی دارد اما هدف آن تضمین امنیت هر خط کد نیست.
3. فاصله‌ی بین انتشار وصله و نصب آن. وقتی آسیب‌پذیری یک افزونه عمومی می‌شود، اسکن انبوه معمولاً خیلی سریع آغاز می‌شود. سایتی که هفته‌ای یک بار به‌روزرسانی می‌شود، پنجره‌ی وسیعی در اختیار مهاجم می‌گذارد.

هسته در برابر افزونه و قالب

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

مدیریت افزونه و قالب: مهم‌ترین کار امنیتی شما

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

معیارهای انتخاب افزونه

• آخرین به‌روزرسانی. افزونه‌ای که ماه‌ها به‌روز نشده، ریسک است — نه چون کدش بد است، بلکه چون وقتی آسیب‌پذیری‌اش کشف شود کسی وصله نمی‌کند. این همان CWE-1104 (استفاده از مؤلفه‌ی شخص ثالثِ نگهداری‌نشده) است.
• سازگاری اعلام‌شده با نسخه‌ی جاری وردپرس و پاسخگویی توسعه‌دهنده در بخش پشتیبانی.
• سابقه‌ی آسیب‌پذیری و نحوه‌ی برخورد با آن. افزونه‌ای که آسیب‌پذیری داشته اما سریع و شفاف وصله کرده، از افزونه‌ای که هرگز گزارشی نداشته قابل اعتمادتر است.
• حجم کد و دامنه‌ی دسترسی. افزونه‌ای که فقط یک شورت‌کد اضافه می‌کند با افزونه‌ای که مدیریت فایل یا اجرای کد ارائه می‌دهد، از نظر ریسک قابل مقایسه نیست.
• هرگز افزونه یا قالب «نال‌شده» نصب نکنید. نسخه‌های کرک‌شده رایج‌ترین راه ورود بدافزار به سایت‌های وردپرسی ایرانی هستند. کد مخرب در آن‌ها عمداً کار گذاشته شده و از هیچ به‌روزرسانی امنیتی هم بهره نمی‌برند.

انضباط عملیاتی

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

مقاوم‌سازی احراز هویت و پنل مدیریت

دومین وکتور بزرگ پس از افزونه‌ها: دسترسی به حساب مدیر. این دسته زیر A07:2025 خطاهای احراز هویت قرار می‌گیرد.

شمارش کاربران (User Enumeration)

وردپرس به‌صورت پیش‌فرض چند مسیر برای کشف نام‌کاربری‌ها فراهم می‌کند: مسیر نویسنده (/?author=1 که به نامک کاربر ریدایرکت می‌شود)، برخی اندپوینت‌های REST API، و پیام‌های خطای متفاوت در فرم ورود. اهمیت این موضوع را نه دست‌کم بگیرید نه بزرگ کنید: شمارش کاربران به‌تنهایی آسیب‌پذیری بحرانی نیست، اما ورودی حملات حدس رمز و فیشینگ هدفمند را فراهم می‌کند. رفع آن ساده است: ریدایرکت مسیر نویسنده، محدود کردن دسترسی ناشناس به اندپوینت کاربران، و یکسان‌سازی پیام خطای ورود.

مجوز فایل‌ها، ویرایشگر پنل و محافظت از wp-config

این سه مورد از دسته‌ی A02:2025 پیکربندی نادرست هستند: بدون تغییر کد، با اثر واقعی.

غیرفعال کردن ویرایشگر فایل در پنل

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

// wp-config.php
define( 'DISALLOW_FILE_EDIT', true );
// و اگر نصب افزونه از پنل لازم نیست:
define( 'DISALLOW_FILE_MODS', true );

محافظت از wp-config.php

این فایل نام کاربری و رمز پایگاه‌داده و کلیدهای نمک را دارد. اقدامات مؤثر: مجوز فایل محدود (خواندنی فقط برای کاربر سرویس وب)، مسدود کردن دسترسی مستقیم HTTP به آن در پیکربندی وب‌سرور، و در صورت امکان انتقال آن به یک سطح بالاتر از ریشه‌ی وب. همچنین کلیدهای نمک باید یکتا و تصادفی باشند؛ در هر رخداد امنیتی باید بازتولید شوند.

مجوز فایل و اجرای PHP در پوشه‌ی آپلود

• قاعده‌ی عمومی: فایل‌ها 644 و پوشه‌ها 755؛ wp-config.php محدودتر. هرگز 777 ندهید — این کار به هر فرایندی روی سرور اجازه‌ی نوشتن می‌دهد.
• اجرای PHP را در پوشه‌ی wp-content/uploads غیرفعال کنید. این تنها اقدامی است که یک آپلود فایلِ آسیب‌پذیر را از تبدیل شدن به اجرای کد از راه دور بازمی‌دارد و در عمل بسیار مؤثر است.
• فایل‌های بکاپ، .sql، آرشیو و پوشه‌ی .git را از ریشه‌ی وب حذف کنید. این‌ها با ابزارهای ساده‌ی شناسایی پیدا می‌شوند.
• فهرست‌شدن دایرکتوری را ببندید.

پیشوند جدول، XML-RPC و REST API: ارزیابی صادقانه

تغییر پیشوند جدول‌ها

توصیه‌ای که در هر فهرست امنیت وردپرس تکرار می‌شود. واقعیت: سود آن حاشیه‌ای است. تغییر wp_ به چیز دیگر فقط در برابر اکسپلویت‌های ازپیش‌نوشته‌ای مفید است که نام جدول را ثابت فرض کرده‌اند. هر تزریق SQL که بتواند اسکیما را بخواند — که تقریباً همه‌شان می‌توانند — پیشوند را در چند ثانیه پیدا می‌کند. اگر سایت جدیدی می‌سازید، پیشوند متفاوت انتخاب کنید چون رایگان است؛ اما تغییر آن روی سایت فعال، ریسک خرابی دارد و به‌هیچ‌وجه در اولویت شما نیست. به‌جایش کوئری‌های افزونه‌های سفارشی را با $wpdb->prepare() اصلاح کنید.

XML-RPC

اندپوینت xmlrpc.php رابط قدیمی وردپرس برای انتشار از راه دور است. دو مسئله‌ی واقعی دارد: امکان ارسال چندین درخواست احراز هویت در یک فراخوانی که حدس رمز را کارآمد می‌کند، و سوءاستفاده‌ی pingback برای ارسال درخواست از طرف سرور شما. اگر از اپ موبایل وردپرس، Jetpack یا انتشار از راه دور استفاده نمی‌کنید، غیرفعال کردنش تصمیم درستی است. اگر استفاده می‌کنید، دسترسی به آن را محدود و نرخ‌بندی کنید.

REST API

برخلاف XML-RPC، REST API بخش زنده و ضروری وردپرس مدرن است و غیرفعال کردن کامل آن معمولاً اشتباه است — پنل مدیریت و بسیاری از افزونه‌ها به آن وابسته‌اند. رویکرد درست، محدودسازی هدفمند است:

• دسترسی ناشناس به اندپوینت کاربران را ببندید تا نام‌کاربری‌ها فهرست نشوند.
• اندپوینت‌های افزونه‌های خودتان را با permission_callback واقعی محافظت کنید — نه با __return_true. این رایج‌ترین اشتباه توسعه‌ی افزونه است و مستقیماً به کنترل دسترسی شکسته منجر می‌شود.
• نرخ درخواست به اندپوینت‌های حساس را محدود کنید.

بکاپ، پایش و ثبت رخداد

این بخش کاری با پیشگیری ندارد؛ درباره‌ی این است که وقتی اتفاق افتاد، چقدر سریع بفهمید و چقدر سریع برگردید.

بکاپ

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

پایش و لاگ

OWASP در A09:2025 نقص ثبت رخداد و هشداردهی امنیتی دقیقاً به این می‌پردازد: بدون لاگ، حمله تشخیص داده نمی‌شود و بدون هشدار، پاسخ سریع ممکن نیست. برای یک سایت وردپرسی حداقل‌ها:

• پایش یکپارچگی فایل‌ها با هشدار بر تغییر فایل‌های هسته و قالب.
• هشدار بر ایجاد کاربر جدید، تغییر نقش، و ورود موفق مدیر از IP جدید.
• نگهداری لاگ دسترسی وب‌سرور با عمق کافی — این دقیقاً چیزی است که در حادثه، تحلیل نقطه‌ی ورود را ممکن می‌کند.
• پایش انقضای گواهی و در دسترس بودن سایت.

افزونه‌های امنیتی: چه کاری می‌کنند و چه کاری نمی‌کنند

افزونه‌های امنیتی وردپرس ارزش دارند، اما اگر انتظار اشتباهی از آن‌ها داشته باشید، به یک حس امنیت کاذب تبدیل می‌شوند.

کارهایی که واقعاً انجام می‌دهند

• محدودسازی نرخ ورود و قفل موقت — مفید و مؤثر.
• پایش یکپارچگی فایل و مقایسه با نسخه‌ی رسمی — مفید برای تشخیص.
• ثبت رخداد و هشدار — ارزشمند، به‌ویژه اگر لاگ سرور در اختیار ندارید.
• فیلتر درخواست‌های شناخته‌شده‌ی مخرب و کاهش نویز اسکن‌های خودکار.
• اسکن بدافزار بر پایه‌ی امضا — برای آلودگی‌های شناخته‌شده مفید است.

کارهایی که نمی‌کنند

• آسیب‌پذیری افزونه‌ی شما را وصله نمی‌کنند. فقط به‌روزرسانی این کار را می‌کند.
• نقص کنترل دسترسی و IDOR را نمی‌بینند. هیچ فیلتری نمی‌داند کاربر شماره‌ی ۵ حق دیدن سفارش شماره‌ی ۷ را دارد یا نه.
• باگ منطق کسب‌وکار را تشخیص نمی‌دهند؛ درخواست‌ها هرکدام کاملاً قانونی به نظر می‌رسند.
• درِ پشتیِ سفارشی را پیدا نمی‌کنند، چون امضایی برای آن وجود ندارد.
• ماژول فایروال آن‌ها همان محدودیت‌های ذاتی هر WAF را دارد و قابل دور زدن است — به‌ویژه اگر مهاجم IP اصلی سرور را پیدا کند.

برنامه‌ی عملی: از امروز تا سه ماه آینده

یک مسیر واقع‌بینانه که می‌توانید همین امروز شروع کنید:

امروز

• فهرست کامل افزونه‌ها و قالب‌ها را بگیرید؛ هرچه استفاده نمی‌شود را حذف کنید.
• همه‌ی موارد باقی‌مانده را به‌روزرسانی کنید.
• MFA را برای همه‌ی حساب‌های مدیر فعال کنید.
• کاربران را مرور کنید: حساب ناشناس، نقش بیش از حد، و کاربران قدیمی که دیگر در سازمان نیستند.
• DISALLOW_FILE_EDIT را فعال کنید.

این هفته

• بکاپ خودکار بیرون از سرور راه‌اندازی و یک بازگردانی آزمایشی انجام دهید.
• اجرای PHP در پوشه‌ی آپلود را غیرفعال کنید.
• مجوز فایل‌ها و دسترسی به wp-config.php را اصلاح کنید.
• فایل‌های بکاپ، آرشیو و .git را از ریشه‌ی وب پاک کنید.
• XML-RPC را در صورت عدم نیاز ببندید و محدودسازی نرخ ورود را فعال کنید.

این ماه

• پایش یکپارچگی فایل و هشدار ورود مدیر را راه‌اندازی کنید.
• سیاست به‌روزرسانی مکتوب کنید: چه کسی، چه زمانی، با چه آزمونی.
• اگر کد سفارشی دارید (افزونه یا قالب اختصاصی)، آن را در برابر الگوهای رایج بازبینی کنید؛ فهرست کامل در آسیب‌پذیری‌های وردپرس.
• یک بررسی امنیتی سایت انجام دهید.

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

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

WRITTEN BY

امیر پیامنی

کارشناس تست نفوذ شبکه

شکارچی ضعف‌های زیرساخت؛ از نقشه‌برداری سطح حمله تا بهره‌برداری از سرویس‌های شبکه و حرکت جانبی داخل دامنه.

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