آسیب‌پذیری‌ها را شکار می‌کنیم،
پیش از مهاجمان.تست نفوذ، ارزیابی امنیتی و باگ‌بانتی — شرکت امنیت سایبری پی‌هانتر

DEEP DIVEتست نفوذ وب اپلیکیشن دقیقاً یعنی چه؟

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

پوشش فنی ما بر پایه‌ی OWASP Web Security Testing Guide بسته می‌شود؛ نسخه‌ی پایدار جاری این راهنما v4.2 است و حدود ۹۷ آزمون را در ۱۲ دسته تعریف می‌کند — از جمع‌آوری اطلاعات و پیکربندی و استقرار، تا احراز هویت، مجوزدهی، مدیریت نشست، اعتبارسنجی ورودی، رمزنگاری، منطق کسب‌وکار و آزمون‌های سمت کلاینت. رده‌بندی ریسک یافته‌ها با OWASP Top 10:2025 و شناسه‌های CWE انجام می‌شود و شدت با CVSS v4.0 نمره می‌گیرد (یا v3.1، اگر ابزار مدیریت ریسک شما هنوز با آن کار می‌کند). چرخه‌ی خود پروژه — از تعیین دامنه و قواعد تعامل تا گزارش — بر پایه‌ی فازهای PTES و NIST SP 800-115 ساختار پیدا می‌کند.

یک نکته را صریح می‌گوییم چون در بازار زیاد اشتباه گفته می‌شود: «گواهی OWASP»، «انطباق با PTES» یا «مجوز OSSTMM» وجود خارجی ندارد. این‌ها متدولوژی و چارچوب‌اند، نه طرح صدور گواهی. آنچه قابل ادعا و قابل بررسی است، پوشش است: اینکه کدام آزمون‌ها اجرا شده، چرا و با چه نتیجه‌ای.

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

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

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

محدوده‌ی معمول یک پروژه‌ی وب

• احراز هویت و نشست: سیاست رمز، محدودسازی تلاش ورود، بازیابی رمز، انقضای نشست، پرچم‌های کوکی و اعتبارسنجی توکن — از جمله بررسی درست ادعاهای aud و iss در JWT.
• کنترل دسترسی: آزمون افقی و عمودی روی هر نقش، اندپوینت‌های پنهان، و APIهایی که فقط در رابط کاربری محدود شده‌اند.
• اعتبارسنجی ورودی: خانواده‌ی تزریق (SQL، فرمان سیستم‌عامل، قالب سمت سرور)، XSS در هر سه بافت، و بارگذاری فایل.
• منطق کسب‌وکار: جایی که بیشترین یافته‌های پرارزش پیدا می‌شود و هیچ ابزاری آن را خودکار نمی‌کند.
• سمت کلاینت و پیکربندی: CORS، CSP، هدرهای امنیتی، افشای فایل‌های پشتیبان و پیام‌های خطای پرجزئیات.
• API: برای REST و GraphQL مرجع تکمیلی ما OWASP API Security Top 10 است، چون بخش API در WSTG v4.2 تنها یک آزمون (GraphQL) دارد.

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

گزارش، رفع و تست مجدد

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