«تست نفوذ» یک سرویس واحد نیست؛ چند حوزهی متفاوت است که ابزار، مهارت و مدت زمان متفاوتی می‌خواهند. سازمان‌ها معمولاً یکی از دو اشتباه را مرتکب می‌شوند: یا همهی حوزهها را با هم سفارش می‌دهند و بودجه را نازک پخش می‌کنند، یا فقط یکی را می‌گیرند و فرض می‌کنند بقیه پوشش داده شده — مثلاً فکر می‌کنند تست نفوذ وب، API را هم پوشش داده است. این مقاله حوزههای تست نفوذ را تفکیک میکند: هرکدام چه چیزی را می‌بیند، چه زمانی برای کسبوکار لازم است، و تقریباً چه حجمی از کار می‌برد.
در یک نگاه
- حوزهها هم‌پوشانی جزئی دارند اما جانشین هم نیستند؛ هرکدام لایه‌ی متفاوتی را می‌بیند.
- برای بیشتر کسبوکارهای آنلاین، ترتیب اولویت این است: وب ← API ← شبکه‌ی بیرونی.
WSTG-APITدر WSTG v4.2 فقط یک آزمون دارد (GraphQL)؛ مرجع درست کار API، OWASP API Security Top 10 (نسخهی ۲۰۲۳) است.- تست نفوذ موبایل بدون آزمون API پشتی آن، نیمه‌کاره است — بخش عمدهی ریسک در سرور است، نه در اپلیکیشن.
- آزمون ابر و مهندسی اجتماعی محدودیت‌های حقوقی و اخلاقی خاص خود را دارند و باید جداگانه مجوز بگیرند.
نقشه‌ی کلی حوزهها
جدول زیر شش حوزهی متعارف را با پوشش، محرک کسب‌وکاری و حجم تقریبی کار مقایسه میکند. حجم کار وابسته به دامنه است و برآورد دقیق فقط پس از پرسشنامه‌ی تعیین دامنه ممکن است؛ ستون آخر ترتیب نسبی را نشان میدهد، نه عدد قطعی.
| حوزه | چه چیزی را می‌بیند | چه زمانی لازم است | حجم نسبی |
|---|---|---|---|
| وب | منطق و کد برنامه: کنترل دسترسی، نشست، اعتبارسنجی، جریان کار | هر سامانه‌ای که ناحیه‌ی کاربری یا دادهی مشتری دارد | متوسط تا زیاد |
| API | اندپوینتهای REST/GraphQL، مجوزدهی سطح آبجکت و سطح تابع | وجود اپلیکیشن موبایل، برنامهی تک‌صفحه‌ای، یا API شرکای تجاری | متوسط |
| شبکه | سرویس‌های در معرض دید، نسخه‌ها، پیکربندی، تفکیک شبکه | وجود زیرساخت خودمیزبان یا الزام انطباق | کم تا متوسط |
| موبایل | ذخیرهسازی محلی، پین‌کردن گواهی، منطق سمت کلاینت، و API پشتی | انتشار اپلیکیشن اندروید یا iOS با دادهی حساس | متوسط |
| ابر | پیکربندی هویت و دسترسی، ذخیرهسازی، شبکه‌ی مجازی، اسرار | مهاجرت به ابر یا رشد سریع زیرساخت ابری | متوسط |
| مهندسی اجتماعی | آگاهی کارکنان و اثربخشی فرایندهای احراز هویت انسانی | سازمان‌های بزرگ با بلوغ فنی نسبی | کم تا متوسط |
تمرکز حرفه‌ای ما بر دو حوزهی نخست است و بخش‌های بعدی همین ترتیب را دنبال می‌کنند: وب و API با جزئیات کامل، بقیه به‌اختصار و دقیق.
تست نفوذ وب
این حوزه لایه‌ی برنامه را می‌آزماید: چیزی که تیم شما نوشته است. متدولوژی مرجع، OWASP WSTG v4.2 با ۱۲ دسته و حدود ۹۷ آزمون است. پوشش عملی آن:
- هویت و احراز هویت: فرایند ثبت‌نام، شمارش حساب، قفل‌شدن حساب، بازیابی و تغییر رمز، احراز هویت ضعیف‌تر در کانال‌های جایگزین.
- مجوزدهی: پیمایش مسیر، دور زدن طرح مجوزدهی، ارتقای سطح دسترسی و IDOR. پرارزش‌ترین بخش هر پروژهی وب.
- مدیریت نشست: ویژگی‌های کوکی، تثبیت نشست، CSRF، خروج و انقضا.
- اعتبارسنجی ورودی: تزریق SQL و انواع دیگر تزریق، XSS، SSTI، SSRF، قاچاق HTTP.
- منطق کسبوکار: دور زدن جریان کار، شرایط مسابقه، دستکاری قیمت، سوءاستفاده از سهمیه — بخشی که هیچ ابزار خودکاری پوشش نمی‌دهد.
- سمت کلاینت: XSS مبنی بر DOM، CORS، clickjacking، ذخیرهسازی مرورگر،
postMessage. - پیکربندی: فایل‌های پشتیبان، واسط مدیریتی، هدرهای امنیتی، تصاحب زیردامنه، ذخیرهسازی ابری باز.
محرک کسب‌وکاری: هر سامانه‌ای که حساب کاربری، دادهی شخصی یا پرداخت دارد. اگر تنها یک حوزه را میتوانید انتخاب کنید، این است. روش اجرای گام‌به‌گام در راهنمای تست نفوذ وب آمده است.
حجم کار: تعیین‌کننده‌ی اصلی تعداد نقشهای کاربری و تعداد فرایندهای چندمرحله‌ای است، نه تعداد صفحات. سامانه‌ای با دو نقش و یک جریان خرید، به‌مراتب سبک‌تر از سامانه‌ای با پنج نقش و گردش کار تأیید چندلایه است.
تست نفوذ API
API امروز اغلب سطح حملهی اصلی است، نه یک ضمیمه. اپلیکیشن موبایل، برنامهی تک‌صفحه‌ای و یکپارچه‌سازی شرکا همه از همان اندپوینت‌ها استفاده می‌کنند و بسیاری از این اندپوینت‌ها هرگز از رابط کاربری وب فراخوانی نمیشوند.
«تست نفوذ وب انجام دادیم، پس API هم پوشش داده شد.» نه، و دلیلش در خودِ متدولوژی است: دستهی WSTG-APIT در WSTG v4.2 فقط یک آزمون دارد و آن هم مخصوص GraphQL است. WSTG v4.2 یک متدولوژی جامع REST API نیست. اگر آزمون فقط از طریق مرور رابط کاربری وب انجام شود، اندپوینتهایی که UI صدا نمی‌زند — نسخههای قدیمی API، اندپوینتهای داخلی، اندپوینتهای مخصوص موبایل — آزموده نمیشوند. برای دامنهی API باید فایل OpenAPI یا Postman Collection تحویل داده شود.
مرجع درست، OWASP API Security Top 10 نسخهی ۲۰۲۳ است. ده دستهی آن:
- BOLA — مجوزدهی شکسته در سطح آبجکت. همان IDOR، اما در API شدیدتر چون شناسه‌ها صریح‌تر در مسیر و بدنه ظاهر می‌شوند.
- احراز هویت شکسته (Broken Authentication).
- BOPLA — مجوزدهی شکسته در سطح ویژگی آبجکت؛ خواندن یا نوشتن فیلدی که نباید در دسترس باشد (مثل ارتقای نقش با ارسال فیلد
role). - مصرف نامحدود منابع (Unrestricted Resource Consumption).
- BFLA — مجوزدهی شکسته در سطح تابع؛ فراخوانی اندپوینت مدیریتی با توکن کاربر عادی.
- دسترسی نامحدود به جریان‌های حساس کسبوکار.
- SSRF.
- پیکربندی نادرست امنیتی.
- مدیریت نادرست موجودی (Improper Inventory Management) — نسخههای قدیمی و اندپوینتهای مستندنشده‌ای که هنوز زنده‌اند.
- مصرف ناامن APIهای بیرونی.
در عمل، آزمون API ترکیبی است از دسته‌های عمومی WSTG (احراز هویت، مجوزدهی، نشست، اعتبارسنجی ورودی) به‌علاوه‌ی این تاکسونومی. توجه ویژه به توکن‌ها لازم است: اعتبارسنجی ادعاهای aud و iss، الگوریتم امضا و انقضا در JWT — و اینکه توکن در localStorage ذخیره نشده باشد. جزئیات جریان کار و ابزارها در دانشنامه‌ی آزمون API.
تست نفوذ موبایل
آزمون اپلیکیشن اندروید یا iOS دو بخش دارد و بخش دوم اغلب مهم‌تر است:
- سمت کلاینت: بازبینی ذخیرهسازی محلی (پایگاه‌داده، فایل‌های تنظیمات، keychain)، اسرار سخت‌کدشده در بسته، پین‌کردن گواهی و امکان دور زدن آن، امنیت ارتباط بین‌فرایندی، و مقاومت در برابر مهندسی معکوس.
- سمت سرور: همان API که اپلیکیشن مصرف میکند. بخش عمدهی ریسک واقعی اینجاست، چون کنترل دسترسی و منطق کسبوکار در سرور اجرا میشود.
نکته‌ی عملی: هیچ کنترلی که فقط در اپلیکیشن پیاده شده باشد قابل اعتماد نیست. مهاجم بسته را باز میکند، ترافیک را با پروکسی می‌بیند و درخواست را مستقیم به سرور می‌فرستد. به همین دلیل توصیهی ما همیشه این است که آزمون موبایل و آزمون API با هم انجام شود، نه جداگانه. جزئیات این حوزه در تست نفوذ موبایل آمده است.
محرک کسب‌وکاری: انتشار اپلیکیشنی که دادهی مالی، سلامت یا هویتی جابهجا میکند، یا الزام فروشگاه‌های اپلیکیشن و شرکای سازمانی.
تست نفوذ شبکه
این حوزه لایه‌ی زیر برنامه را می‌آزماید: چه سرویسی در معرض دید است، با چه نسخه‌ای، با چه پیکربندی‌ای، و اگر مهاجم یک نقطه گرفت تا کجا می‌تواند حرکت کند.
- بیرونی: شمارش سرویس‌های در معرض اینترنت، اثر انگشت نسخه، سرویس‌های فراموش‌شده روی درگاه‌های غیراستاندارد، پیکربندی TLS، و آسیب‌پذیری اجزای شناخته‌شده.
- درونی: کیفیت تفکیک شبکه، سرویس‌های داخلی بدون احراز هویت، پنل‌های مدیریتی، و مسیرهای حرکت جانبی.
برای یک شرکت که سامانه‌اش روی زیرساخت ابری مدیریت‌شده اجرا میشود، دامنهی این حوزه کوچک است. برای سازمانی با مرکز دادهی خودش، بزرگ. PCI DSS v4.0.1 در بندهای ۱۱٫۴٫۲ و ۱۱٫۴٫۳ آزمون شبکه‌ی درونی و بیرونی را حداقل هر ۱۲ ماه و پس از هر تغییر مهم الزامی میکند و در بند ۱۱٫۴٫۵ راستی‌آزمایی کنترل‌های تفکیک را می‌خواهد. شرح کامل در تست نفوذ شبکه.
یک سرور کاملاً وصله‌شده و کاملاً مقاوم‌سازی‌شده می‌تواند برنامه‌ای با نقص بحرانی کنترل دسترسی میزبانی کند و آزمون شبکه هیچ‌وقت آن را نبیند. عکسش هم درست است: برنامه‌ای بی‌عیب روی سروری با سرویس مدیریتی افشاشده در معرض خطر است. این دو حوزه پرسش‌های متفاوتی را پاسخ می‌دهند و جانشین هم نیستند.
تست نفوذ ابر و مهندسی اجتماعی
ابر
آزمون ابر بیشتر یک بازبینی پیکربندی است تا بهرهبرداری، و تمرکزش روی هویت و دسترسی است: نقشهای بیشمجوز، کلیدهای بلندعمر، ذخیرهسازی با دسترسی عمومی، گروههای امنیتی باز، اسرار داخل متغیرهای محیطی و مخازن کد، و پیکربندی لاگ و پایش.
دو نکته‌ی عملی: اول، مدل مسئولیت مشترک یعنی زیرساخت خودِ ارائهدهنده در دامنهی شما نیست و آزمون آن نه مجاز است و نه معنادار؛ دامنهی شما پیکربندی و لایه‌ی برنامه است. دوم، هر ارائهدهنده قواعد خودش را برای آزمون امنیتی دارد و باید پیش از شروع بررسی شود.
یک تصحیح فنی که ارزش گفتن دارد: فرض قدیمی «SSRF روی زیرساخت ابری یعنی دسترسی فوری به اعتبارنامه‌های نقش» دیگر پیش‌فرض درستی نیست. سرویس فراداده‌ی نسخهی دوم (IMDSv2) نیازمند دریافت توکن با متد PUT و ارسال هدر اختصاصی است و سقف پرش پیش‌فرضش ۱ است؛ در ایمیج‌ها و انواع نمونه‌ی جدیدتر هم به‌صورت پیش‌فرض فعال است. نسخهی اول همچنان ممکن است در محیط‌های قدیمی وجود داشته باشد، اما فرض پیش‌فرض نیست.
مهندسی اجتماعی
هدف این حوزه سنجش فرایند و آگاهی است، نه گرفتن مچ افراد. سناریوهای متعارف: کارزار فیشینگ هدفمند با شاخص‌های اندازه‌گیری‌شده، آزمون فرایند بازنشانی رمز از طریق میز خدمت، و آزمون کنترل دسترسی فیزیکی در سازمان‌های بزرگ.
محدودیت‌های اخلاقی و حقوقی این حوزه سخت‌گیرانه‌تر از بقیه است: مجوز باید صریحاً این حوزه را نام ببرد، هدف باید کارکنان همان سازمان باشند و نه اشخاص ثالث، دادهی اعتبارنامه‌ی واقعی جمع‌آوری یا ذخیره نمی‌شود، و خروجی باید تجمعی و بی‌نام باشد تا به ابزار ارزیابی عملکرد فردی تبدیل نشود. سازمانی که هنوز آسیب‌پذیری‌های پایهی برنامه‌اش را رفع نکرده، از این حوزه ارزش کمی می‌گیرد؛ جای درست آن پس از رسیدن به بلوغ فنی نسبی است — و مسیر مؤثرتر در آن مرحله، دوره‌ی سازمانی توسعه‌ی امن است.
چطور ترکیب درست را برای سازمان خودتان انتخاب کنید
ترتیب پیشنهادی بر پایهی جایی که ریسک واقعاً هست:
- سامانه‌ای که دادهی مشتری دارد را اول بیازمایید. برای بیشتر کسبوکارهای آنلاین این یعنی برنامهی وب و API آن — و این دو در یک پروژه انجام می‌شوند، نه دو پروژه.
- اگر اپلیکیشن موبایل دارید، آن را به همان پروژه اضافه کنید، چون API مشترک است و آزمون جدا کار را دوباره انجام میدهد.
- شبکه‌ی بیرونی را بیازمایید اگر زیرساخت خودمیزبان دارید یا مشمول انطباق هستید.
- بازبینی پیکربندی ابر را پس از مهاجرت یا رشد سریع زیرساخت انجام دهید.
- مهندسی اجتماعی و تیم سرخ را برای زمانی بگذارید که لاگ، پایش و فرایند پاسخ به رخداد دارید. پیش از آن، نتیجه از قبل معلوم است.
یک گزینه‌ی مکمل که جای تست نفوذ را نمیگیرد اما پس از آن ارزش دارد: برنامهی باگ بانتی. تست نفوذ پوشش سیستماتیک در یک بازه‌ی معین میدهد؛ باگ بانتی جست‌وجوی پیوسته و نامتقارن. ترتیب درست این است که اول با تست نفوذ آسیب‌پذیری‌های ساختاری را ببندید و بعد برنامهی پاداش راه بیندازید، وگرنه هزینه‌ی پاداش صرف یافته‌هایی میشود که یک آزمون منظم ارزان‌تر پیدا می‌کرد.
اگر مطمئن نیستید کدام ترکیب برای شما درست است، دامنه را در قالب یک پرسشنامه‌ی ساختاریافته تعیین می‌کنیم و اجرای آن با تست نفوذ وب پی‌هانتر شروع میشود.
پرسش‌های متداول
حوزههای تست نفوذ چه تفاوتی با انواع تست نفوذ دارند؟
«حوزه» به چه چیزی آزموده میشود اشاره دارد: وب، API، موبایل، شبکه، ابر، مهندسی اجتماعی. «نوع» به چگونه آزموده میشود اشاره دارد: جعبهی سیاه، سفید یا خاکستری، و بیرونی یا درونی. این دو مستقلاند — میتوانید یک تست نفوذ API جعبهی خاکستری بیرونی داشته باشید.
آیا تست نفوذ وب شامل تست نفوذ API هم میشود؟
بهطور خودکار نه. اگر آزمون فقط با مرور رابط کاربری وب انجام شود، اندپوینتهایی که UI فراخوانی نمیکند آزموده نمیشوند — نسخههای قدیمی API، اندپوینتهای داخلی و اندپوینتهای مخصوص موبایل. برای پوشش API باید دامنه صریحاً آن را شامل شود و فایل OpenAPI یا Postman Collection تحویل داده شود. توجه کنید که دستهی API در WSTG v4.2 فقط یک آزمون (GraphQL) دارد و مرجع درست، OWASP API Security Top 10 نسخهی ۲۰۲۳ است.
برای اپلیکیشن موبایل، تست نفوذ موبایل کافی است؟
کافی نیست. بخش عمدهی ریسک واقعی در API پشتی است، چون کنترل دسترسی و منطق کسبوکار در سرور اجرا میشود و هر کنترلی که فقط داخل اپلیکیشن پیاده شده باشد با یک پروکسی قابل دور زدن است. توصیهی درست: آزمون موبایل و API را در یک پروژه انجام دهید.
تست نفوذ ابری چه چیزی را بررسی میکند؟
عمدتاً پیکربندی، نه بهرهبرداری: نقشهای بیشمجوز و کلیدهای بلندعمر، ذخیرهسازی با دسترسی عمومی، گروههای امنیتی باز، اسرار افشاشده در متغیرهای محیطی و مخازن کد، و کیفیت لاگ و پایش. توجه کنید که بر پایهی مدل مسئولیت مشترک، زیرساخت خودِ ارائهدهنده در دامنهی شما نیست و هر ارائهدهنده قواعد مخصوص خود را برای آزمون امنیتی دارد که باید پیش از شروع بررسی شود.
کدام حوزه را اول سفارش بدهم؟
حوزهای که دادهی مشتری در آن جابهجا میشود. برای بیشتر کسبوکارهای آنلاین این یعنی برنامهی وب و API آن، در یک پروژهی مشترک. شبکه را زمانی اضافه کنید که زیرساخت خودمیزبان دارید یا الزام انطباق وجود دارد، و مهندسی اجتماعی و تیم سرخ را برای زمانی بگذارید که لاگ، پایش و فرایند پاسخ به رخداد برقرار است.
آیا میتوان همهی حوزهها را در یک پروژه انجام داد؟
فنی ممکن است اما معمولاً نتیجهی بدی میدهد، چون بودجهی زمانی ثابت روی شش حوزه پخش میشود و هیچکدام عمق کافی نمیگیرد. رویکرد بهتر: در هر دوره یک یا دو حوزهی مرتبط را با عمق کامل بیازمایید و حوزههای دیگر را در دورههای بعدی پوشش دهید. تنها ترکیبی که واقعاً باید با هم انجام شود، وب و API — و در صورت وجود، موبایل — است، چون سطح حملهی مشترکی دارند.
منابع
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسبوکار و زنجیره‌های حملهی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارش‌ها با اوست.