امنیت وردپرس: آسیب‌پذیری‌های وردپرس

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

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

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

آسیب‌پذیری (vulnerability) یک ضعف قابل‌سوءاستفاده در نرم‌افزار یا پیکربندی است. حمله (attack)، تلاش برای سوءاستفاده از یک ضعف یا عبور از کنترل‌های امنیتی است. نفوذ (penetration) زمانی رخ می‌دهد که مهاجم بتواند کاری خارج از مجوز خود انجام دهد؛ مثلاً اطلاعاتی را بخواند یا تنظیماتی را تغییر دهد که نباید به آنها دسترسی داشته باشد.

برای مثال، فرض کنید افزونه‌ای اجازه تغییر تنظیمات را بدون بررسی درست سطح دسترسی به کاربر می‌دهد. این نقص، آسیب‌پذیری است. تلاش یک کاربر برای استفاده از آن، حمله محسوب می‌شود. تغییر موفق تنظیمات توسط کاربری که چنین مجوزی ندارد، نتیجه سوءاستفاده از آسیب‌پذیری یا همان هک شدن است.

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

آسیب‌پذیری‌های وردپرس ناشی از کامپیوتر شما

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

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

نرم‌افزارهای کرک‌شده و فایل‌های ناشناس

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

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

محدودیت ابزارهایی مانند NoScript

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

آسیب‌پذیری‌های هسته، افزونه‌ها و پوسته‌ها

وردپرس برای رفع مشکلات امنیتی و خطاهای نرم‌افزاری، به‌صورت منظم به‌روزرسانی منتشر می‌کند. اما یک سایت وردپرسی فقط از هسته تشکیل نشده است؛ هر افزونه، پوسته و کد سفارشی نیز باید در برنامه نگهداری (maintenance) قرار بگیرد. برای دریافت بسته هسته وردپرس، همواره از وبسایت رسمی وردپرس استفاده کنید یا به‌روزرسانی را از مسیر رسمی پیشخوان انجام دهید. درباره افزونه و پوسته نیز منبع تهیه، وضعیت پشتیبانی و نسخه نصب‌شده را مشخص نگه دارید.

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

آیا نسخه‌های قدیمی وردپرس هیچ اصلاحیه امنیتی دریافت نمی‌کنند؟

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

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

به‌روزرسانی خودکار وردپرس چگونه عمل می‌کند؟

قابلیت به‌روزرسانی پس‌زمینه از وردپرس نسخه 3.7 معرفی شد و مدیریت آپدیت خودکار افزونه‌ها و پوسته‌ها در نسخه 5.5 توسعه یافت. با این حال، این برداشت که «آپدیت‌های اصلی همیشه دستی هستند» درست نیست. از وردپرس 5.6، نصب‌های تازه می‌توانند به‌صورت پیش‌فرض آپدیت‌های اصلی و جزئی هسته را خودکار دریافت کنند؛ وردپرس‌های قدیمی‌تر و تنظیمات اختصاصی ممکن است رفتار متفاوتی داشته باشند. ثابت‌ها، فیلترها و تنظیمات سایت نیز روی این رفتار اثر می‌گذارند. جزییات در مستندات به‌روزرسانی خودکار وردپرس آمده است.

پس وضعیت واقعی سایت را در «پیشخوان ← به‌روزرسانی‌ها» و تنظیمات افزونه‌ها بررسی کنید. فعال بودن قابلیت خودکار، جای بررسی موفقیت آپدیت و عملکرد بخش‌های مهم را نمی‌گیرد.

انواع حملات و ضعف‌های امنیتی در وردپرس

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

حملات ورود: Brute Force و استفاده از رمزهای افشاشده

در حمله Brute Force، مهاجم ترکیب‌های مختلف نام کاربری و رمز عبور را برای ورود امتحان می‌کند. در Credential Stuffing، از اطلاعات ورود افشاشده سرویس‌های دیگر استفاده می‌شود؛ به همین دلیل تکرار رمز عبور میان چند سایت خطرناک است.

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

تزریق SQL یا SQL Injection

اگر داده‌های ورودی کاربر بدون رسیدگی مناسب وارد دستور پایگاه داده شوند، ممکن است مهاجم منطق آن دستور را تغییر دهد. پیامد این رخداد می‌تواند خواندن یا تغییر اطلاعات خارج از مجوز باشد. توضیح OWASP درباره SQL Injection سازوکار این نوع حمله را شرح می‌دهد.

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

اجرای اسکریپت در مرورگر یا XSS

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

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

جعل درخواست یا CSRF

در CSRF، مهاجم تلاش می‌کند مرورگر کاربری را که وارد سایت شده، به ارسال یک درخواست ناخواسته وادار کند. مشکل اصلی، پذیرفته شدن آن درخواست بدون کنترل مناسب است. شرح این حمله در مستندات OWASP درباره CSRF آمده است.

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

کنترل ناقص دسترسی و افزایش سطح دسترسی

ممکن است یک قابلیت افزونه به‌درستی بررسی نکند که کاربر اجازه خواندن یک داده یا تغییر تنظیمات را دارد یا خیر. برای مثال، یک مشترک نباید بتواند با ارسال درخواست مستقیم، تنظیمات مدیریتی افزونه را تغییر دهد.

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

آسیب‌پذیری‌های وب‌سرور و هاست

وبسرور، PHP و سایر اجزای محیط میزبانی نیز به نگهداری نیاز دارند. در هاست مدیریت‌شده، باید از میزبان بپرسید کدام بخش‌ها را به‌روزرسانی می‌کند و کدام مسئولیت‌ها بر عهده شماست.

برای PHP، «قابل اجرا بودن سایت» با «دریافت اصلاحیه امنیتی» مترادف نیست. نسخه‌ای که به پایان پشتیبانی رسیده، ممکن است همچنان سایت را اجرا کند، اما دیگر اصلاحیه رسمی دریافت نکند. برای ارزیابی این موضوع از جدول رسمی نسخه‌های پشتیبانی‌شده PHP استفاده کنید و سازگاری افزونه‌ها را پیش از تغییر نسخه بررسی کنید.

آیا هاست اشتراکی همیشه ناامن‌تر است؟

در میزبانی چند سایت روی یک سرور، کیفیت جداسازی حساب‌ها و پیکربندی اهمیت دارد. آلودگی سایت دیگر به این معنا نیست که سایت شما حتماً آلوده می‌شود؛ باید وضعیت جداسازی و دسترسی‌ها بررسی شود. از طرف دیگر، خرید VPS به تنهایی امنیت ایجاد نمی‌کند. اگر سرویس مدیریت‌شده نباشد، مسئولیت نگهداری سیستم عامل، تنظیمات شبکه و نرم‌افزارهای سرور نیز به کارهای شما اضافه می‌شود.

پیشنهاد من این است که سرویس را بر اساس نیاز سایت و توان نگهداری انتخاب کنید. از میزبان درباره جداسازی حساب‌ها، نسخه‌های نرم‌افزار، بکاپ و روند رسیدگی به رخداد امنیتی سؤال کنید؛ اسم پلن میزبانی برای تصمیم‌گیری کافی نیست.

آسیب‌پذیری‌های وردپرس ناشی از شبکه

اطلاعات ورود را از مسیر HTTP ارسال نکنید. صفحه ورود و پیشخوان باید از HTTPS معتبر استفاده کنند. هشدار گواهی مرورگر را هم نادیده نگیرید. HTTPS در وردپرس از ارتباط مرورگر و سرور محافظت می‌کند، اما سلامت دستگاه یا امن بودن خود نرم‌افزار سایت را تضمین نمی‌کند.

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

پیشنهاد می‌شود مسیر دسترسی به پنل هاست، ایمیل بازیابی و ابزار انتقال فایل را نیز در بررسی امنیت قرار دهید. مراقبت فقط از صفحه ورود وردپرس، همه راه‌های مدیریت سایت را پوشش نمی‌دهد.

چک‌لیست بررسی آسیب‌پذیری‌های وردپرس

• دستگاه‌های مدیران و مرورگرهای آنها به‌روز و منابع نصب نرم‌افزار مشخص هستند.
• وضعیت هسته، افزونه‌ها و پوسته‌ها و موفقیت به‌روزرسانی‌ها بررسی شده است.
• گزارش‌های آسیب‌پذیری با نسخه نصب‌شده و شرایط سوءاستفاده تطبیق داده می‌شوند.
• حساب‌های مدیریتی، نقش کاربران و روش‌های ورود بازبینی شده‌اند.
• مسئول نگهداری وبسرور و PHP مشخص است.
• ارتباط ورود و مدیریت با HTTPS معتبر انجام می‌شود.
• مسیر ثبت گزارش و تماس با هاستینگ در زمان رخداد مشخص است.

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

اگر مشکوک به هک هستیم، چه چیزهایی را بررسی کنیم؟

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

برای بررسی اولیه پیشنهاد می‌شود:

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

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

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

برای بررسی امنیت وردپرس، ابتدا محل احتمالی مشکل را مشخص کنید: دستگاه مدیر، نرم‌افزار سایت، حساب کاربری، سرور یا شبکه. سپس شواهد و مسئول رسیدگی را کنار هم بگذارید. مثلاً نسخه آسیب‌پذیر یک افزونه نیاز به اصلاحیه دارد، در حالی که نگرانی درباره دستگاه مدیر باید در همان دستگاه پیگیری شود.

در قسمت بعدی مجموعه، بحث دسترسی فایل‌ها در وردپرس را ادامه می‌دهیم. پیش از تغییر تنظیمات فایل یا سرور، بکاپ تهیه کنید و اثر تغییرات را متناسب با محیط میزبانی خود بررسی کنید.