«تست نفوذ» (Penetration Testing) در بازار ایران به هر چیزی گفته میشود: از اجرای یک اسکنر رایگان روی دامنه تا یک پروژه‌ی چندهفته‌ای با گزارش فنی. این ابهام برای خریدار گران تمام میشود، چون فاکتور دو سرویس کاملاً متفاوت شبیه هم به نظر می‌رسد. این مقاله تعریف دقیق تست نفوذ را میدهد، مرز آن را با اسکن آسیبپذیری و ارزیابی امنیتی روشن میکند، مراحل واقعی یک پروژه‌ی پن تست وب را شرح میدهد و در پایان می‌گوید مشتری در انتهای کار دقیقاً چه چیزی تحویل میگیرد.
در یک نگاه
- تست نفوذ یک حملهی شبیهسازیشده و مجاز با هدف اثبات بهره‌برداری‌پذیری است، نه فهرست‌کردن هشدارهای یک ابزار.
- اسکن آسیبپذیری خودکار است و الگو تشخیص میدهد؛ تست نفوذ دستی است و زنجیره‌ی سوءاستفاده می‌سازد.
- پرحجم‌ترین و پرخطرترین یافتهها در دسته‌ی A01:2025 کنترل دسترسی شکسته و A06:2025 طراحی ناامن هستند — همان دو دسته‌ای که ابزار خودکار تقریباً کور است.
- خروجی پروژه یک PDF نیست؛ یک گزارش با گام‌های بازتولید، شدت امتیازدهی‌شده با
CVSS، راهکار رفع و یک آزمون مجدد است. - بدون مجوز کتبی و دامنه‌ی مشخص، کار انجام‌شده تست نفوذ نیست.
تست نفوذ چیست؟ تعریف دقیق
تست نفوذ عبارت است از ارزیابی امنیتی یک سامانه با شبیه‌سازی رفتار مهاجم واقعی، در چارچوب یک مجوز کتبی و یک دامنه‌ی توافق‌شده، با هدف کشف و اثبات مسیرهای عملی سوءاستفاده و سنجش تأثیر آن‌ها بر کسبوکار. سه واژه در این تعریف بار اصلی را می‌کشند:
- مجاز: بدون نامه‌ی اجازه‌ی آزمون و دامنه‌ی مکتوب، همان فعالیت از منظر حقوقی دسترسی غیرمجاز است. امضای قرارداد و مجوز آزمون اولین قدم هر پروژه است، نه یک تشریفات اداری.
- اثبات: تست نفوذ ادعا نمیکند «این پارامتر ممکن است آسیب‌پذیر باشد»؛ نشان میدهد که با این درخواست مشخص، این دادهی مشخص بیرون آمد. تفاوت میان «احتمال» و «اثبات» همان تفاوت میان اسکن و تست نفوذ است.
- تأثیر: یافته‌ای که تأثیرش بر داده و فرایند کسبوکار توضیح داده نشود، برای مدیر قابل تصمیم‌گیری نیست. یک XSS در صفحه‌ی «درباره‌ی ما» و همان XSS در پنل مدیریت، دو ریسک کاملاً متفاوت‌اند.
در حوزه‌ی برنامه‌های وب — تمرکز اصلی ما در سرویس تست نفوذ وب — این تعریف یک لایه دقیق‌تر میشود: آزمونگر با ترافیک HTTP کار میکند، وضعیت نشست و نقش کاربر را دستکاری میکند، منطق چندمرحلهای فرایندها را می‌شکند و مرزهای اعتماد میان کلاینت، سرور و سرویس‌های پشتی را می‌آزماید.
هر سه یک چیز هستند. «پن تست» کوتاه‌شده‌ی محاوره‌ای است و در گزارش رسمی بهتر است «تست نفوذ» نوشته شود. اصطلاح «هک قانونی» را در اسناد حرفه‌ای به کار نبرید؛ عبارت پذیرفته‌شده در قرارداد و ممیزی، «تست نفوذ» یا «آزمون امنیتی» است.
تفاوت تست نفوذ با اسکن آسیبپذیری، ارزیابی امنیتی و تیم سرخ
این چهار سرویس نه مترادف‌اند و نه جایگزین یکدیگر. هرکدام پرسش متفاوتی را پاسخ می‌دهند:
| سرویس | پرسشی که پاسخ میدهد | روش | خروجی |
|---|---|---|---|
| اسکن آسیبپذیری | چه ضعفهای شناخته‌شده‌ای قابل تشخیص خودکار هستند؟ | تمام‌خودکار، مبتنی بر امضا و الگو | فهرست هشدار، نیازمند غربال دستی |
| ارزیابی آسیبپذیری | همان، اما پس از حذف خطای مثبت و اولویت‌بندی | خودکار + بازبینی انسانی | فهرست تأییدشده و اولویت‌دار |
| ارزیابی امنیتی | وضعیت کلی امنیت من کجاست و از کجا شروع کنم؟ | مصاحبه، بازبینی پیکربندی و معماری، اسکن | نقشه‌ی راه و شکاف‌ها |
| تست نفوذ | مهاجم واقعاً تا کجا می‌تواند پیش برود؟ | عمدتاً دستی، با بهرهبرداری کنترل‌شده | یافته‌ی اثباتشده با گام بازتولید |
| تیم سرخ (Red Team) | آیا تیم مدافع من این حمله را می‌بیند؟ | سناریومحور، پنهان‌کار، بلندمدت | ارزیابی توان تشخیص و پاسخ |
تفاوت کلیدی تست نفوذ و تیم سرخ در هدف است، نه در مهارت: تست نفوذ میخواهد پوشش بدهد و تا جای ممکن آسیبپذیری پیدا کند؛ تیم سرخ میخواهد یک سناریوی خاص را بدون شناسایی‌شدن اجرا کند تا توان تشخیص سازمان سنجیده شود. سازمانی که هنوز پایش و لاگ ندارد، از تیم سرخ چیزی جز یک نتیجه‌ی از پیش معلوم به دست نمی‌آورد. تفکیک کامل این سرویس‌ها را در مقاله‌ی ارزیابی امنیتی و تفاوت آن با تست نفوذ آورده‌ایم.
«اسکنر ما هفته‌ای یکبار اجرا میشود، پس تست نفوذ لازم نداریم.» اسکنر یک ابزار پوشش پایه است و جای آن در خط لوله‌ی توسعه است، نه جای تست نفوذ. اسکنر ساختاراً نمی‌تواند تشخیص دهد که کاربر «الف» مجاز به دیدن سفارش کاربر «ب» نیست — چون مفهوم «مجاز» را نمی‌فهمد. همین یک کلاس آسیبپذیری، در دادهی OWASP در ۱۰۰٪ برنامه‌های آزموده‌شده وجود داشته است.
مراحل تست نفوذ وب
چرخه‌ی یک پروژه‌ی تست نفوذ وب هفت مرحله دارد. این تقسیم‌بندی با فازهای PTES و ساختار سه‌مرحله‌ای NIST SP 800-115 (برنامه‌ریزی ← اجرا ← پس از اجرا) هم‌راستاست:
- پیش‌تعامل و تعیین دامنه: فهرست دارایی‌های در دامنه، نقشهای کاربری، محدودیت‌ها، پنجرهی زمانی آزمون و کانال اطلاع فوری یافته‌های بحرانی.
- شناسایی (Reconnaissance): نگاشت سطح حمله — زیردامنه‌ها، فناوری‌ها، اندپوینتهای فراموش‌شده، فایل‌های پشتیبان، جاوااسکریپت باندل‌شده و نقشه‌ی منبع (sourcemap).
- نگاشت برنامه: عبور از همهی جریان‌های کاربری با پروکسی میان‌راهی برای ساخت درخت واقعی برنامه — نه آنچه مستندات می‌گوید.
- کشف آسیبپذیری: ترکیب اسکن خودکار برای پوشش سطحی و آزمون دستی برای کنترل دسترسی، احراز هویت، نشست، اعتبارسنجی ورودی و منطق کسبوکار.
- بهرهبرداری کنترل‌شده: اثبات یافته با کم‌ترین اثر مخرب. هدف نمایش قابلیت است، نه ایجاد خرابی؛ هیچ داده‌ای حذف یا تخریب نمی‌شود.
- پس از بهرهبرداری: بررسی اینکه یک نقطه‌ی رخنه تا کجا گسترش می‌یابد — ارتقای سطح دسترسی، دسترسی افقی به دادهی سایر کاربران، رسیدن به سرویس‌های داخلی.
- گزارش‌دهی و آزمون مجدد: مستندسازی، امتیازدهی شدت، ارائه‌ی راهکار و سپس راستی‌آزمایی وصله‌ها.
در عمل مرحله‌های ۲ تا ۶ خطی نیستند و تکرار می‌شوند: هر یافته سطح حملهی تازه‌ای باز میکند. جزئیات فنی در راهنمای تست نفوذ وب و ترتیب اجرایی در فرایند تست نفوذ.
چرا آزمون دستی چیزی را پیدا میکند که اسکنر نمی‌تواند
این مهم‌ترین بخش این مقاله است، چون تمام تفاوت قیمت و تمام تفاوت ارزش از همین‌جا می‌آید. یک اسکنر آسیبپذیری وب — چه Burp Scanner، چه ZAP، چه Nuclei — سه محدودیت ساختاری دارد:
۱. اسکنر مفهوم «مجوز» را نمی‌فهمد
برای تشخیص IDOR یا شکست کنترل دسترسی، ابزار باید بداند این شناسه به کدام کاربر تعلق دارد و کدام نقش حق دیدنش را دارد. این دانش در کد نیست، در قصد طراح است. آزمونگر با دو حساب کاربری هم‌سطح وارد میشود، توکن نشست را جابه‌جا میکند و پاسخ سرور را مقایسه میکند. به همین دلیل دسته‌ی کنترل دسترسی شکسته در OWASP Top 10:2025 رتبه‌ی A01 را دارد و OWASP گزارش میکند در دادهی این نسخه ۱۰۰٪ برنامه‌های آزموده‌شده نوعی نقص کنترل دسترسی داشته‌اند.
۲. اسکنر منطق کسبوکار را نمی‌شناسد
دسته‌ی A06:2025 طراحی ناامن درباره‌ی نقص معماری است، نه باگ کد. جمله‌ی خود OWASP گویاست: «یک طراحی ناامن را هیچ پیاده‌سازی بی‌نقصی نمی‌تواند اصلاح کند.» مثال‌های واقعی که OWASP ذکر میکند از همین جنس‌اند: سامانهی رزرو سینما که مهاجم با رزرو صدها صندلی در سالن‌های مختلف زیر آستانه‌ی بیعانه باقی می‌ماند، یا فروشگاهی بدون محافظت در برابر ربات که کالای محدودش در چند ثانیه تمام میشود. هیچ امضایی برای «تخفیف دوباره اعمال شد» یا «مرحله‌ی پرداخت رد شد» وجود ندارد.
۳. اسکنر زنجیره نمی‌سازد
ارزش واقعی معمولاً در ترکیب است: یک تغییر مسیر باز که به‌تنهایی کم‌اهمیت به نظر می‌رسد، در کنار یک جریان OAuth به سرقت کد مجوز می‌رسد. زنجیره‌سازی نیازمند مدل ذهنی از کل سامانه است — کاری که ابزار انجام نمی‌دهد.
«فایروال برنامهی وب (WAF) داریم، پس در برابر OWASP Top 10 پوشش داریم.» WAF ساختاراً نسبت به کنترل دسترسی شکسته، منطق کسبوکار، شرایط مسابقه و بخش بزرگی از XSS مبنی بر DOM (که بخش fragment آدرس هیچ‌وقت به سرور نمی‌رسد) کور است. WAF یک لایه‌ی کاهش ریسک است و هرگز نباید به‌عنوان «راهکار رفع» یک آسیبپذیری در سطح کد ثبت شود.
جعبهی سیاه، سفید یا خاکستری؟
میزان اطلاعاتی که در اختیار آزمونگر قرار میگیرد، مستقیماً روی عمق نتیجه اثر می‌گذارد:
- جعبهی سیاه (Black Box): فقط آدرس سامانه در اختیار آزمونگر است. شبیه‌ترین حالت به مهاجم بیرونی، اما بخشی از بودجه‌ی زمانی صرف کشف چیزی میشود که کارفرما از قبل می‌دانست.
- جعبهی سفید (White Box): دسترسی به کد منبع، معماری و اعتبارنامه‌ها. بیشترین پوشش، ولی پرهزینه‌تر.
- جعبهی خاکستری (Grey Box): اعتبارنامهی همهی نقش‌ها بهعلاوهی مستندات، بدون کد کامل. برای برنامه‌های وب معمولاً بهترین نسبت نتیجه به هزینه است، چون بخش عمده‌ی آسیبپذیریهای پرخطر پس از ورود کاربر قرار دارند و آزمون بدون احراز هویت هیچ‌وقت به آن‌ها نمی‌رسد.
مقایسه‌ی کامل با برآورد زمان هر رویکرد در انواع تست نفوذ آمده است.
خروجی پروژه: مشتری واقعاً چه چیزی تحویل میگیرد
اگر تنها تحویل‌دادنی یک PDF خودکار خروجی‌گرفته از ابزار باشد، آن پروژه تست نفوذ نبوده است. بسته‌ی تحویل استاندارد شامل این اقلام است:
- خلاصه‌ی مدیریتی: یک تا دو صفحه، بدون واژه‌ی فنی، برای تصمیم‌گیر: چه چیزی در معرض خطر است، چه چیزی باید همین هفته اصلاح شود.
- یافته‌های فنی: برای هر مورد — عنوان، محل دقیق (اندپوینت و پارامتر)، شدت، گام‌های بازتولید، شاهد (درخواست/پاسخ یا تصویر)، تأثیر بر کسبوکار و راهکار رفع مشخص در سطح کد یا پیکربندی.
- امتیازدهی شدت: با CVSS. در گزارش باید صریحاً نوشته شود از نسخهی
v4.0یاv3.1استفاده شده و امتیاز بر پایه‌ی کدام گروه سنجه (پایه، تهدید، محیطی) محاسبه شده است. - نگاشت به تاکسونومی: هر یافته به یک دسته‌ی OWASP Top 10:2025، یک شناسه‌ی CWE و شناسه‌ی آزمون WSTG نگاشت شود.
- گزارش پوشش: چه چیزی آزموده شد و — مهم‌تر — چه چیزی آزموده نشد و چرا.
- آزمون مجدد: پس از رفع، آزمون تکرار میشود و گزارش تکمیلی وضعیت هر یافته را «رفع‌شده / جزئی / رفع‌نشده» ثبت میکند.
ساختار دقیق‌تر گزارش و نمونه‌ی بخش‌ها را در گزارش تست نفوذ و عوامل تعیین‌کننده‌ی هزینه را در هزینه‌ی تست نفوذ توضیح داده‌ایم.
چه زمانی و هر چند وقت یکبار؟
تست نفوذ یک رخداد نقطه‌ای است و اعتبارش با تغییر سامانه کاهش می‌یابد. سه محرک عملی برای اجرای آن وجود دارد:
- محرک تغییر: پیش از انتشار یک قابلیت حساس — درگاه پرداخت، احراز هویت، آپلود فایل، API عمومی — یا پس از مهاجرت زیرساخت.
- محرک دوره‌ای: بازهی متعارف سالانه است. در PCI DSS v4.0.1 الزام صریح‌تر است: بند ۱۱٫۴٫۲ و ۱۱٫۴٫۳ آزمون نفوذ داخلی و بیرونی را حداقل هر ۱۲ ماه و همچنین پس از هر تغییر مهم زیرساخت یا برنامه الزامی میکنند، و بند ۱۱٫۴٫۴ آزمون مجدد را اجباری می‌داند.
- محرک الزام بیرونی: درخواست مشتری سازمانی، پرسشنامهی امنیتی شرکا، یا الزامات ممیزی.
توجه کنید که ISO/IEC 27001:2022 فراوانی مشخصی برای تست نفوذ تعیین نمیکند؛ کنترل‌های A.8.8 (مدیریت آسیبپذیریهای فنی) و A.8.29 (آزمون امنیتی در توسعه و پذیرش) یک فرایند تعریف‌شده و ریسکمحور می‌خواهند. هر ادعایی مبنی بر اینکه «ISO 27001 تست نفوذ سالانه را الزامی کرده» نادرست است.
بین دو تست نفوذ، چیزی که وضعیت را حفظ میکند مدیریت آسیبپذیری پیوسته است: اسکن خودکار در خط لوله، رصد اجزای شخص ثالث، و یک چک‌لیست امنیتی پیش از هر انتشار.
«گواهی OWASP»، «انطباق با PTES» و «OSSTMM Certified» هیچ‌کدام نهاد صادرکننده ندارند. ادعای درست و قابل دفاع این است: پوشش آزمون بر پایه‌ی OWASP WSTG v4.2، رده‌بندی ریسک بر پایه‌ی OWASP Top 10:2025 و CWE، چرخه‌ی پروژه بر پایه‌ی فازهای PTES و NIST SP 800-115، و امتیازدهی با CVSS v4.0. جزئیات در متدولوژی تست نفوذ.
پرسش‌های متداول
تست نفوذ چیست و به زبان ساده چه کاری انجام میدهد؟
تست نفوذ یک حملهی شبیهسازیشده و دارای مجوز کتبی به سامانهی خودتان است. متخصص امنیت با همان روشهای مهاجم واقعی تلاش میکند وارد شود، سطح دسترسی بگیرد و به داده برسد — اما بدون تخریب، و با ثبت دقیق هر گام. نتیجه فهرستی از مسیرهای اثبات‌شدهی سوءاستفاده همراه با راهکار رفع است، نه فهرستی از احتمالات.
تفاوت تست نفوذ و اسکن آسیبپذیری چیست؟
اسکن آسیبپذیری خودکار است و ضعفهای شناختهشده را با الگو تشخیص میدهد؛ خروجیاش فهرست هشدار است که باید غربال شود. تست نفوذ عمدتاً دستی است، خطای مثبت را حذف میکند، یافتهها را به هم زنجیر میکند و کلاسهایی مثل کنترل دسترسی شکسته و نقص منطق کسبوکار را پیدا میکند که ابزار خودکار ساختاراً نمیبیند. اسکن مکمل تست نفوذ است، نه جانشین آن.
تست نفوذ چقدر طول میکشد؟
به اندازهی سطح حمله بستگی دارد، نه به تعداد صفحات سایت. معیار واقعی تعداد نقشهای کاربری، تعداد اندپوینتهای احراز هویتشده و پیچیدگی فرایندهای چندمرحلهای است. یک برنامهی وب متوسط با سه نقش کاربری معمولاً در بازهی چند روز تا دو هفتهی کاری آزمون فعال قرار میگیرد، بهعلاوهی زمان گزارشنویسی و آزمون مجدد. برآورد دقیق فقط پس از تکمیل پرسشنامهی تعیین دامنه ممکن است.
آیا تست نفوذ به سایت من آسیب میزند؟
ریسک صفر نیست، اما مدیریتشده است. آزمونهای مخرب مانند منع سرویس بهصورت پیشفرض خارج از دامنهاند، بهرهبرداری تا حد اثبات انجام میشود و نه بیشتر، پنجرهی زمانی آزمون با کارفرما توافق میشود و یک کانال ارتباطی فوری برای توقف کار وجود دارد. برای سامانههای حساس، اجرای آزمون روی محیط پیشعملیاتی با دادهی مشابه گزینهی مرجح است.
برای تست نفوذ به کد منبع نیاز دارید؟
الزامی نیست. اما دادن اعتبارنامهی همهی نقشهای کاربری (رویکرد جعبهی خاکستری) تفاوت چشمگیری در نتیجه ایجاد میکند، چون بیشتر آسیبپذیریهای پرخطر پس از ورود کاربر قرار دارند. کد منبع در رویکرد جعبهی سفید و برای بازبینی کد لازم است و بالاترین پوشش را میدهد.
هر چند وقت یکبار باید تست نفوذ انجام داد؟
حداقل سالی یکبار، و علاوه بر آن پس از هر تغییر مهم در معماری یا افزودن قابلیت حساس. اگر مشمول PCI DSS هستید، بندهای ۱۱٫۴٫۲ و ۱۱٫۴٫۳ نسخهی v4.0.1 آزمون داخلی و بیرونی را حداقل هر ۱۲ ماه و پس از هر تغییر مهم الزامی میکنند. ISO/IEC 27001:2022 فراوانی مشخصی تعیین نمیکند و فقط یک فرایند ریسکمحور میخواهد.
منابع
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسبوکار و زنجیره‌های حملهی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارش‌های تست نفوذ پی‌هانتر با اوست.