این مقاله همان چیزی است که ما در یک پروژه‌ی تست نفوذ وب واقعاً انجام می‌دهیم — به ترتیب، با نام آزمون‌ها و نام ابزارها، و با صراحت درباره‌ی اینکه هر مرحله چه چیزی را پیدا میکند و چه چیزی را نه. ساختار آن بر پایه‌ی راهنمای آزمون امنیت وب OWASP یعنی WSTG v4.2 است: ۱۲ دسته و حدود ۹۷ آزمون نام‌گذاری‌شده. اگر پیمانکار انتخاب می‌کنید، این متن می‌گوید چه چیزی را از او بخواهید؛ اگر توسعه‌دهنده‌اید، می‌گوید آزمونگر به کجای برنامه‌ی شما نگاه میکند.
در یک نگاه
- پوشش آزمون با WSTG v4.2 (منتشرشده در ۳ دسامبر ۲۰۲۰) بیان میشود: ۱۲ دسته و حدود ۹۷ آزمون با شناسه‌ی مشخص.
- بزرگ‌ترین دسته WSTG-INPV با ۱۹ آزمون است، اما پرخطرترین یافته‌ها معمولاً از WSTG-ATHZ و WSTG-BUSL بیرون می‌آیند.
- ابزارها فقط پوشش سطحی می‌دهند؛ Burp Community هیچ اسکنری ندارد و Caido هم اسکنر و سرویس OAST ندارد.
- تحویل نهایی شامل گزارش پوششی، امتیازدهی
CVSSو یک آزمون مجدد پس از رفع است.
گام صفر: تعیین دامنه و قواعد تعامل
هیچ آزمونی پیش از امضای مجوز کتبی شروع نمی‌شود. سند قواعد تعامل (Rules of Engagement) باید صریح باشد:
- دامنه‌ی دقیق: فهرست دامنهها، اندپوینت‌های API و محدوده‌ی IP. هر چیزی که در فهرست نیست، خارج از دامنه است.
- نقشها و اعتبارنامه‌ها: برای هر نقش حداقل دو حساب؛ آزمون کنترل دسترسی افقی بدون دو حساب هم‌سطح ممکن نیست.
- محیط: عملیاتی یا پیشعملیاتی — و در حالت دوم، تأیید همسانی کد و پیکربندی با عملیاتی.
- ممنوعیت‌ها: آزمون منع سرویس، مهندسی اجتماعی و عملیات تخریبی، پیش‌فرض خارج از دامنه.
- پنجره‌ی زمانی و IP مبدأ: تا تیم عملیات ترافیک آزمون را با حمله‌ی واقعی اشتباه نگیرد.
- مسیر تشدید: اگر یافته‌ی بحرانی یا نشانه‌ی رخنه‌ی قبلی پیدا شد، چه کسی مطلع میشود.
«دامنه را باز بگذاریم تا آزمونگر آزادتر باشد.» عکس آن درست است: دامنه‌ی مبهم باعث میشود بودجه‌ی زمانی روی دارایی‌های کم‌اهمیت پخش شود و سامانه‌ی اصلی سطحی آزموده شود. دامنه‌ی مضیق و عمیق تقریباً همیشه یافته‌ی ارزشمندتری تولید میکند. دامنه‌ی مبهم مسئولیت حقوقی هم می‌سازد: سرویس شخص ثالثی که مالکش نیستید، بدون اجازه‌ی مالک قابل آزمون نیست.
شناسایی و نگاشت سطح حمله (WSTG-INFO)
دسته‌ی WSTG-INFO با ۱۰ آزمون به یک پرسش پاسخ میدهد: سطح حمله واقعاً چیست، نه آنچه مستندات می‌گوید.
- کشف زیردامنه: شمارش غیرفعال با
subfinderو برای عمق بیشترamass؛ سپس زنده‌بودن و اثر انگشت فناوری باhttpx. - آدرس‌های تاریخی:
gauآدرس‌ها را از Wayback Machine، Common Crawl، AlienVault OTX و URLScan جمع میکند و اندپوینت‌هایی را لو میدهد که تیم توسعه فکر میکند حذف شده‌اند. - خزش:
katanaبا حالت headless برای برنامه‌های تک‌صفحه‌ای، به‌علاوه‌ی خزش دستی از طریق پروکسی. - بازبینی محتوا: جاوااسکریپت باندل‌شده گنجینه است — اندپوینت، کلید API، پرچم قابلیت، نام نقشها. فایل‌های
.mapجامانده در محیط عملیاتی درخت کد اصلی را بازسازی می‌کنند. - متافایل‌ها:
robots.txt،sitemap.xml،security.txtو جست‌وجوی هدفمند در ایندکس موتورهای جست‌وجو. - سرویسهای غیرمنتظره:
nmap -sVروی درگاه‌های غیراستاندارد (۸۰۸۰، ۸۴۴۳، ۹۰۰۰) برای یافتن پنل‌ها و محیط‌های آزمایشی فراموش‌شده.
خروجی این مرحله یک فهرست است، نه یافته. تفکیک شناسایی غیرفعال و فعال در دانشنامه‌ی شناسایی آمده است.
پیکربندی و استقرار (WSTG-CONF)
دسته‌ی WSTG-CONF با ۱۱ آزمون: رایج‌ترین و ارزان‌ترین یافته‌ها اینجا هستند — ارزان چون رفعشان تغییر کد نمی‌خواهد. صعود A02:2025 پیکربندی نادرست از رتبه‌ی ۵ به ۲ بازتاب همین واقعیت است.
- فایل‌های قدیمی و پشتیبان:
config.php.bak،.env،.git/، فایل فشرده‌ی استقرار — باffufیاferoxbusterو فهرست‌هایSecLists. - واسط مدیریتی: پنل ادمین بدون محدودیت شبکه یا با اعتبارنامه‌ی پیش‌فرض.
- متدهای HTTP: فعال بودن
PUTیاTRACEو رفتار برنامه در برابر متدهای غیرمنتظره. - هدرهای امنیتی:
Strict-Transport-Security، سیاست ارجاع‌دهنده و سیاست امنیت محتوا. - تصاحب زیردامنه: رکورد DNS به سرویسی اشاره میکند که دیگر تخصیص داده نشده.
- ذخیره‌سازی ابری: باکت با دسترسی عمومی یا فهرست‌شدن محتوا.
ابزار مناسب این مرحله nuclei است: تطبیق‌دهنده‌ی الگو با حدود ۱۲٬۰۰۰ قالب (سنجش‌شده در مرداد ۱۴۰۵)، عالی برای CVE شناخته‌شده، پنل افشاشده و پیکربندی نادرست. اما منطق نمی‌فهمد و اجرای کل قالب‌ها روی هدف عملیاتی کند و پرصداست — با -tags و -severity فیلتر کنید.
هویت، احراز هویت، مجوزدهی و نشست
چهار دسته‌ی WSTG که بیشترین سهم را در یافتههای پرخطر دارند:
| دسته | تعداد آزمون | نمونه‌ی آزمونهای کلیدی |
|---|---|---|
| WSTG-IDNT — مدیریت هویت | ۵ | تعریف نقشها، فرایند ثبت‌نام، تخصیص حساب، شمارش حساب (WSTG-IDNT-04) |
| WSTG-ATHN — احراز هویت | ۱۰ | اعتبارنامه روی کانال رمزنشده، اعتبارنامه‌ی پیش‌فرض، قفل ضعیف حساب، دور زدن طرح احراز هویت (۰۴)، بازیابی رمز، احراز هویت ضعیف‌تر در کانال جایگزین (۱۰) |
| WSTG-ATHZ — مجوزدهی | ۴ | پیمایش مسیر (۰۱)، دور زدن طرح مجوزدهی (۰۲)، ارتقای سطح دسترسی (۰۳)، IDOR (WSTG-ATHZ-04) |
| WSTG-SESS — مدیریت نشست | ۹ | طرح نشست (۰۱)، ویژگی کوکی (۰۲)، تثبیت نشست (۰۳)، CSRF (WSTG-SESS-05)، خروج (۰۶)، انقضا (۰۷)، سرگردانی نشست (۰۸) |
روش عملی در دسته‌ی ATHZ: هر درخواست حساس را با سه وضعیت تکرار کنید — بدون توکن، با توکن کاربر هم‌سطح، و با توکن کاربر کم‌دسترس‌تر — و پاسخ‌ها را مقایسه کنید. تفاوت در بدنه، کد وضعیت یا حتی طول پاسخ نشانه است؛ توضیح فنی در دانشنامه‌ی IDOR. در دسته‌ی ATHN نکته‌ی مهم کانال‌های جایگزین است: اپلیکیشن موبایل، API یا ورود با کد یک‌بارمصرف اغلب سخت‌گیری کم‌تری از فرم وب دارند — همان حساب، ضعیف‌ترین درِ ورودش را به مهاجم میدهد.
«مرورگرها پیش‌فرض SameSite=Lax می‌گذارند، پس CSRF حل شده است.» کروم چنین میکند، اما فایرفاکس نه — این قابلیت در فایرفاکس ۹۶ عرضه و به‌دلیل خرابی سایت‌ها برگردانده شد و باگ مربوطه WONTFIX بسته شده. سافاری سازوکار متفاوتی دارد. تغییر وضعیت با GET، پارامترهای بازنویسی متد و زیردامنه‌های هم‌سایت هم Lax را دور می‌زنند. توکن CSRF سمت سرور همچنان الزامی است.
اعتبارسنجی ورودی، مدیریت خطا و رمزنگاری
WSTG-INPV با ۱۹ آزمون بزرگ‌ترین دسته است: XSS بازتابی و ذخیره‌شده، دستکاری متد HTTP، آلودگی پارامتر، تزریق SQL (با ۸ زیرآزمون مخصوص Oracle، MySQL، SQL Server، PostgreSQL، NoSQL، ORM و سمت کلاینت)، تزریق LDAP/XML/XPath، تزریق کد (با زیرآزمون‌های LFI و RFI)، تزریق دستور، قاچاق HTTP، تزریق هدر Host، SSTI و SSRF (آزمون شماره ۱۹ همین دسته).
روش کار: هر نقطه‌ی ورودی — پارامتر پرس‌وجو، بدنه، هدر، کوکی، نام فایل آپلود، مقدار JSON تودرتو — با نشانگر کنترل‌شده تحریک و رفتار خوانده میشود. برای تزریق SQL، جریان کار حرفه‌ای این است که نقطه‌ی تزریق دستی پیدا شود و بعد درخواست ذخیره‌شده به sqlmap -r داده شود، نه حدس‌زدن با -u.
id=1' AND (SELECT 1 FROM (SELECT SLEEP(3))x)-- -
# 3s delay => time-based blind SQLi candidateدو دسته‌ی کوچک اما پرارزش هم اینجا می‌آیند: WSTG-ERRH (۲ آزمون: مدیریت نادرست خطا و Stack Trace) که به دسته‌ی جدید A10:2025 مربوط است، و WSTG-CRYP (۴ آزمون: TLS ضعیف، اوراکل پدینگ، دادهی حساس روی کانال رمزنشده، رمزنگاری ضعیف) که با testssl.sh یا sslyze آزموده میشود.
«از React استفاده می‌کنیم پس XSS نداریم.» فرار خودکار فقط در درج متن اعمال میشود. dangerouslySetInnerHTML، v-html، href با مقدار javascript:، تزریق قالب سمت کلاینت، رندر سمت سرور و ابزارک‌های آلودگی پروتوتایپ همه باقی می‌مانند. مستندات خود React می‌گوید ایجاد آسیب‌پذیری XSS از این راه «بدیهی و ساده» است.
منطق کسبوکار (WSTG-BUSL) — بخشی که هیچ ابزاری پوشش نمی‌دهد
دسته‌ی WSTG-BUSL نُه آزمون دارد و ارزش واقعی آزمونگر انسانی اینجا مشخص میشود، چون باید قصد فرایند را فهمید — چیزی که در کد نوشته نشده.
- اعتبارسنجی داده (۰۱): تعداد منفی کالا، تخفیف ۱۲۰ درصد، تاریخ گذشته.
- جعل درخواست (۰۲): ساخت درخواستی که رابط کاربری هرگز تولید نمی‌کند.
- بررسی یکپارچگی (۰۳): تغییر فیلدی که سرور بازاعتبارسنجی نمی‌کند — قیمت، سطح اشتراک.
- زمان‌بندی فرایند (۰۴): شرایط مسابقه — مثلاً درخواست هم‌زمان برای استفاده‌ی چندباره از یک کد تخفیف. با حمله‌ی تک‌بسته‌ای روی HTTP/2 این کلاس دیگر «نیازمند شبکه‌ی سریع» نیست؛ تفصیل در دانشنامه‌ی شرایط مسابقه.
- محدودیت استفاده (۰۵): استفاده‌ی نامحدود از عملیاتی که باید سهمیه داشته باشد.
- دور زدن جریان کار (۰۶): پرش از مرحله‌ی پرداخت، یا رفتن مستقیم به مرحله‌ی تأیید.
- مقاومت در برابر سوءاستفاده (۰۷): آیا برنامه رفتار غیرعادی مکرر را تشخیص میدهد؟
- آپلود نوع غیرمنتظره (۰۸) و فایل مخرب (۰۹): از
SVGحاوی اسکریپت تا پسوند دوگانه.
این دسته با A06:2025 طراحی ناامن هم‌پوشان است؛ به تعبیر OWASP: «یک طراحی ناامن را هیچ پیاده‌سازی بی‌نقصی نمی‌تواند اصلاح کند.»
سمت کلاینت (WSTG-CLNT)
WSTG-CLNT با ۱۳ آزمون: XSS مبنی بر DOM (۰۱)، اجرای جاوااسکریپت (۰۲)، تزریق HTML (۰۳)، تغییر مسیر سمت کلاینت (۰۴)، تزریق CSS (۰۵)، دستکاری منابع (۰۶)، CORS (۰۷)، Cross-Site Flashing (۰۸)، Clickjacking (۰۹)، WebSockets (۱۰)، postMessage (۱۱)، ذخیره‌سازی مرورگر (۱۲) و XSSI (۱۳).
ابزار کلیدی این بخش DOM Invader است — افزونه‌ی پیش‌نصب در مرورگر داخلی Burp Suite که یک نشانگر تزریق میکند و می‌گوید کدام سینک آن را دریافت کرده و چه پاک‌سازی‌هایی در مسیر اعمال شده. آزمون postMessage، آلودگی پروتوتایپ سمت کلاینت و DOM Clobbering را هم پوشش میدهد. نکته‌ای که محتوای فارسی زیاد اشتباه می‌گوید: DOM Invader در نسخه‌ی Community هم موجود است، نه فقط Professional.
در ذخیره‌سازی مرورگر دو چیز همیشه بررسی میشود: پرچم‌های کوکی (HttpOnly، Secure، SameSite، پیشوندهای __Host- و __Secure-) و محتوای localStorage — جایی که توکن JWT مرتباً پیدا میشود و نباید باشد، چون با XSS خواندنی است.
Access-Control-Allow-Origin: * به‌خودی‌خود معمولاً بحرانی نیست، چون مرورگر با مبدأ عام اعتبارنامه نمی‌فرستد. الگوی واقعاً بحرانی بازتاب مبدأ همراه با Access-Control-Allow-Credentials: true است. CORS سیاست هم‌مبدأ را سست میکند و هیچ‌گاه حفاظت اضافه نمی‌کند.
زنجیره‌ی ابزار، صادقانه
ابزار مهم است اما تعیین‌کننده نیست. ترکیبی که در عمل استفاده میشود، با محدودیت واقعی هر مورد:
| ابزار | نقش | محدودیت واقعی |
|---|---|---|
| Burp Suite Professional | پروکسی، Repeater، Intruder، Scanner، Collaborator | اشتراک است نه خرید یک‌باره؛ اسکنرش باگ منطقی پیدا نمی‌کند |
| Burp Suite Community | پروکسی، Repeater، Decoder، DOM Invader | اسکنر ندارد، Collaborator ندارد، Intruder فقط نسخه‌ی نمایشی و کندشده |
| Caido | پروکسی و جریان کار دستی، Workflows | پیش از نسخه‌ی ۱٫۰، متن‌باز نیست، اسکنر و OAST ندارد |
| ZAP (ZAP by Checkmarx) | اسکن خودکار، مناسب CI/CD | پرصداتر از Burp؛ نام «OWASP ZAP» از سپتامبر ۲۰۲۳ منسوخ |
| ffuf / feroxbuster | کشف محتوا و فازینگ پارامتر | ffuf از سپتامبر ۲۰۲۳ نسخه‌ی جدید نداشته؛ پایدار، اما «مداوم به‌روز» نیست |
| Nuclei | تطبیق قالب برای CVE و پیکربندی نادرست | منطق نمی‌فهمد؛ نرخ خطای مثبت تابع کیفیت قالب است |
| sqlmap | بهرهبرداری تزریق SQL پس از کشف دستی | روی NoSQL و بیشتر تزریق‌های ORM بی‌اثر است |
دو ابزاری که فهرست‌های فارسی زیاد اشتباه معرفی می‌کنند: Metasploit چارچوب بهرهبرداری شبکه و میزبان است و در تست نفوذ وب نقش محدودی دارد (CVE شناخته‌شده در پشته، تولید پیلود با msfvenom، پس از بهرهبرداری). Nikto هم اسکنر وب‌سرور قدیمی است: پرصدا و ناتوان در درک برنامه‌های تک‌صفحه‌ای و API. مقایسه‌ی کامل در ابزارهای تست نفوذ.
گزارش، رفع و آزمون مجدد
WSTG بخش مستقلی برای گزارش‌دهی دارد: یافته‌ای که قابل بازتولید و رفع نباشد ارزش عملیاتی ندارد. هر یافته باید داشته باشد:
- محل دقیق: اندپوینت، متد، پارامتر، نقش.
- گام‌های بازتولید، به‌گونه‌ای که توسعه‌دهنده بدون کمک ما آن را تکرار کند.
- شاهد: درخواست و پاسخ خام، بدون دادهی حساس.
- شدت با CVSS v4.0 (یا
v3.1اگر ابزار انطباق کارفرما آن را می‌خواهد)، با ذکر صریح گروه سنجه‌ی مبنا. - نگاشت به شناسه‌ی WSTG، دسته‌ی OWASP Top 10:2025 و شناسه‌ی CWE.
- راهکار رفع مشخص در سطح کد یا پیکربندی — نه «WAF نصب کنید».
بخشی که اغلب حذف میشود و نباید، گزارش پوشش است: کدام آزمونهای WSTG اجرا شدند و کدام‌ها قابل اجرا نبودند و چرا. همین بخش است که مقایسه‌ی گزارش دو پیمانکار را ممکن میکند. ساختار کامل در گزارش تست نفوذ.
پس از رفع، آزمون مجدد انجام میشود و این مرحله اختیاری نیست: بند ۱۱٫۴٫۴ در PCI DSS v4.0.1 تصریح میکند آسیب‌پذیری قابل بهرهبرداری باید رفع و آزمون تکرار شود. برای حفظ وضعیت بین دو پروژه، چک‌لیست تست نفوذ را در فرایند انتشار بگذارید؛ و اگر می‌خواهید این متدولوژی روی سامانه‌ی خودتان اجرا شود، تست نفوذ وب پی‌هانتر نقطه‌ی شروع است.
پرسش‌های متداول
تست نفوذ وب چه تفاوتی با تست نفوذ شبکه دارد؟
لایهی آزمون متفاوت است. تست نفوذ شبکه روی سرویسهای در معرض دید، نسخهها و تفکیک شبکه تمرکز دارد. تست نفوذ وب روی منطق و کد برنامه کار میکند: کنترل دسترسی، احراز هویت، نشست، اعتبارسنجی ورودی و فرایندهای چندمرحلهای. یک سرور کاملاً وصلهشده میتواند برنامهای با نقص کنترل دسترسی بحرانی میزبانی کند و اسکن شبکه آن را نمیبیند.
آیا WSTG v4.2 قدیمی نیست؟
WSTG v4.2 در ۳ دسامبر ۲۰۲۰ منتشر شده، پس بیش از پنج سال از آن گذشته و باید صادقانه گفت. اما همچنان نسخه‌ی پایدار جاری است: v4.3 منتشر نشده و v5.0 در حال توسعه است. رویکرد حرفه‌ای این است که WSTG چک‌لیست پوشش باشد و برای موضوعاتی که پوشش نمی‌دهد — مثل API مدرن — مرجع مکمل بیاوریم.
برای تست نفوذ وب چه چیزی باید آماده کنم؟
پنج چیز: فهرست دقیق دامنهها و اندپوینتها؛ حداقل دو حساب برای هر نقش؛ مشخصکردن محیط و تأیید همسانی آن با عملیاتی؛ یک شخص تماس فنی در دسترس؛ و فهرست عملیات ممنوع. اگر فایل OpenAPI دارید آن را هم بدهید — پوشش را محسوس بالا میبرد.
آیا تست نفوذ وب روی سایت عملیاتی امن است؟
با قواعد تعامل درست، بله. آزمونهای مخرب خارج از دامنهاند، بهرهبرداری تا حد اثبات انجام میشود، نرخ درخواست کنترل میشود و کانالی برای توقف فوری وجود دارد. برای سامانههای حساس، محیط پیشعملیاتی با دادهی مصنوعی مرجح است — به شرط همسانی کد و پیکربندی با عملیاتی.
چرا آزمون احراز هویتشده مهمتر از آزمون بدون ورود است؟
چون بخش عمدهی سطح حمله پس از ورود کاربر قرار دارد. آزمون بدون احراز هویت فقط بخش عمومی را میبیند و IDOR، ارتقای سطح دسترسی و بیشتر یافتههای منطق کسبوکار را از دست میدهد. اگر بودجه محدود است، دامنه را کوچکتر کنید ولی آزمون را احراز هویتشده و با همهی نقشها اجرا کنید.
منابع
علیرضا کیا
متخصص تست نفوذ وب و اندروید با سابقه‌ی مدیریت تیم نفوذ در داتین. مهندسی معکوس اپ‌ها و کشف ذخیره‌سازی ناامن، تخصص اوست.