گزارش تست نفوذ باید شامل چه چیزهایی باشد؟

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

این ساختاری است که گزارش‌های خودمان را با آن می‌سنجیم و پیشنهاد می‌کنیم آن را در درخواست پیشنهاد (RFP) بعدی‌تان بنویسید.

یک گزارش را سه گروه می‌خوانند و هر کدام از جای دیگری شروع می‌کنند:

۱. محدوده‌ی واقعاً آزمون‌شده، نه محدوده‌ی برنامه‌ریزی‌شده

صفحه‌ی اول باید دقیقاً بگوید چه چیزی در محدوده بوده و چه چیزی واقعاً آزمون شده است: نام دامنه‌ها، بازه‌های IP، نسخه‌ی برنامه‌ها، نقش‌های کاربری، محیط‌ها (عملیاتی، آزمایشی، نسخه‌ی کپی) و تاریخ‌ها. اگر سامانه‌ای در محدوده بوده ولی امکان آزمون آن فراهم نشده (سرویس از دسترس خارج بوده، اطلاعات ورود نرسیده، یا WAF آزمونگر را مسدود کرده و تنظیم نشده) گزارش باید صریحاً بنویسد. در غیر این صورت «نتیجه‌ی پاک» برای آن سامانه یک اطمینان کاذب است.

آنچه باید بخواهید: فهرست دارایی‌های آزمون‌شده با تاریخ آزمون هر یک، و فهرست استثناها با دلیل.

۲. روش‌شناسی و استاندارد

روش‌شناسی را نام ببرید و به آن پایبند بمانید. برای برنامه‌های وب معمولاً راهنمای OWASP WSTG و برای عمق بیشتر استاندارد ASVS؛ برای APIها فهرست OWASP API Security Top 10 و همان فصل‌های ASVS؛ برای زیرساخت، PTES یا مراحل NIST 800-115. ارزش این کار در خودِ نام اختصاری نیست؛ در این است که یک چک‌لیست نام‌دار به خواننده اجازه می‌دهد ببیند چه چیزی پیدا نشده، نه فقط چه چیزی پیدا شده.

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

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

ردیف‌هایی که می‌گویند «چیزی پیدا نشد» به اندازه‌ی ردیف‌های یافته‌دار ارزش دارند، چون همین ردیف‌ها به ممیز نشان می‌دهند که آن بخش واقعاً بررسی شده است.

۳. خلاصه‌ی مدیریتی که یک مدیر بتواند بر اساس آن اقدام کند

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

۴. یافته‌ها، هر کدام در یک صفحه و با قالب ثابت

هر یافته باید همان فیلدها را با همان ترتیب داشته باشد تا صد یافته را بتوان در یک بعدازظهر اولویت‌بندی کرد:

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

یک یافته با همین قالب، از همان پروژه‌ی ساختگی روی API یک فروشگاه:

GET /api/v2/orders/100482 HTTP/1.1
Host: shop.example
Authorization: Bearer eyJ… (test customer A, customer_id 5531)

HTTP/1.1 200 OK
Content-Type: application/json

{"order_id": 100482, "customer_id": 5537, "name": "[redacted]",
 "address": "[redacted]", "items": 3, "total": 1840000}

نکته: داده‌ی شخصی را در شواهد پنهان کنید، اما هرگز بخشی را که یافته را اثبات می‌کند. این‌جا نام و نشانی پنهان شده‌اند و customer_id مانده است: ۵۵۳۷ همان ۵۵۳۱ درخواست‌کننده نیست و همین تفاوت، خودِ یافته است.

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

۵. زنجیره‌ها و اثر بر کسب‌وکار

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

یک نمونه از همان پروژه. آزمونگر کار را با یک حساب مشتری عادی شروع کرد:

F-03 به‌تنهایی پایین است (CVSS v4 برابر ۲٫۳): لینک معرفی‌ای که مشتری با دیگران به اشتراک می‌گذارد، شناسه‌ی داخلی او را در خود دارد. F-05 به‌تنهایی متوسط است (۶٫۰): مسیری که ایمیل مشتری را عوض می‌کند شناسه‌ی هر مشتری را می‌پذیرد، ولی این شناسه‌ها حدس‌زدنی نیستند. کنار هم، شناسه‌ی لورفته به تغییر ایمیل می‌رسد، بازنشانی گذرواژه به نشانی مهاجم می‌رود و حساب تصاحب می‌شود: ۸٫۵، بالا، با امتیازدهی کل زنجیره. امتیاز هیچ‌کدام از این دو یافته به‌تنهایی به خلاصه‌ی مدیریتی نمی‌رسید؛ زنجیره می‌رسد.

۶. آنچه امتحان شد و جواب نداد

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

۷. شرایط آزمون مجدد

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

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

۸. پیوست‌هایی که در وقت صرفه‌جویی می‌کنند

خروجی اسکنرها، لاگ کامل درخواست‌ها، ابزارها و نسخه‌های استفاده‌شده، و یک خروجی ماشین‌خوان از یافته‌ها (CSV یا JSON) تا تیم فنی بتواند آن‌ها را به سامانه‌ی پیگیری خود وارد کند، نه این‌که دوباره تایپ کند. نسخه‌ی ماشین‌خوان لطف نیست؛ همان چیزی است که باعث می‌شود گزارش واقعاً پیگیری شود.

پرسش‌هایی که پیش از امضا باید بپرسید

۱. آیا گزارش می‌نویسد چه چیزی قابل آزمون نبود و چرا؟ ۲. پوشش آزمون به کدام استاندارد نگاشت می‌شود و آیا آن نگاشت را می‌بینم؟ ۳. آیا هر یافته شدتِ امتیازدهی‌شده با بردار، علت ریشه‌ای و مراحل بازتولید دارد؟ ۴. آیا آزمون مجدد وجود دارد و وضعیت‌ها چگونه گزارش می‌شوند؟ ۵. آیا یافته‌ها را در قالبی دریافت می‌کنم که سامانه‌ی پیگیری من بتواند وارد کند؟

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