وقتی برای انواع تست نفوذ استعلام می‌گیرید، سه پیشنهاد با سه قیمت متفاوت میرسد و هیچ‌کدام توضیح نمی‌دهد که تفاوت واقعی در چه چیزی پیدا میشود است، نه در نام. تفکیک جعبهی سیاه، سفید و خاکستری درباره‌ی مهارت آزمونگر نیست؛ درباره‌ی این است که چه مقدار از بودجه‌ی زمانی پروژه صرف کشف میشود و چه مقدار صرف آزمون. این مقاله سه رویکرد را با هزینهی زمانی و برد واقعی هرکدام مقایسه میکند، تفکیک درونی/بیرونی و احراز هویتشده/نشده را روشن میکند و یک توصیه‌ی صریح می‌دهد.
در یک نگاه
- تفاوت سه نوع در سطح اطلاعات ورودی است، نه در عمق مهارت یا کیفیت کار.
- جعبهی سیاه واقع‌نمای مهاجم بیرونی است، اما بخش بزرگی از زمان را صرف کشف چیزی میکند که کارفرما از قبل می‌داند.
- جعبهی سفید بالاترین پوشش را می‌دهد و برای سامانه‌های حساس یا پیش از انتشار اولیه منطقی است.
- برای بیشتر برنامه‌های وب، جعبهی خاکستری بهترین نسبت نتیجه به هزینه است — چون یافته‌های پرخطر پس از ورود کاربر قرار دارند.
- تفکیک احراز هویتشده / نشده در عمل تأثیر بیشتری بر نتیجه دارد تا انتخاب رنگ جعبه.
معیار دستهبندی: آزمونگر چه می‌داند؟
یک پروژه‌ی تست نفوذ بودجه‌ی زمانی محدودی دارد و آن بودجه بین دو کار تقسیم میشود: کشف (فهمیدن اینکه سامانه چیست و چه اجزایی دارد) و آزمون (تلاش برای شکستن آن). هر اطلاعاتی که کارفرما در ابتدا می‌دهد، مستقیماً از سهم کشف کم و به سهم آزمون اضافه میکند.
بر این پایه سه رویکرد وجود دارد:
- جعبهی سیاه (Black Box): آزمونگر فقط دامنه یا آدرس سامانه را دارد. هیچ حساب کاربری، هیچ مستندی، هیچ کدی.
- جعبهی خاکستری (Grey Box): اعتبارنامهی همه‌ی نقشهای کاربری، توضیح فرایندهای کسبوکار، و در صورت لزوم مستندات API و دیاگرام معماری — بدون کد منبع.
- جعبهی سفید (White Box): همه‌ی موارد بالا به‌علاوه‌ی کد منبع، پیکربندی سرور و دسترسی به تیم توسعه برای پرسش.
«جعبهی سیاه سخت‌گیرانه‌ترین و در نتیجه معتبرترین نوع آزمون است.» این استدلال اشتباه است. جعبهی سیاه واقع‌نماترین شبیه‌سازی مهاجم بیرونیِ ناشناس است، اما کم‌ترین پوشش را می‌دهد. مهاجم واقعی محدودیت زمانی قرارداد شما را ندارد؛ می‌تواند ماه‌ها روی هدف بماند. آزمونگری که در چند روز محدود شده، اگر اطلاعات پایه را نداشته باشد ناچار است سطحی کار کند. هدف پروژه، بازی منصفانه با آزمونگر نیست؛ پیدا کردن حداکثر آسیب‌پذیری در بودجه‌ی موجود است.
جعبهی سیاه: چه پیدا میکند و چه از دست می‌دهد
در این رویکرد کار با شناسایی شروع میشود: کشف زیردامنه، اثر انگشت فناوری، کشف محتوا، و یافتن نقاط ورودی. آزمونگر مانند مهاجم بیرونی سطح حمله را از صفر می‌سازد.
چه چیزی خوب پیدا میکند
- دارایی‌های فراموش‌شده: محیط آزمایشی، پنل قدیمی، زیردامنه‌ی رهاشده و قابل تصاحب.
- پیکربندی نادرست در لبه: فایل پشتیبان قابل دانلود، فهرست‌شدن دایرکتوری، هدرهای گم‌شده، مخزن
.gitافشاشده. - ضعف‌های ثبت‌نام و ورود: شمارش حساب، نبود محدودیت نرخ، بازیابی رمز ضعیف.
- آسیب‌پذیری اجزای شناخته‌شده در سرویسهای عمومی.
چه چیزی را از دست می‌دهد
- هر چیزی که پس از ورود کاربر است — یعنی بیشتر برنامه.
- کنترل دسترسی شکسته بین نقش‌ها؛ بدون دو حساب هم‌سطح این آزمون عملاً ممکن نیست.
- نقص منطق کسبوکار در فرایندهای چندمرحله‌ای مثل پرداخت، بازگشت وجه، یا گردش کار تأیید.
هزینهی زمانی: بخش قابل توجهی از پروژه صرف شناسایی و کشف محتوا میشود. برای سامانه‌ای که کارفرما از ساختارش کاملاً آگاه است، این بخش عملاً بازتولید دانش موجود است.
کاربرد درست: ارزیابی سطح حمله‌ی بیرونی سازمان، سنجش اینکه یک مهاجم ناشناس در بازه‌ی کوتاه چه میبیند، یا آزمون یک سامانه‌ی صرفاً عمومی بدون ناحیهی کاربری.
جعبهی سفید: بالاترین پوشش
در جعبهی سفید، آزمون پویا با بازبینی کد ترکیب میشود. آزمونگر مسیر داده را از نقطه‌ی ورود تا سینک خطرناک در کد دنبال میکند و بعد در سامانه‌ی زنده آن را اثبات میکند.
چه چیزی خوب پیدا میکند
- مسیرهای تزریق کم‌عمق‌شده: جایی که ورودی از سه لایه عبور میکند و در انتها در یک کوئری پویا می‌نشیند.
- تزریق مرتبه‌دوم: داده‌ای که در یک اندپوینت ذخیره و در اندپوینت دیگری اجرا میشود. کشف این دسته از بیرون بسیار دشوار است.
- سوءاستفاده‌های رمزنگاری: تولید عدد تصادفی ضعیف، کلید سخت‌کدشده، IV ثابت.
- منطق مجوزدهی: خواندن مستقیم اینکه بررسی نقش کجا انجام میشود و کدام مسیر آن را دور می‌زند.
محدودیت‌های واقعی
- هزینهی زمانی بالاتر است: خواندن و فهمیدن کد خودش زمان می‌برد و با اندازهی کدبیس رشد میکند.
- نیازمند همکاری فعال تیم توسعه و اغلب توافق محرمانگی سخت‌گیرانه‌تر برای کد.
- ابزار تحلیل ایستا کمک میکند اما جایگزین خواندن کد نیست. Semgrep CE در نسخه‌ی رایگان تحلیل جریان دادهی بین‌فایلی ندارد و CodeQL برای کدبیس تجاری و بسته نیازمند توافق تجاری است.
- مهم‌تر از همه: تحلیل ایستا کنترل دسترسی و منطق کسبوکار را تقریباً پیدا نمی‌کند — و همان‌جاست که پرخطرترین یافته‌ها زندگی می‌کنند.
روش و محدودیت‌های بازبینی کد را در دانشنامه‌ی بازبینی کد امن شرح داده‌ایم. جعبهی سفید برای سامانه‌های بانکی، سلامت و زیرساختی، و همچنین پیش از انتشار نخست یک محصول، انتخاب درستی است.
جعبهی خاکستری: توصیه‌ی ما برای برنامه‌های وب
در جعبهی خاکستری کارفرما اعتبارنامهی همه‌ی نقش‌ها — ترجیحاً دو حساب برای هر نقش — و توضیح فرایندهای کسبوکار را می‌دهد. کد منبع در اختیار آزمونگر نیست. دلیل توصیه‌ی ما ساده و مبتنی بر جای واقعی آسیب‌پذیری‌هاست:
- پرخطرترین دسته پس از ورود است. در OWASP Top 10:2025، رتبه‌ی یک همچنان کنترل دسترسی شکسته است و OWASP گزارش میکند در دادهی این نسخه ۱۰۰٪ برنامه‌های آزموده‌شده نوعی نقص کنترل دسترسی داشته‌اند. آزمون این دسته بدون چند حساب کاربری فعال، شدنی نیست.
- منطق کسبوکار فقط با دانستن قصد فرایند آزمودنی است. اگر آزمونگر نداند «تخفیف باید یک‌بار اعمال شود»، نمی‌فهمد اعمال دوباره‌اش یک یافته است.
- بودجه‌ی زمانی جابه‌جا میشود، نه اضافه. با حذف مرحله‌ی حدس‌زدن ساختار، همان تعداد روز کاری صرف آزمون واقعی میشود.
این رویکرد در عمل با روش کار متدولوژی تست نفوذ وب ما هم‌راستاست: دامنه‌ی مضیق، عمق زیاد، و پوشش کامل دسته‌های WSTG-ATHZ و WSTG-BUSL که بیشترین ارزش را تولید می‌کنند.
اگر می‌خواهید واقع‌نمایی جعبهی سیاه را هم داشته باشید، پروژه را دو مرحله‌ای کنید: یک بازه‌ی کوتاه ابتدایی بدون اطلاعات برای سنجش سطح حمله‌ی بیرونی، و سپس تحویل اعتبارنامه‌ها و ادامه‌ی کار به‌صورت خاکستری. این کار هر دو دیدگاه را می‌دهد بدون آنکه کل بودجه صرف کشف شود.
مقایسه‌ی سه رویکرد
| معیار | جعبهی سیاه | جعبهی خاکستری | جعبهی سفید |
|---|---|---|---|
| ورودی از کارفرما | فقط دامنه | اعتبارنامهی همه‌ی نقش‌ها + مستندات | کد منبع + پیکربندی + دسترسی به تیم |
| سهم زمان صرف‌شده برای کشف | زیاد | کم | متوسط (خواندن کد) |
| پوشش سطح حمله | کم | زیاد | بیشترین |
| کشف کنترل دسترسی و IDOR | تقریباً هیچ | قوی | قوی |
| کشف منطق کسبوکار | ضعیف | قوی | قوی |
| کشف تزریق مرتبه‌دوم | ضعیف | متوسط | قوی |
| واقع‌نمایی مهاجم بیرونی | بیشترین | متوسط | کم |
| هزینهی نسبی | کم‌ترین | متوسط | بیشترین |
| مناسب برای | ارزیابی سطح حمله‌ی بیرونی | اکثر برنامه‌های وب | سامانه‌های حساس و پیش از انتشار |
عوامل تعیین‌کننده‌ی قیمت — تعداد نقش‌ها، تعداد اندپوینت‌ها، وجود API، و شمول آزمون مجدد — را در هزینهی تست نفوذ تفکیک کرده‌ایم.
تست نفوذ بیرونی و درونی
این تفکیک به جایگاه شبکهای آزمونگر مربوط است، نه به سطح دانش او، و کاملاً مستقل از رنگ جعبه است:
- بیرونی (External): آزمون از اینترنت، مانند هر کاربر یا مهاجم بیرونی. برای یک برنامهی وب عمومی، این حالت پیش‌فرض است.
- درونی (Internal): آزمون از داخل شبکهی سازمان — با فرض اینکه مهاجم پیش‌تر جای پایی گرفته یا یک کارمند بدنیت است. اینجا سرویسهای داخلی، پنل‌های مدیریتی بدون احراز هویت، و ضعف تفکیک شبکه دیده میشود.
PCI DSS v4.0.1 هر دو را الزامی میکند: بند ۱۱٫۴٫۲ آزمون درونی و بند ۱۱٫۴٫۳ آزمون بیرونی، هر دو حداقل هر ۱۲ ماه و پس از هر تغییر مهم زیرساخت یا برنامه. بند ۱۱٫۴٫۵ هم آزمون کنترل‌های تفکیک را حداقل سالانه لازم می‌داند (برای ارائه‌دهندگان سرویس، بند ۱۱٫۴٫۶ آن را به هر شش ماه تبدیل میکند).
برای یک شرکت با تمرکز بر برنامهی وب، نکته‌ی مهم این است: آزمون درونی جای آزمون برنامه را نمی‌گیرد. تفکیک کامل حوزه‌ها و جایگاه آزمون شبکه در حوزه‌های تست نفوذ آمده است.
احراز هویتشده یا نشده — مهم‌تر از رنگ جعبه
در عمل، بیشترین تأثیر روی نتیجهی یک پروژه از این تفکیک می‌آید:
- آزمون بدون احراز هویت (Unauthenticated): فقط بخش عمومی برنامه — صفحه‌ی ورود، ثبت‌نام، بازیابی رمز، جست‌وجوی عمومی، اندپوینت‌های باز.
- آزمون احراز هویتشده (Authenticated): با ورود به هر نقش، و مهم‌تر از آن، آزمون عبور از مرز نقش‌ها.
آزمون احراز هویتشده باید به‌صورت ماتریسی انجام شود: هر عملیات حساس با هر نقش، و همچنین با توکن کاربر هم‌سطح دیگر. جدول نتیجه، ماتریس مجوزدهی واقعی برنامه را در برابر ماتریس مورد نظر طراح می‌گذارد. تفاوت‌ها همان یافته‌ها هستند.
«حساب ادمین را به آزمونگر نمی‌دهیم چون خطرناک است، پس نتیجهی آزمون هم دقیق‌تر میشود.» ندادن حساب ادمین یک کلاس کامل از یافته‌ها را حذف میکند: ارتقای سطح دسترسی از کاربر عادی به ادمین. برای آزمون این مسیر، آزمونگر باید بداند رابط ادمین چه شکلی است تا بفهمد کاربر عادی به کدام بخشش میرسد. راهکار درست ساختن یک حساب ادمین موقت روی محیط آزمون است، نه حذف این بخش از دامنه.
اگر مطمئن نیستید کدام ترکیب برای سامانه‌ی شما مناسب است، در جلسه‌ی مشاوره دامنه را بر پایهی معماری و ریسک واقعی سامانه تعیین می‌کنیم و سپس با تست نفوذ وب اجرا میشود.
پرسش‌های متداول
انواع تست نفوذ چیست؟
سه دستهبندی جداگانه وجود دارد که اغلب با هم مخلوط میشوند. بر پایهی سطح دانش آزمونگر: جعبهی سیاه، خاکستری و سفید. بر پایهی جایگاه شبکهای: بیرونی و درونی. بر پایهی وضعیت نشست: احراز هویتشده و نشده. یک پروژه همزمان در هر سه دستهبندی جایی دارد — مثلاً «تست نفوذ بیرونی، جعبهی خاکستری، احراز هویتشده با سه نقش».
تفاوت جعبه سیاه و جعبه خاکستری در تست نفوذ چیست؟
در جعبهی سیاه آزمونگر فقط آدرس سامانه را دارد و باید همه چیز را خودش کشف کند. در جعبهی خاکستری اعتبارنامهی نقشهای کاربری و توضیح فرایندها در اختیارش است. نتیجهی عملی: در جعبهی سیاه بخش بزرگی از زمان صرف کشف میشود و بخش احراز هویتشدهی برنامه تقریباً آزموده نمیشود؛ در خاکستری همان زمان به آزمون کنترل دسترسی و منطق کسبوکار میرسد.
کدام نوع تست نفوذ برای سایت من مناسب است؟
اگر سامانه ناحیهی کاربری، نقشهای مختلف یا فرایند پرداخت دارد، جعبهی خاکستری تقریباً همیشه انتخاب درست است. اگر سامانه صرفاً یک وبسایت معرفی محصول بدون ورود کاربر است، جعبهی سیاه کافی است. اگر در حوزهی بانکی، سلامت یا زیرساخت حساس کار میکنید یا پیش از انتشار نخست محصول هستید، جعبهی سفید همراه با بازبینی کد را انتخاب کنید.
آیا جعبه سفید گرانتر است؟
بله، چون بازبینی کد زمان اضافه میخواهد و هزینهی آن با اندازهی کدبیس رشد میکند. اما «گرانتر» به معنی «همیشه ارزشمندتر» نیست: تحلیل کد در پیدا کردن تزریق و سوءاستفادهی رمزنگاری قوی است و در پیدا کردن نقص کنترل دسترسی و منطق کسبوکار ضعیف. بهترین ترکیب برای بیشتر سازمانها، آزمون خاکستری منظم است و بازبینی کد هدفمند روی ماژولهای حساس.
تفاوت تست نفوذ داخلی و خارجی چیست؟
در آزمون خارجی، آزمونگر از اینترنت کار میکند و همان چیزی را میبیند که مهاجم بیرونی میبیند. در آزمون داخلی، از داخل شبکهی سازمان — با فرض اینکه مهاجم جای پایی گرفته یا کارمندی بدنیت است — سرویسهای داخلی و کیفیت تفکیک شبکه آزموده میشود. PCI DSS v4.0.1 در بندهای ۱۱٫۴٫۲ و ۱۱٫۴٫۳ هر دو را حداقل هر ۱۲ ماه الزامی میکند.
برای تست نفوذ چند حساب کاربری لازم است؟
قاعدهی عملی: برای هر نقش، دو حساب. دلیلش این است که آزمون کنترل دسترسی افقی — یعنی بررسی اینکه کاربر «الف» به دادهی کاربر «ب» دسترسی ندارد — با یک حساب در هر نقش ممکن نیست. اگر برنامهی شما پنج نقش دارد، ده حساب آزمایشی روی محیط آزمون بسازید و پس از پایان پروژه غیرفعالشان کنید.
منابع
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسبوکار و زنجیره‌های حمله‌ی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارش‌ها با اوست.