بررسی Passive و امن

بررسی امنیت سایت وردپرسی

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

این ابزار دقیقاً چه کار می‌کند؟

سرور wp-check مثل یک بازدیدکنندهٔ معمولی حدود ۲۰ آدرس عمومی سایت شما را فقط با درخواست GET باز می‌کند؛ همان کاری که ربات‌های مهاجم هر روز به‌صورت خودکار روی میلیون‌ها سایت وردپرسی انجام می‌دهند. سپس پاسخ‌ها را تحلیل می‌کند و نشان می‌دهد چه اطلاعاتی از سایت شما بیرون درز کرده است، و برای هر مورد راه‌حل عملی و کد آماده می‌دهد.

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

چه چیزهایی بررسی می‌شود؟

افشای نام‌های کاربری

آیا مهاجم می‌تواند بدون هیچ دسترسی، نام کاربری مدیر و نویسندگان را پیدا کند؟

  • لیست کاربران در REST API

    آدرس /wp-json/wp/v2/users خوانده می‌شود تا ببینیم لیست نام‌های کاربری برای همه قابل مشاهده است یا نه.

    چرا مهم است؟ مهاجم با داشتن نام کاربری فقط باید رمز را حدس بزند؛ یعنی نیمی از کار حملهٔ brute-force و credential stuffing آماده است. در سایت‌های ایرانی نام کاربری گاهی شمارهٔ موبایل است که خودش داده شخصی است.

  • شمارش نویسندگان با ?author=1

    آدرس /?author=1 درخواست می‌شود؛ وردپرس به‌طور پیش‌فرض آن را به /author/نام‌کاربری ریدایرکت می‌کند.

    چرا مهم است؟ با عوض کردن عدد (author=2، 3، …) می‌شود نام کاربری همهٔ نویسندگان، معمولاً از جمله مدیر سایت، را یکی‌یکی درآورد.

  • سایت‌مپ نویسندگان

    سایت‌مپ داخلی وردپرس برای نویسندگان (/wp-sitemap-users-1.xml) بررسی می‌شود.

    چرا مهم است؟ این سایت‌مپ آدرس صفحهٔ همهٔ نویسندگان را لیست می‌کند و هر آدرس شامل نام کاربری است.

  • صفحهٔ ورود در مسیر پیش‌فرض

    فقط بررسی می‌شود که صفحهٔ /wp-login.php باز می‌شود یا نه؛ هیچ فرمی ارسال و هیچ رمزی امتحان نمی‌شود.

    چرا مهم است؟ ربات‌های brute-force همیشه همین مسیر را هدف می‌گیرند. به‌تنهایی آسیب‌پذیری نیست، اما همراه با افشای نام کاربری خطرناک‌تر می‌شود.

افشای نسخه و اطلاعات فنی

آیا سایت نسخهٔ وردپرس، افزونه‌ها یا نرم‌افزار سرور را به همه نشان می‌دهد؟

  • فایل readme.html وردپرس

    فایل /readme.html که همراه هر نصب وردپرس روی سرور قرار می‌گیرد بررسی می‌شود.

    چرا مهم است؟ این فایل تأیید می‌کند سایت وردپرسی است و گاهی نسخه را هم لو می‌دهد؛ مهاجم با دانستن نسخه مستقیم سراغ آسیب‌پذیری‌های شناخته‌شدهٔ همان نسخه می‌رود.

  • متای Generator در سورس صفحه

    سورس صفحهٔ اصلی برای تگ <meta name="generator"> که نسخهٔ وردپرس را اعلام می‌کند بررسی می‌شود.

    چرا مهم است؟ نسخهٔ دقیق وردپرس را در اختیار اسکنرهای خودکار می‌گذارد تا سایت‌های نسخهٔ آسیب‌پذیر را سریع پیدا کنند.

  • شناسایی افزونه‌ها از ریشهٔ REST API

    ریشهٔ REST API (/wp-json/) خوانده می‌شود و namespaceهای غیر پیش‌فرض (که معمولاً هرکدام متعلق به یک افزونه است) استخراج می‌شود.

    چرا مهم است؟ مهاجم نقشهٔ افزونه‌های نصب‌شده را بدون هیچ تلاشی به دست می‌آورد (مثلاً wc/v3 یعنی ووکامرس) و دنبال آسیب‌پذیری‌های همان افزونه‌ها می‌گردد.

  • افشای نسخهٔ وب‌سرور و PHP

    هدرهای Server و X-Powered-By در پاسخ صفحهٔ اصلی بررسی می‌شود.

    چرا مهم است؟ نسخهٔ دقیق نرم‌افزار سرور و PHP به مهاجم می‌گوید دنبال کدام آسیب‌پذیری‌های شناخته‌شده بگردد. نسخه‌های قدیمی PHP دیگر آپدیت امنیتی نمی‌گیرند.

پیکربندی سرور و وردپرس

تنظیماتی که سطح حمله را بزرگ‌تر می‌کنند: xmlrpc، لاگ دیباگ، HTTPS، هدرهای امنیتی و…

  • HTTPS و ریدایرکت از http

    بررسی می‌شود که سایت روی HTTPS بالا می‌آید و نسخهٔ http آن به https ریدایرکت می‌شود.

    چرا مهم است؟ بدون HTTPS اجباری، رمز عبور و کوکی ورود مدیر روی شبکه (مثلاً وای‌فای عمومی) به‌صورت متن ساده جابه‌جا می‌شود.

  • هدرهای امنیتی HTTP

    وجود هدرهای Strict-Transport-Security، X-Frame-Options (یا frame-ancestors در CSP) و X-Content-Type-Options در پاسخ صفحهٔ اصلی بررسی می‌شود.

    چرا مهم است؟ بدون این هدرها سایت در برابر clickjacking (قرار دادن سایت در iframe برای فریب کاربر)، MIME sniffing و برگرداندن اتصال به http آسیب‌پذیرتر است.

  • xmlrpc.php فعال

    فایل /xmlrpc.php فقط با یک درخواست GET بررسی می‌شود؛ هیچ درخواست XML-RPC واقعی ارسال نمی‌شود.

    چرا مهم است؟ با متد system.multicall می‌شود صدها رمز را در یک درخواست امتحان کرد (دور زدن محدودیت تلاش ورود)، و از pingback برای حملات DDoS به سایت‌های دیگر استفاده کرد.

  • فایل debug.log عمومی

    فایل لاگ دیباگ وردپرس در /wp-content/debug.log بررسی می‌شود.

    چرا مهم است؟ لاگ خطا ممکن است مسیر فایل‌ها روی سرور، کوئری‌های دیتابیس، ایمیل کاربران و حتی توکن‌ها را لو بدهد.

  • لیست شدن فایل‌های پوشهٔ uploads

    پوشهٔ /wp-content/uploads/ باز می‌شود تا ببینیم وب‌سرور لیست فایل‌ها (Index of) را نشان می‌دهد یا نه.

    چرا مهم است؟ همهٔ فایل‌های آپلودشده، از جمله فاکتورها، رزومه‌ها یا بکاپ‌هایی که افزونه‌ها آنجا می‌گذارند، برای همه قابل مرور و دانلود می‌شود.

فایل‌های حساس جامانده

فایل‌هایی که نباید هرگز روی سرور عمومی باشند: بکاپ کانفیگ، دیتابیس، .env و .git

  • پوشهٔ .git در دسترس

    فایل /.git/HEAD بررسی می‌شود؛ اگر باز شود یعنی کل مخزن گیت روی سرور عمومی است.

    چرا مهم است؟ با پوشهٔ .git می‌شود کل سورس سایت و تاریخچهٔ تغییراتش را (گاهی همراه رمزها و کلیدها) دانلود کرد.

  • فایل .env در دسترس

    فایل /.env بررسی می‌شود و فقط وقتی مثبت حساب می‌شود که واقعاً متغیرهایی مثل DB_PASSWORD یا SECRET داشته باشد.

    چرا مهم است؟ فایل متغیرهای محیطی معمولاً رمز دیتابیس، کلیدهای API و توکن‌های درگاه پرداخت را دارد.

  • بکاپ wp-config (.bak)

    نسخهٔ پشتیبان /wp-config.php.bak بررسی می‌شود.

    چرا مهم است؟ برخلاف wp-config.php، فایل .bak اجرا نمی‌شود و به‌صورت متن خام دانلود می‌شود؛ یعنی رمز دیتابیس و کلیدهای امنیتی وردپرس لو می‌رود.

  • فایل موقت ویرایشگر wp-config (~)

    فایل /wp-config.php~ که ویرایشگرهایی مثل nano/vim هنگام ذخیره می‌سازند بررسی می‌شود.

    چرا مهم است؟ مثل فایل .bak، به‌صورت متن خام دانلود می‌شود و رمز دیتابیس را لو می‌دهد.

  • خروجی دیتابیس (database.sql)

    فایل /database.sql در ریشهٔ سایت بررسی می‌شود.

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

  • صفحهٔ phpinfo.php

    فایل /phpinfo.php که معمولاً برای تست سرور ساخته و فراموش می‌شود بررسی می‌شود.

    چرا مهم است؟ پیکربندی کامل PHP و سرور، مسیرهای فایل، ماژول‌ها و گاهی متغیرهای محیطی را نشان می‌دهد.

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

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

محدودیت‌ها

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