شناسایی چیست و چرا کیفیت آزمون را تعیین میکند؟
شناسایی (Reconnaissance) مرحله‌ای است که در آن آزمونگر می‌فهمد با چه چیزی روبه‌روست: کدام دارایی‌ها وجود دارند، هر کدام چه فناوری‌ای دارند، چه نقاط ورودی‌ای در اختیار کاربر است و کدام بخش برنامه احتمالاً پرریسک‌ترین بخش است. در ساختار یک engagement، این همان مرحله‌ای است که سقف کیفیت کل آزمون را تعیین میکند: چیزی که کشف نشود، آزمون نمیشود.
تقسیم اصلی این مرحله بر یک معیار ساده استوار است — آیا به هدف ترافیک می‌فرستید یا نه؟
- شناسایی منفعل: داده از منابع ثالث می‌آید (لاگ‌های شفافیت گواهی، DNS منفعل، آرشیوهای وب، موتورهای جست‌وجو، مخازن عمومی). هدف متوجه نمیشود. این همان چیزی است که در OSINT شرح داده شده.
- شناسایی فعال: درخواست به هدف ارسال میشود — بررسی زندهبودن، انگشتنگاری سرور و فریم‌ورک، خزش، کشف محتوا و اسکن. در لاگ مشتری دیده میشود، ممکن است هشدار WAF یا IDS ایجاد کند، و به مجوز کتبی و پنجرهی زمانی توافقشده نیاز دارد.
این دو در هم تنیده‌اند: منفعل فهرست کاندیدها را می‌سازد، فعال آن‌ها را تأیید میکند.
نگاشت به WSTG-INFO: ده آزمون گردآوری اطلاعات
OWASP در راهنمای آزمون امنیت وب (WSTG) این مرحله را در بخش گردآوری اطلاعات با پیشوند شناسه‌ی WSTG-INFO جمع کرده است. این بخش ده آزمون سطح‌بالا با شناسه‌های WSTG-INFO-01 تا -10 دارد؛ جدول زیر حوزه‌های پوشش آن‌ها را گروه‌بندی میکند:
| حوزه‌ی آزمون | در عمل چه چیزی بررسی میشود |
|---|---|
| شناسایی از طریق موتورهای جست‌وجو | محتوایی که ایندکس شده و نباید عمومی باشد: فایل پیکربندی، صفحات خطا، اسناد داخلی |
| انگشتنگاری وب‌سرور | نوع و نسخه‌ی سرور از هدرها، رفتار خطا و ترتیب هدرها |
| بررسی فایل‌های متا | robots.txt، sitemap.xml، security.txt و مسیرهایی که این فایل‌ها لو می‌دهند |
| شمارش برنامه‌ها روی یک سرور | چند برنامه روی یک میزبان، میزبانی مجازی، مسیرهای فرعی و پورت‌های غیرمتعارف |
| نشت اطلاعات در محتوای صفحه | کامنت‌های HTML، جاوااسکریپت بسته‌بندی‌شده، sourcemap، کلیدهای جاسازی‌شده |
| شناسایی نقاط ورودی | هر پارامتر، هدر، کوکی، فیلد فرم، بدنه‌ی JSON و مسیر آپلود |
| نگاشت مسیرهای اجرا | جریان‌های چندمرحله‌ای، گردش‌کارها و مسیرهای شرطی برنامه |
| انگشتنگاری فریم‌ورک برنامه | فریم‌ورک سمت سرور و سمت کلاینت، نسخه و کتابخانه‌های ثالث |
| نگاشت معماری برنامه | وجود WAF، متعادل‌کننده‌ی بار، CDN، دروازه‌ی API و سرویس‌های پشتی |
نسخه‌ی پایدار جاری WSTG نسخه‌ی 4.2 (۳ دسامبر ۲۰۲۰) است و نسخه‌ی ۵٫۰ در حال توسعه؛ جزئیات در متدولوژی تست نفوذ آمده است.
زنجیرهی عملی: subfinder ← httpx ← katana ← nuclei
الگوی متداول و مؤثر امروز، زنجیره‌ای از ابزارهای تک‌کاره است که خروجی هرکدام ورودی بعدی میشود:
subfinder -d example.com -all -silent > subs.txt
httpx -l subs.txt -sc -title -tech-detect > live.txt
katana -list live.txt -jc -d 3 -o urls.txt
nuclei -l live.txt -severity critical,high -tags cve,exposure- subfinder — کشف منفعل زیردامنه از منابع متعدد. هیچ ترافیکی به هدف نمی‌رود.
- httpx — بررسی زندهبودن، کد وضعیت، عنوان، داده‌ی TLS و تشخیص فناوری. این نخستین گام فعال است.
- katana — خزنده با پشتیبانی حالت headless؛ اندپوینت‌ها و پارامترها را از HTML و جاوااسکریپت بیرون میکشد.
- nuclei — تطبیق الگو‌محور برای CVE شناختهشده، پنل‌ها و فایل‌های افشاشده و پیکربندی نادرست.
دو نکته: نخست، Nuclei یک تطبیق‌دهنده‌ی امضاست، نه اسکنر منطق‌آگاه؛ IDOR، نقص منطق کسبوکار و تزریق نوظهور را پیدا نمی‌کند. دوم، خروجی ابزارهای مبتنی بر آرشیو ماهیتاً تاریخی است و بخش بزرگی از URLها امروز ۴۰۴ می‌دهند؛ همیشه باید از httpx عبور کنند — در عوض می‌توانند اندپوینت‌هایی را نشان دهند که عمداً حذف شده‌اند. برای کشف محتوای فعال، ffuf ابزار مرحله‌ی بعد است.
از شناسایی به سطح حمله و سپس اولویت‌بندی
خروجی خام شناسایی یک فهرست است؛ ارزش واقعی در تبدیل آن به یک مدل سطح حمله و بعد به یک ترتیب کار است:
- دارایی‌ها: هر میزبان زنده با مالک، محیط (تولید/تست) و فناوری‌اش برچسب می‌خورد.
- نقاط ورودی: هر پارامتر، هدر، کوکی و بدنه‌ی درخواست که کاربر بر آن اثر دارد فهرست میشود. این فهرست، دامنه‌ی واقعی آزمون است.
- مرزهای اعتماد: کجا کاربر ناشناس به کاربر احراز هویت‌شده تبدیل میشود، کجا نقش عوض میشود، کجا داده به سرویس دیگری منتقل میشود.
- اولویت‌بندی: بر پایه‌ی احتمال و اثر.
آنچه در عمل ابتدا آزمون میشود: احراز هویت و بازیابی رمز، هر مسیر آپلود فایل، پنل‌های مدیریتی و مسیرهای بی‌لینک، اندپوینت‌هایی که شناسه‌ی شیء میگیرند (کاندید IDOR)، جریان‌های مالی چندمرحله‌ای (کاندید شرایط مسابقه)، هر جا که سرور به‌جای کاربر درخواست بیرونی میفرستد (کاندید SSRF)، و کامپوننت‌های ثالث قدیمی. مدل‌سازی تهدید همین اولویت‌بندی را ساخت‌یافته انجام میدهد.
اشتباهات رایج در مرحله‌ی شناسایی
«شناسایی یعنی گرفتن فهرست زیردامنه‌ها.» فهرست زیردامنه فقط اولین لایه است. آنچه نتیجه‌ی آزمون را تغییر میدهد، نگاشت نقاط ورودی و مسیرهای اجرا است: کدام پارامتر به کدام عملیات می‌رسد، کدام نقش به کدام اندپوینت دسترسی دارد و جریان چندمرحله‌ای کجا وضعیت را نگه می‌دارد. آزمونگری که ده هزار زیردامنه دارد اما نقشه‌ی نقاط ورودی برنامهی اصلی را ندارد، شناسایی نکرده است.
سه اشتباه دیگر که مرتب دیده میشود:
- گسترش دامنه بدون تأیید: هر زیردامنه‌ی کشف‌شده لزوماً دارایی مشتری نیست. آزمون میزبان اشتراکی، CDN یا سرویس تأمین‌کننده‌ی ثالث بدون مجوز، تخلف است. فهرست باید پیش از مرحله‌ی فعال تأیید شود — بندی که در قرارداد تست نفوذ جای دارد.
- اسکن پرسرعت روی محیط عملیاتی: پروفایل‌های زمانی تهاجمی و اجرای کل مجموعه‌ی قالب‌ها بدون فیلتر، هم پرسروصداست و هم می‌تواند سرویس شکننده را بی‌ثبات کند. فیلتر بر پایه‌ی برچسب و شدت، و هماهنگی پنجرهی زمانی، بخشی از حرفه‌ای بودن است.
- اعتماد به تشخیص خودکار فناوری: تشخیص نسخه از هدرها اغلب نادرست یا عمداً گمراه‌کننده است. نسخه‌ی گزارش‌شده باید با شاهد دوم تأیید شود، وگرنه یافته‌ی CVE شما مثبت کاذب است.
پرسش‌های متداول
تفاوت شناسایی منفعل و فعال چیست؟
معیار تفکیک، ارسال ترافیک به هدف است. شناسایی منفعل داده را از منابع ثالث میگیرد و هدف متوجه نمیشود. شناسایی فعال درخواست به هدف میفرستد — بررسی زندهبودن، انگشتنگاری، خزش، کشف محتوا — در لاگ دیده میشود و به مجوز کتبی و پنجرهی زمانی توافقشده نیاز دارد.
شناسایی در یک تست نفوذ وب چقدر طول میکشد؟
به اندازهی سطح حمله بستگی دارد، اما یک قاعدهی عملی وجود دارد: شناسایی و نگاشت نقاط ورودی معمولاً سهم قابل توجهی از زمان engagement را میگیرد و کوتاه کردن آن مستقیماً کیفیت یافتهها را پایین میآورد. برای یک برنامهی تکدامنه ممکن است چند ساعت باشد؛ برای سازمانی با دهها دارایی، چند روز.
ابزارهای شناسایی جای آزمون دستی را میگیرند؟
نه. زنجیرهی subfinder ← httpx ← katana ← nuclei سطح حمله را پیدا میکند و CVE و افشاهای شناختهشده را نشان میدهد. اما کنترل دسترسی، IDOR و منطق کسبوکار — یعنی پرارزشترین یافتهها — امضا ندارند و فقط با کار دستی کشف میشوند.
برای شناسایی از چه واژهنامهای استفاده کنیم؟
برای کشف محتوا، مجموعههای SecLists نقطهی شروع استانداردند؛ فهرستهای خانوادهی raft و directory-list-2.3-medium بازده بهتری از فهرست کوچک common.txt دارند. مؤثرتر از هر فهرست عمومی، ساخت واژهنامهی اختصاصی از خودِ برنامه است: نام پارامترها و مسیرهای موجود در جاوااسکریپت و پاسخ API.