گزارش تست نفوذ تنها خروجی قابل تحویل یک پروژه است؛ همه‌ی کار فنی در نهایت به آن تبدیل می‌شود. و دقیقاً همین‌جاست که تفاوت میان یک ارزیابی واقعی و یک اسکن بازاریابی‌شده بیش از هر جای دیگری آشکار می‌شود. اگر می‌خواهید نمونه گزارش تست نفوذ را بسنجید یا گزارشی را که تازه تحویل گرفته‌اید ارزیابی کنید، این مقاله بخش‌به‌بخش میگوید چه چیزی باید در آن باشد، هر یافته چه فیلدهایی لازم دارد، رتبه‌ی شدت را چگونه بخوانید — و کدام نشانه‌ها می‌گویند آنچه در دست دارید فقط خروجی PDF یک ابزار است.
در یک نگاه
- گزارش دو مخاطب دارد: خلاصه‌ی مدیریتی برای تصمیم‌گیر و بخش فنی یافتهها برای تیم توسعه. اگر یکی از این دو نیست، گزارش ناقص است.
- هر یافته باید بازتولیدپذیر باشد: شواهد خام درخواست/پاسخ، مراحل دقیق، و بردار کامل CVSS — نه فقط یک جمله‌ی توصیفی.
- بیانیه‌ی متدولوژی باید پوشش را به دسته‌ها و شناسه‌های WSTG v4.2 ارجاع دهد، نه به عبارت مبهم «همه‌ی آسیب‌پذیری‌ها».
- CVSS v4.0 استاندارد جاری است (انتشار رسمی FIRST.Org در ۱ نوامبر ۲۰۲۳)، اما v3.1 هنوز در دادهی واقعی غالب است. گزارش ۲۰۲۶ میتواند از هر دو استفاده کند، به شرط آنکه صریحاً بگوید کدام.
- نتایج آزمون مجدد و نامه‌ی تأییدیه بخشی از تحویل‌دادنی‌ها هستند؛ گزارشی بدون آن‌ها چرخه را نبسته است.
گزارش تست نفوذ برای چه کسی نوشته می‌شود؟
یک گزارش خوب هم‌زمان دو سند است که در یک جلد قرار گرفته‌اند، و هر کدام مخاطب کاملاً متفاوتی دارد.
مخاطب اول: تصمیم‌گیر. مدیر ارشد فناوری، مدیر ریسک یا صاحب کسبوکار. این فرد نمی‌خواهد بردار CVSS بخواند؛ میخواهد بداند «چه چیزی در معرض است، چقدر فوری است، و چه بودجه و زمانی برای رفع لازم است». پاسخ این سه سؤال باید در دو صفحه‌ی نخست باشد.
مخاطب دوم: تیم توسعه. این تیم نیازی به توضیح مفهوم IDOR ندارد؛ نیاز دارد بداند کدام اندپوینت، با کدام درخواست، تحت کدام نشست، چه چیزی برگرداند که نباید. برای این مخاطب، شواهد خام مهم‌تر از نثر است.
مخاطب سومی هم هست که اغلب فراموش می‌شود: خواننده‌ی بیرونی — مشتری سازمانی، شریک تجاری یا ممیز انطباق. این مخاطب نسخهی کامل را نمی‌بیند و به نامه‌ی تأییدیه بسنده میکند.
یک آزمون ساده: گزارش را به یک برنامه‌نویس تیم خودتان بدهید که در پروژه نبوده. اگر بتواند بدون تماس با تیم آزمون، یافته را روی محیط تست بازتولید کند، گزارش کار میکند. اگر نتواند، شما یک فهرست هشدار خریده‌اید نه یک گزارش.
ساختار کامل یک گزارش: نُه بخش استاندارد
ترتیب و نام‌گذاری بین شرکت‌ها کمی متفاوت است، اما یک گزارش حرفهای این نُه بخش را دارد. ساختار زیر با فاز «گزارش‌دهی» در NIST SP 800-115 و بخش پنجم راهنمای WSTG هم‌راستاست.
| # | بخش | محتوای الزامی |
|---|---|---|
| ۱ | خلاصه‌ی مدیریتی | وضعیت ریسک به زبان کسبوکار، شمارش یافتهها به تفکیک شدت، سه تا پنج توصیه‌ی اولویت‌دار |
| ۲ | دامنه و قواعد درگیری | فهرست دقیق دارایی‌ها، موارد خارج از دامنه، بازهی زمانی، محدودیت‌ها، مجوز کتبی |
| ۳ | بیانیه‌ی متدولوژی | مرجع پوشش (WSTG v4.2)، تاکسونومی ریسک (OWASP Top 10:2025 و CWE)، مدل جعبه، ابزارها |
| ۴ | خلاصه‌ی یافتهها | جدول تمام یافتهها با شناسه، عنوان، شدت، دارایی و وضعیت |
| ۵ | یافتههای تفصیلی | هر یافته با ساختار کامل و ثابت (بخش بعدی) |
| ۶ | یافتههای اطلاعاتی و مشاهدات | مواردی که آسیبپذیری نیستند اما سطح حمله را بزرگ می‌کنند یا بهبود مقاوم‌سازی‌اند |
| ۷ | نقشه‌ی راه رفع | اولویت‌بندی، تفکیک اقدام فوری/کوتاه‌مدت/ساختاری، تخمین تلاش |
| ۸ | نتایج آزمون مجدد | وضعیت هر یافته پس از رفع: تأییدشده / ناقص / رفع‌نشده / پذیرش ریسک |
| ۹ | نامه‌ی تأییدیه | سند یک‌صفحه‌ای قابل ارائه به طرف سوم |
بخش‌های ۱ تا ۷ در تحویل اول می‌آیند؛ بخش ۸ و ۹ پس از رفع یافتهها و اجرای آزمون مجدد به گزارش اضافه می‌شوند. اگر پیمانکار شما همه‌ی این‌ها را در یک تحویل واحد ارائه میدهد و «آزمون مجدد» جایی ندارد، یعنی چرخه‌ی رفع در قرارداد دیده نشده — همان مشکلی که در هزینه تست نفوذ به‌عنوان یکی از منابع اصلی اختلاف قیمت توضیح داده‌ایم.
خلاصه‌ی مدیریتی: چه باید داشته باشد و چه نباید
خلاصه‌ی مدیریتی سخت‌ترین بخش نوشتن است، چون باید بدون اصطلاح فنی دقیق بماند. آنچه باید داشته باشد:
- یک جمله‌ی وضعیت. مثلاً: «در دامنه‌ی آزموده‌شده، دو نقص کنترل دسترسی با شدت بحرانی شناسایی شد که امکان دسترسی به دادهی سایر مشتریان را فراهم می‌کرد.»
- شمارش یافتهها به تفکیک شدت در یک جدول کوچک.
- الگوی ریشه‌ای. این ارزشمندترین جمله‌ی گزارش است: آیا یافتهها پراکنده‌اند یا همه از یک علت مشترک می‌آیند (مثلاً «مجوزدهی در لایه‌ی مسیریابی انجام می‌شود، نه در لایه‌ی دسترسی به داده»)؟
- سه تا پنج توصیه‌ی اولویت‌دار با افق زمانی.
- محدودیت‌های ارزیابی. چه چیزی آزموده نشد و چرا.
و آنچه نباید داشته باشد: نمره‌ی کلی مبهم از ۱۰۰ که مبنای محاسبه‌اش توضیح داده نشده، مقایسه با «میانگین صناعت» بدون منبع، و ادعای «سامانه امن است». هیچ آزمونی نمی‌تواند نبود آسیبپذیری را اثبات کند؛ فقط میتواند بگوید در این دامنه، در این بازهی زمانی، با این سطح دسترسی، این موارد یافت شد.
«گزارش بدون یافتهی بحرانی یعنی سامانه امن است.» نه. گزارش بدون یافتهی بحرانی سه معنای ممکن دارد: سامانه واقعاً بالغ است، دامنه بیش از حد محدود بوده، یا آزمون سطحی بوده. تشخیص کدام‌یک، از بیانیه‌ی متدولوژی و بخش محدودیت‌ها ممکن می‌شود — نه از تعداد یافتهها. به همین دلیل، پیمانکاری که «تضمین کشف حداقل n آسیبپذیری» میدهد، از اساس در حال فروش چیز اشتباهی است.
دامنه و قواعد درگیری (Rules of Engagement)
این بخش ظاهر اداری دارد اما در عمل تعیین میکند گزارش شما چه ارزشی دارد. یک بیانیه‌ی دامنه‌ی کامل شامل این‌هاست:
- دارایی‌های داخل دامنه به‌صورت صریح: نام دامنه‌ها، زیردامنه‌ها، اندپوینت‌های API، و اینکه محیط عملیاتی بود یا Staging.
- موارد خارج از دامنه به‌صورت صریح‌تر: زیرساخت شبکه، سرویس‌های ثالث، مهندسی اجتماعی، منع سرویس.
- بازهی زمانی آزمون با تاریخ و ساعت. یافتهها عکس لحظه‌ای هستند؛ کدی که هفته‌ی بعد منتشر شود در این گزارش نیست.
- نقش‌ها و حساب‌های در اختیار تیم — همان چیزی که سطح واقعی پوشش کنترل دسترسی را مشخص میکند.
- محدودیت‌های اعمال‌شده: نرخ درخواست، ممنوعیت آزمون‌های مخرب، فهرست IPهای مبدأ تیم آزمون، مسیر تماس تشدید (Escalation) و نام افراد پاسخگو در دو طرف.
- ارجاع به مجوز کتبی و NDA.
وجود IPهای مبدأ و بازهی زمانی در گزارش، فایده‌ی جانبی مهمی دارد: تیم پایش شما میتواند لاگ‌های همان بازه را بررسی کند و ببیند چه مقدار از فعالیت آزمون را تشخیص داده بود. این خودش یک سنجه‌ی مستقل است و مستقیماً به دسته‌ی A09:2025 در OWASP Top 10:2025 (نقص ثبت رخداد و هشداردهی) مربوط می‌شود. جزئیات حقوقی و قالب مجوز را در قرارداد و مجوز تست نفوذ و ساختار مرحله‌ای کار را در فرایند تست نفوذ آورده‌ایم.
بیانیه‌ی متدولوژی: چگونه پوشش را ادعا کنیم
این بخش پاسخ میدهد که «چه چیزی آزموده شد» و باید به مرجع بیرونی وصل باشد، نه به ادعای درونی. عبارت حرفهای چیزی شبیه این است:
پوشش آزمون فنی بر پایه‌ی OWASP Web Security Testing Guide v4.2 و دوازده دسته‌ی آن اجرا شد. رده‌بندی ریسک با OWASP Top 10:2025 و CWE انجام شده و شدت با CVSS v4.0 امتیازدهی شده است. ساختار چرخه‌ی پروژه (اسکوپینگ، قواعد درگیری، گزارش‌دهی) بر پایه‌ی فازهای PTES و NIST SP 800-115 است.
چند نکته‌ی صداقتی که یک بیانیه‌ی درست رعایت میکند:
- WSTG v4.2 نسخهی پایدار جاری است و در ۳ دسامبر ۲۰۲۰ منتشر شده. نسخهی ۴٫۳ منتشر نشده و ۵٫۰ در حال توسعه است. ادعای «متدولوژی ۲۰۲۶ OWASP» نادرست است؛ جمله‌ی درست این است که v4.2 نسخهی پایدار فعلی است و پروژه یک نسخهی وب «stable» را به‌روز نگه می‌دارد.
- دسته‌ی WSTG-APIT فقط یک آزمون دارد (GraphQL). اگر دامنه شامل API است، بیانیه باید OWASP API Security Top 10 (نسخهی ۲۰۲۳) را به‌عنوان مرجع مکمل نام ببرد.
- «گواهی OWASP»، «انطباق با PTES» و «OSSTMM Compliant» وجود خارجی ندارند. اگر در بیانیه‌ی متدولوژی یک گزارش این عبارت‌ها را دیدید، نویسنده‌ی گزارش استانداردها را نمیشناسد. توضیح کامل در متدولوژی تست نفوذ.
- فهرست ابزارها باید باشد، اما ابزار جای متدولوژی را نمی‌گیرد. فهرست واقع‌بینانه‌ی ابزارها در ابزارهای تست نفوذ آمده است.
هم‌چنین اگر دامنه‌ی مشخصی از WSTG آزموده نشده (مثلاً دسته‌ی CRYP چون TLS در لایه‌ی CDN مدیریت می‌شود و خارج از دامنه بود)، همان‌جا نوشته شود. گزارشی که ادعای پوشش ۱۰۰٪ میکند، معمولاً پوشش را نسنجیده است.
ساختار هر یافته: فیلدهای الزامی
قلب گزارش همین است. هر یافته باید ساختار یکسان و کامل داشته باشد تا قابل مقایسه، قابل پیگیری و قابل بازتولید باشد.
| فیلد | چه چیزی باید باشد | چرا لازم است |
|---|---|---|
| شناسه‌ی یافته | کد یکتا مثل PH-2026-014 | پیگیری در سیستم تیکت و در آزمون مجدد |
| عنوان | توصیف فنی خنثی، مثل «کنترل دسترسی افقی در اندپوینت جزئیات سفارش» | عنوان مبهم باعث دسته‌بندی غلط و اولویت غلط می‌شود |
| دارایی متأثر | میزبان، مسیر دقیق، متد HTTP، پارامتر | بدون این، تیم توسعه نمی‌داند کجا را نگاه کند |
| شدت + بردار CVSS | رتبه‌ی کیفی و بردار کامل، با ذکر نسخه | بردار، استدلال امتیاز را قابل بازبینی میکند |
| دسته‌بندی | OWASP A0x:2025 + شناسه‌ی WSTG + CWE | اتصال به تاکسونومی استاندارد و امکان تحلیل روند |
| توضیح فنی | مکانیزم نقص در همان برنامه، نه تعریف عمومی کتاب درسی | تعریف عمومی را همه می‌دانند؛ ارزش در تحلیل موردی است |
| شواهد و PoC | درخواست/پاسخ خام، مراحل شماره‌گذاری‌شده، تصویر شاهد | معیار بازتولیدپذیری؛ بدون آن یافته قابل تأیید نیست |
| پیش‌نیازهای بهره‌جویی | چه سطح دسترسی و چه شرایطی لازم است | مبنای واقعی اولویت‌بندی؛ یافته‌ای که نیازمند دسترسی مدیر است ریسک متفاوتی دارد |
| تأثیر کسبوکار | ترجمه‌ی نقص فنی به پیامد: افشای دادهی مشتری، خسارت مالی، توقف سرویس | این تنها بخشی است که تصمیم‌گیر می‌خواند |
| راهکار رفع | اقدام مشخص در سطح کد یا پیکربندی، به‌ترتیب اثربخشی | «ورودی را اعتبارسنجی کنید» راهکار نیست؛ راهکار مکان و شکل تغییر است |
| مراجع | پیوند به CWE، دسته‌ی OWASP و راهنمای رسمی مربوطه | به تیم توسعه امکان مطالعه‌ی مستقل میدهد |
| وضعیت آزمون مجدد | خالی در تحویل اول؛ پر شده پس از رفع | بستن چرخه و مستندسازی برای ممیزی |
یک نکته درباره‌ی PoC: شاهد باید وجود نقص را اثبات کند، نه آن را تسلیح کند. برای یک تزریق، نمایش شکل آسیبپذیری (مثلاً ' OR '1'='1 و تفاوت پاسخ) کافی است؛ زنجیره‌ی بهره‌جویی کامل و قابل اجرا نه لازم است و نه مسئولانه. برای یافتههای کنترل دسترسی، شاهد استاندارد نمایش دو درخواست یکسان با دو نشست متفاوت و پاسخ متفاوت است.
«راهکار رفع این یافته: قانون WAF اضافه کنید.» WAF یک کنترل جبرانی و ابزار خریدن زمان است، نه راهکار رفع. WAF ساختاراً نسبت به نقص کنترل دسترسی، منطق کسبوکار، شرایط مسابقه و بخش بزرگی از DOM XSS کور است، و قابل دور زدن است. در یک گزارش حرفهای، راهکار رفع همان تغییر کد است و قانون WAF حداکثر به‌عنوان «کاهش موقت ریسک تا زمان رفع» ذکر می‌شود.
چگونه یک رتبه‌ی شدت را بخوانیم
رتبه‌ی شدت عددی نیست که به آن اعتماد کورکورانه کنید؛ استدلالی است که باید بتوانید بازبینی کنید. به همین دلیل بردار کامل مهم‌تر از عدد است.
CVSS نسخهی ۴٫۰ استاندارد جاری است و در ۱ نوامبر ۲۰۲۳ رسماً توسط FIRST.Org منتشر شده؛ نسخه‌های ۳٫۱ و پیش‌تر در سایت FIRST بایگانی محسوب می‌شوند. بازه‌های کیفی نسبت به نسخهی ۳ تغییری نکرده‌اند:
| رتبه | بازهی امتیاز | انتظار عملی از زمان رفع |
|---|---|---|
| Critical (بحرانی) | ۹٫۰ – ۱۰٫۰ | اقدام فوری، خارج از چرخه‌ی انتشار عادی |
| High (بالا) | ۷٫۰ – ۸٫۹ | در نزدیک‌ترین انتشار ممکن |
| Medium (متوسط) | ۴٫۰ – ۶٫۹ | در برنامه‌ی انتشار جاری یا بعدی |
| Low (پایین) | ۰٫۱ – ۳٫۹ | در بدهی فنی، با زمان‌بندی مشخص |
| None | ۰٫۰ | مشاهده‌ی اطلاعاتی |
چیزی که در v4.0 تغییر کرده و در خواندن گزارش مهم است
- معیار جدید Attack Requirements (AT) اضافه شده که پیش‌نیازهای وابسته به استقرار را از پیچیدگی حمله جدا میکند.
- معیار User Interaction از دو حالت به سه حالت
None/Passive/Activeگسترش یافته. - معیار Scope حذف شده و جای آن دو مجموعه‌ی تأثیر آمده: سامانه‌ی آسیب‌پذیر (VC/VI/VA) و سامانه‌ی پیرو (SC/SI/SA).
- گروه Temporal به Threat تغییر نام داده و فقط یک معیار دارد: Exploit Maturity.
- گروه Supplemental اضافه شده (Safety، Automatable، Recovery و…) که روی عدد اثر نمی‌گذارد و فقط زمینه میدهد.
- نام‌گذاری صریح CVSS-B / CVSS-BT / CVSS-BE / CVSS-BTE معرفی شده تا مشخص باشد امتیاز فقط پایه است یا تهدید و محیط هم لحاظ شده‌اند.
این آخری در عمل مهم‌ترین است: بیشتر امتیازهایی که در گزارش‌ها می‌بینید CVSS-B هستند، یعنی فقط پایه. امتیاز پایه محیط شما را نمیشناسد. یک XSS با امتیاز پایه‌ی متوسط روی پنل مدیریت داخلی که فقط از VPN دسترس‌پذیر است، ریسک واقعی متفاوتی نسبت به همان یافته روی صفحه‌ی عمومی ورود دارد. اگر پیمانکار امتیاز محیطی نمی‌دهد، حداقل باید تأثیر کسبوکار را جداگانه توضیح دهد.
پذیرش v4.0 در دادهی واقعی هنوز جزئی است. در مجموعه‌داده‌ی OWASP Top 10:2025، از حدود ۲۲۰٬۰۰۰ رکورد CVE بررسی‌شده، ۱۵۶٬۰۰۰ مورد امتیاز CVSS v3 داشتند و فقط ۶٬۰۰۰ مورد امتیاز v4. فهرست CWE Top 25 سال ۲۰۲۵ متعلق به MITRE هم امتیازدهی را انحصاراً با v3.0/v3.1 انجام داده است. نتیجه: یک گزارش در سال ۲۰۲۶ با هر دو نسخه قابل دفاع است؛ چیزی که قابل دفاع نیست، نگفتن نسخه یا مخلوط کردن دو نسخه در یک جدول است.
نقشه‌ی راه رفع و نتایج آزمون مجدد
فهرست یافتهها به‌تنهایی برنامه‌ی کار نیست. نقشه‌ی راه، یافتهها را به سه سطح ترجمه میکند:
- اقدام فوری. یافتههای بحرانی و مواردی که هم‌اکنون قابل بهره‌جویی از بیرون هستند. اینجا حتی یک راهکار موقت (بستن اندپوینت، غیرفعال‌سازی قابلیت) قابل قبول است.
- رفع کوتاه‌مدت. اصلاح کد یافتههای بالا و متوسط در چرخه‌ی انتشار جاری.
- اصلاح ساختاری. علت مشترک. اگر هفت یافتهی کنترل دسترسی وجود دارد، رفع تک‌تک هفت مورد راه‌حل نیست؛ راه‌حل انتقال مجوزدهی به یک لایه‌ی مرکزی است. این بخش همان جایی است که یک گزارش خوب بیشترین ارزش را می‌سازد.
سپس آزمون مجدد. این مرحله باید هر یافته را در یکی از چهار وضعیت قرار دهد:
| وضعیت | معنا |
|---|---|
| رفع تأییدشده | بردار اصلی و واریانت‌های آن دیگر کار نمی‌کنند |
| رفع ناقص | بردار اصلی بسته شده اما واریانت (متد HTTP دیگر، اندپوینت دوقلوی API، کدگذاری دیگر) باز است |
| رفع‌نشده | تغییری اعمال نشده یا اثری نداشته |
| پذیرش ریسک | سازمان آگاهانه ریسک را پذیرفته؛ باید مکتوب و امضاشده باشد |
«رفع ناقص» شایعترین نتیجه‌ی آزمون مجدد است و دقیقاً دلیل الزامی بودن این مرحله. الگوی رایج: تیم توسعه بررسی مجوز را به مسیر GET اضافه میکند و مسیر PATCH همان منبع را فراموش میکند. توجه کنید که PCI DSS v4.0.1 در بند ۱۱٫۴٫۴ تکرار آزمون برای تأیید رفع را الزام میکند و نگهداری نتایج و شواهد رفع را برای حداقل ۱۲ ماه میخواهد. اتصال این چرخه به فرایند جاری سازمان را در مدیریت آسیبپذیری شرح داده‌ایم.
نامه‌ی تأییدیه و گزارش سانسورشده
گزارش کامل سند محرمانه‌ای است که نقشه‌ی راه حمله به سامانه‌ی شما را در خود دارد؛ آن را برای مشتری یا شریک تجاری نمی‌فرستید. برای این کار دو خروجی جداگانه لازم است:
- نامه‌ی تأییدیه (Attestation Letter). سندی یک تا دو صفحهای روی سربرگ پیمانکار که میگوید: چه دارایی‌هایی، در چه بازهی زمانی، با چه متدولوژی آزموده شدند؛ توزیع شدت یافتهها؛ وضعیت رفع پس از آزمون مجدد؛ و امضای مسئول فنی. این سند جزئیات فنی یافتهها را ندارد و همان چیزی است که در ارزیابی تأمین‌کننده از شما خواسته می‌شود.
- گزارش سانسورشده (Redacted). نسخه‌ای که ساختار، متدولوژی و نمونه‌ای از سطح جزئیات را نشان میدهد ولی نام دارایی، شواهد و مسیرها حذف شده‌اند. این همان چیزی است که شما هم باید پیش از خرید از پیمانکار بخواهید — و توضیح داده‌ایم در کارشناس تست نفوذ که چرا نداشتنش یک نشانهی هشدار است.
یک نکته‌ی حقوقی که در قرارداد باید روشن باشد: مالکیت گزارش، مدت نگهداری دادهی آزمون توسط پیمانکار، و سازوکار امحا. تیم آزمون در جریان کار نمونه‌ای از دادهی واقعی، لاگ درخواست‌ها و شواهد را در اختیار دارد؛ سرنوشت این‌ها باید مکتوب باشد.
نشانه‌های گزارشی که گزارش تست نفوذ نیست
PDF صادرشده از یک ابزار اسکن سند بی‌ارزشی نیست — برای پایش پیوسته مفید است. مسئله جایی است که همان فایل با برچسب «گزارش تست نفوذ» تحویل داده شود. نشانه‌های تشخیص:
- هیچ یافته‌ای مربوط به کنترل دسترسی یا منطق کسبوکار وجود ندارد. قوی‌ترین نشانه. ابزارها ساختاراً این دسته را پیدا نمی‌کنند، در حالی که OWASP گزارش میکند ۱۰۰٪ برنامه‌های آزموده‌شده نوعی نقص کنترل دسترسی داشته‌اند.
- توضیح یافتهها عمومی و قابل کپی است و به معماری برنامه‌ی شما اشاره‌ای نمیکند.
- ده‌ها یافتهی تکراری از یک جنس — مثلاً هدر امنیتی غایب روی هر مسیر، به‌جای یک یافتهی واحد در سطح سایت.
- شواهد، تصویری از رابط ابزار است نه درخواست و پاسخ HTTP؛ و راهکار رفع متن عمومی ابزار است بدون نام فایل یا مسیر.
- بخش دامنه و قواعد درگیری وجود ندارد و هیچ اشاره‌ای به نقش‌های آزموده‌شده نیست.
- نسخهی CVSS ذکر نشده یا شدت‌ها بدون بردار آمده‌اند.
برای دیدن روایت واقعی یک پروژه — از اسکوپینگ تا کشف IDOR و منطق تخفیف — نمونه تست نفوذ را بخوانید، و برای سنجش پوشش گزارش در برابر مرجعی مستقل چک لیست تست نفوذ را. نمونهی سانسورشده‌ی گزارش ما را میتوانید از فرم مشاوره یا صفحه‌ی خدمات تست نفوذ وب درخواست کنید.
پرسش‌های متداول
نمونه گزارش تست نفوذ را از کجا میتوانم ببینم؟
هر پیمانکار حرفهای باید نسخهی سانسورشده از یک گزارش واقعی داشته باشد که ساختار، عمق یافتهها و شکل شواهد را نشان دهد، بدون افشای نام مشتری یا دادهی او. اگر پیمانکاری فقط جلد و فهرست نشان میدهد یا میگوید «به دلیل محرمانگی نمیتوانیم»، این یک نشانهی هشدار است — سانسور کردن گزارش کار سختی نیست. نمونهی ما را میتوانید از فرم مشاوره درخواست کنید.
گزارش تست نفوذ چند صفحه باید باشد؟
تعداد صفحه معیار نیست و گمراهکننده است. یک گزارش ۳۰ صفحهای با هشت یافتهی واقعی و شواهد بازتولیدپذیر، از یک گزارش ۲۰۰ صفحهای که ۱۸۰ صفحهاش خروجی خام ابزار است بسیار ارزشمندتر است. معیار درست این است: آیا تیم توسعه میتواند بدون تماس اضافی، هر یافته را بازتولید و رفع کند؟
تفاوت گزارش تست نفوذ با گزارش اسکن آسیبپذیری چیست؟
گزارش اسکن، فهرست هشدارهای ابزار است: وسیع، کمعمق، محدود به الگوهای شناختهشده و مستعد مثبت کاذب. گزارش تست نفوذ حاوی یافتههای تأییدشده توسط انسان با شواهد بازتولیدپذیر، تحلیل تأثیر کسبوکار و یافتههای کنترل دسترسی و منطق است که هیچ اسکنری تولید نمیکند. تفصیل تفاوت در ارزیابی امنیتی آمده است.
آیا گزارش تست نفوذ برای دریافت گواهی یا انطباق کافی است؟
بستگی به چارچوب دارد. PCI DSS در بند ۱۱٫۴ آزمون نفوذ داخلی و بیرونی حداقل هر ۱۲ ماه و پس از تغییرات مهم را الزام میکند و نگهداری نتایج و شواهد رفع را برای حداقل ۱۲ ماه میخواهد. ISO/IEC 27001:2022 در کنترلهای A.8.8 و A.8.29 فرایند مبتنی بر ریسک میخواهد اما دورهی مشخصی تعیین نمیکند — ادعای «ISO الزام تست سالانه دارد» نادرست است.
چرا در گزارش، شدت یافته با تصور ما متفاوت است؟
معمولاً چون امتیاز ارائهشده CVSS-B (فقط پایه) است و پایه، محیط شما را نمیشناسد: جداسازی شبکه، وجود MFA، حساسیت داده و کنترلهای جبرانی در آن لحاظ نشده. راه درست این است که از پیمانکار بخواهید بردار کامل را بدهد و در صورت نیاز معیارهای محیطی (CVSS-BE) را هم محاسبه کند، یا حداقل تأثیر کسبوکار را جداگانه توضیح دهد.
آزمون مجدد چه زمانی باید انجام شود؟
پس از اینکه تیم توسعه رفعها را روی محیطی مشابه محیط عملیاتی مستقر کرد — نه بعد از هر تکرفع. بازهی متعارف چند هفته پس از تحویل گزارش است و باید در قرارداد مشخص باشد. توجه کنید شایعترین نتیجه «رفع ناقص» است: یک متد HTTP یا اندپوینت دوقلوی API جا میماند، و همین دلیل الزامی بودن این مرحله است.
منابع
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسبوکار و زنجیره‌های حمله‌ی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارش‌های تست نفوذ پی‌هانتر با اوست.