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

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

فصل اول: تست نفوذ وردپرس چیست؟

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

تست نفوذ (Penetration Testing) فرایند ارزیابی کنترل‌شده امنیت سامانه است که در آن متخصص تلاش می‌کند با روش‌های تعریف‌شده و در محدوده مجاز، وجود ضعف‌های امنیتی را اثبات کند.

تفاوت اسکن آسیب‌پذیری با تست نفوذ

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

فصل دوم: پیش‌نیازهای ضروری

پیش از شروع تست نفوذ، باید با مفاهیم زیر آشنا شوید:

لازم نیست پیش از شروع، در تمام این موضوعات متخصص باشید؛ اما باید آن‌ها را در طول دوره به‌ترتیب یاد بگیرید.

فصل سوم: ساخت آزمایشگاه امن تست نفوذ

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

گزینه‌های مناسب برای آزمایشگاه

مراحل آماده‌سازی

1. یک محیط محلی راه‌اندازی کنید.

2. وردپرس را با آخرین نسخه پایدار نصب کنید.

3. یک حساب مدیر و چند حساب آزمایشی با نقش‌های متفاوت بسازید.

4. یک نسخه پشتیبان از فایل‌ها و پایگاه داده تهیه کنید.

5. آدرس محلی سایت را یادداشت کنید؛ برای مثال:

http://wordpress-lab.local

6. ابزارهای بررسی را فقط روی همین محیط یا هدفی که مجوز کتبی آن را دارید اجرا کنید.

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

فصل چهارم: نقشه راه استاندارد تست نفوذ

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

این ساختار با رویکردهای ارزیابی امنیت برنامه‌های وب، از جمله راهنمای تست امنیت وب OWASP، هم‌راستا است.

فصل پنجم: شناسایی اولیه وردپرس

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

۵.۱ بررسی دستی سایت

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

در وردپرس، مسیرهای شناخته‌شده‌ای مانند موارد زیر ممکن است وجود داشته باشند:

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

۵.۲ بررسی پاسخ HTTP

اگر از ترمینال استفاده می‌کنید، در آزمایشگاه خود می‌توانید هدرهای پاسخ را مشاهده کنید:

curl -sS -D - -o /dev/null http://wordpress-lab.local/

این فرمان هدرهای پاسخ HTTP را نشان می‌دهد و محتوای صفحه را در خروجی نمایش نمی‌دهد.

موارد قابل بررسی:

• آیا سایت از HTTPS استفاده می‌کند؟

• آیا پاسخ‌ها اطلاعات غیرضروری درباره فناوری سرور افشا می‌کنند؟

• آیا هدرهای امنیتی متناسب با معماری سایت تنظیم شده‌اند؟

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

برای نمونه، Strict-Transport-Security برای سیاست HTTPS و Content-Security-Policy برای محدود کردن منابع قابل بارگذاری مرورگر کاربرد دارند. نبود یک هدر خاص، بدون بررسی معماری و ریسک، لزوماً آسیب‌پذیری قطعی نیست.

۵.۳ ساخت فهرست سطح حمله

در پایان شناسایی، جدولی شبیه این بسازید:

این فهرست، مبنای برنامه آزمون‌های مرحله بعد خواهد بود.

فصل ششم: بررسی هسته، قالب و افزونه‌های آسیب‌پذیر

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

۶.۱ چه چیزهایی را بررسی کنیم؟

• نسخه هسته وردپرس و وضعیت به‌روزرسانی آن

• افزونه‌های فعال و غیرفعال

• قالب فعال و قالب‌های بلااستفاده

• منبع دریافت افزونه‌ها و قالب‌ها

• تاریخ آخرین به‌روزرسانی و وضعیت پشتیبانی

• آسیب‌پذیری‌های ثبت‌شده برای نسخه دقیق هر جزء

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

۶.۲ ابزار WPScan

برای شروع، ابتدا نسخه ابزار را بررسی کنید:

wpscan --version

سپس یک بررسی اولیه روی وردپرس آزمایشگاهی خود اجرا کنید:

wpscan --url http://wordpress-lab.local

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

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

نحوه تحلیل خروجی:

1. نام و نسخه جزء شناسایی‌شده را ثبت کنید.

2. نام دقیق افزونه یا قالب را با شناسه رسمی آن تطبیق دهید.

3. هشدار را در پایگاه معتبر بررسی کنید.

4. نسخه‌های آسیب‌پذیر و اصلاح‌شده را مقایسه کنید.

5. بررسی کنید آیا شرایط لازم برای آسیب‌پذیری در سایت شما وجود دارد.

6. نتیجه را به‌عنوان «تأییدشده»، «احتمالی» یا «نیازمند بررسی بیشتر» ثبت کنید.

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

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

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

۷.۱ نقش‌های وردپرس را بشناسید

• مدیر (Administrator): دسترسی مدیریتی گسترده

• ویرایشگر (Editor): مدیریت و انتشار محتوای مجاز

• نویسنده (Author): مدیریت نوشته‌های خود

• مشارکت‌کننده (Contributor): ایجاد نوشته با محدودیت انتشار

• مشترک (Subscriber): دسترسی محدود به حساب کاربری

قابلیت‌های واقعی هر نقش می‌توانند با افزونه‌ها و تنظیمات تغییر کنند؛ بنابراین باید رفتار واقعی سایت را بررسی کنید.

۷.۲ آزمایش عملی در محیط محلی

دو حساب آزمایشی بسازید:

• حساب A: کاربر عادی

• حساب B: مدیر سایت

سپس مراحل زیر را انجام دهید:

1. با حساب مدیر یک نوشته آزمایشی بسازید.

2. با حساب عادی وارد سایت شوید.

3. بررسی کنید آیا کاربر عادی می‌تواند عملی را انجام دهد که به نقش مدیر نیاز دارد.

4. عملیات مجاز و غیرمجاز را ثبت کنید.

5. همین بررسی را برای صفحات مدیریتی و قابلیت‌های افزونه‌ها تکرار کنید.

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

مثال از یک ضعف واقعی

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

اصل امنیتی: مخفی کردن یک دکمه در رابط کاربری، جایگزین بررسی مجوز در سمت سرور نیست.

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

فصل هشتم: بررسی احراز هویت و نشست کاربری

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

چک‌لیست عملی

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

تمرین عملی

با حساب آزمایشی خود وارد وردپرس شوید و ابزار توسعه مرورگر را باز کنید. در بخش Storage یا Application، کوکی‌های سایت را مشاهده کنید.

موارد مهم:

• Secure: ارسال کوکی فقط روی اتصال امن

• HttpOnly: جلوگیری از دسترسی مستقیم JavaScript به کوکی

• SameSite: محدود کردن برخی ارسال‌های بین‌سایتی کوکی

وجود یا نبود هر ویژگی را با توجه به نوع کوکی و معماری برنامه تحلیل کنید. این ویژگی‌ها به‌تنهایی همه حملات مرتبط با نشست را خنثی نمی‌کنند.

برای بررسی تکمیلی، راهنمای آزمون احراز هویت OWASP را مطالعه کنید.

فصل نهم: بررسی XSS و اعتبارسنجی ورودی‌ها

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

سه دسته رایج عبارت‌اند از:

• Reflected XSS: ورودی در پاسخ همان درخواست به شکل ناامن بازتاب می‌شود.

• Stored XSS: داده ناامن ذخیره می‌شود و در بازدیدهای بعدی نمایش داده می‌شود.

• DOM-based XSS: پردازش ناامن داده در سمت مرورگر باعث اجرای کد می‌شود.

آزمایش کنترل‌شده

در فرم جست‌وجو یا یک فیلد آزمایشی در سایت محلی، یک رشته بی‌خطر مانند زیر وارد کنید:

TEST-XSS-01 < > " ' &

بررسی کنید:

1. آیا داده به‌صورت متن نمایش داده می‌شود؟

2. آیا علامت‌ها به‌درستی کدگذاری شده‌اند؟

3. آیا ورودی در HTML، ویژگی‌های HTML یا JavaScript قرار می‌گیرد؟

4. آیا همان داده در بخش مدیریت هم نمایش داده می‌شود؟

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

چه چیزی باید اصلاح شود؟

• اعتبارسنجی داده متناسب با کاربرد آن

• کدگذاری خروجی متناسب با محل نمایش

• پرهیز از قراردادن مستقیم ورودی کنترل‌شده کاربر در کد

• استفاده از روش‌های امن توسعه در PHP و JavaScript

• بررسی مجوز و پاک‌سازی داده‌ها در افزونه‌ها

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

فصل دهم: بررسی تزریق SQL

تزریق SQL زمانی رخ می‌دهد که ورودی کنترل‌شده کاربر به‌صورت ناامن در دستور پایگاه داده قرار گیرد.

برای نمونه، اگر افزونه‌ای مقدار ورودی را مستقیماً با یک رشته SQL ترکیب کند، ممکن است ساختار دستور پایگاه داده تغییر کند.

تمرین امن و عملی

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

دنبال این الگوها باشید:

• ساخت کوئری با اتصال مستقیم رشته‌ها

• استفاده از ورودی درخواست بدون اعتبارسنجی

• نبود پارامترهای امن در کوئری

• بررسی ناکافی نوع و محدوده مقادیر

• نمایش خطاهای پایگاه داده به کاربر

در وردپرس، برای کوئری‌های سفارشی باید از الگوهای امن مانند $wpdb->prepare() استفاده کرد و قالب کوئری را متناسب با داده‌ها طراحی کرد.

نمونه‌ای از یک الگوی پارامتری:

global $wpdb;

$user_id = 10;

$result = $wpdb->get_var(
    $wpdb->prepare(
        "SELECT ID FROM {$wpdb->users} WHERE ID = %d",
        $user_id
    )
);

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

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

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

فصل یازدهم: تست امنیت آپلود فایل

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

آزمایش عملی در محیط آزمایشگاهی

1. با یک حساب مجاز وارد وردپرس شوید.

2. یک تصویر بی‌خطر مانند PNG بارگذاری کنید.

3. نتیجه را بررسی کنید: آیا فایل به‌درستی ذخیره شده و فقط در محل مورد انتظار قابل دسترسی است؟

4. محدودیت‌های نوع فایل، اندازه فایل و مجوز بارگذاری را بررسی کنید.

5. با حسابی که مجوز بارگذاری ندارد، بررسی کنید آیا سرور درخواست را رد می‌کند.

6. مطمئن شوید که فایل‌های بارگذاری‌شده نمی‌توانند به‌صورت غیرمنتظره به‌عنوان کد اجرایی پردازش شوند.

چه مواردی را بررسی کنیم؟

• اعتبارسنجی سمت سرور، نه صرفاً بررسی پسوند در مرورگر

• بررسی نوع واقعی فایل و ساختار محتوای آن

• محدودیت حجم و تعداد درخواست‌ها

• نام‌گذاری امن فایل و جلوگیری از مسیرهای غیرمجاز

• مجوز نوشتن در پوشه‌های آپلود

• محدود کردن اجرای اسکریپت در محل ذخیره فایل‌ها، متناسب با معماری سرور

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

فصل دوازدهم: ارزیابی REST API وردپرس

وردپرس یک رابط برنامه‌نویسی به نام REST API دارد که به وب‌سایت‌ها و برنامه‌های دیگر اجازه می‌دهد با محتوای وردپرس تعامل کنند.

آدرس رایج آن:

http://wordpress-lab.local/wp-json/

در محیط آزمایشگاهی، این آدرس را در مرورگر باز کنید و ساختار پاسخ را بررسی کنید.

آزمایش کنترل دسترسی API

نکته مهم: عمومی بودن یک endpoint به معنی آسیب‌پذیری نیست. برخی داده‌ها ذاتاً عمومی هستند؛ معیار اصلی، مجاز بودن داده و عملیات مطابق طراحی سامانه است.

فصل سیزدهم: بررسی تنظیمات سرور و فایل‌های حساس

بسیاری از مشکلات امنیتی وردپرس از کدنویسی نیستند؛ بلکه از پیکربندی اشتباه سرور یا مجوزهای نامناسب فایل‌ها ناشی می‌شوند.

موارد مهم برای بررسی

راهنمای رسمی امنیت وردپرس درباره فایل‌های حساس، مجوزها، پایگاه داده و پشتیبان‌گیری توضیحات بیشتری ارائه می‌کند.

یک بررسی عملی با PHP

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

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

فصل چهاردهم: بررسی افزونه‌های اختصاصی وردپرس

اگر افزونه‌ای توسط تیم شما توسعه داده شده است، این بخش اهمیت بیشتری دارد.

چک‌لیست بازبینی کد افزونه

• آیا عملیات حساس مجوز کاربر را در سمت سرور بررسی می‌کند؟
• آیا درخواست‌های تغییردهنده وضعیت از محافظت مناسب در برابر CSRF برخوردارند؟
• آیا داده‌های ورودی اعتبارسنجی می‌شوند؟
• آیا خروجی متناسب با محل نمایش کدگذاری می‌شود؟
• آیا کوئری‌های پایگاه داده به‌صورت امن ساخته می‌شوند؟
• آیا فایل‌های بارگذاری‌شده کنترل می‌شوند؟
• آیا endpointهای REST API مجوزهای لازم را بررسی می‌کنند؟
• آیا خطاها اطلاعات حساس را افشا نمی‌کنند؟
• آیا اسرار و کلیدهای دسترسی در کد یا مخزن عمومی قرار نگرفته‌اند؟

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

فصل پانزدهم: ابزارهای ضروری تست نفوذ وردپرس

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

فصل شانزدهم: سناریوی عملی جامع تست نفوذ

در این سناریو، نقش یک تستر امنیت را دارید که مسئول ارزیابی یک وردپرس آزمایشگاهی است.

نمونه یافته امنیتی

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

این یک نمونه آموزشی از نحوه مستندسازی است، نه ادعای وجود چنین ضعفی در یک افزونه مشخص.

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

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

برای امتیازدهی استاندارد می‌توانید از CVSS استفاده کنید. شدت نهایی باید با شرایط واقعی محیط و شواهد آزمون سازگار باشد.

فصل نوزدهم: بعد از تست نفوذ چه کار کنیم؟

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

1. پیش از تغییرات، نسخه پشتیبان قابل‌بازیابی تهیه کنید.

2. ابتدا یافته‌های با ریسک بالا را برطرف کنید.

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

4. تنظیمات دسترسی، رمزها و مجوز فایل‌ها را اصلاح کنید.

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

6. همان آزمونی را که ضعف را نشان داده بود، مجدداً اجرا کنید.

7. اطمینان حاصل کنید که اصلاح امنیتی قابلیت عادی سایت را مختل نکرده است.

راهنمای امنیت وردپرس بر محدودسازی دسترسی، تهیه پشتیبان و آمادگی برای بازیابی تأکید دارد.

منابع تکمیلی برای ادامه یادگیری

جمع‌بندی صفر و یک سایبر

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