برنامه تست‌های عملکردی را گذرانده و آمادهٔ انتشار است؛ اما آیا رفتار امنیتی آن نیز بررسی شده است؟ ممکن است پاسخ‌های HTTP اطلاعات اضافی منتشر کنند، تنظیمات امنیتی ناقص باشند یا یک ورودی، رفتار آسیب‌پذیری را در برنامه آشکار کند.
تست امنیت پویای برنامه یا DAST، برنامهٔ در حال اجرا را از طریق رابط‌های قابل دسترس آن بررسی می‌کند. ابزار ZAP یکی از گزینه‌های متن‌باز برای انجام این بررسی‌ها روی برنامه‌های وب و APIهاست.
نکته‌ای دربارهٔ نام ابزار: اگرچه هنوز با نام «OWASP ZAP» شناخته می‌شود، این پروژه از سپتامبر ۲۰۲۳ از OWASP خارج شده و اکنون پروژه‌ای مستقل با پشتیبانی Checkmarx است. در این مقاله از نام فعلی ZAP استفاده می‌کنیم. وضعیت رسمی پروژه
تست DAST چیست؟
در DAST، آزمون روی برنامهٔ اجراشده انجام می‌شود. ابزار درخواست می‌فرستد، پاسخ‌ها را بررسی می‌کند و به دنبال نشانه‌های آسیب‌پذیری یا پیکربندی نامناسب می‌گردد.
این روش با بررسی ایستای کد یا SAST تفاوت دارد. برای نمونه، یک تنظیم اشتباه در پاسخ واقعی وب‌سرور ممکن است هنگام بررسی رفتار برنامه آشکار شود. در مقابل، مسیرهایی که ابزار نتوانسته به آن‌ها دسترسی پیدا کند، پوشش مناسبی نخواهند داشت.
DAST بخشی از ارزیابی امنیت است و جای بررسی کد، وابستگی‌ها و تست دستی را نمی‌گیرد. راهنمای DAST در OWASP
ZAP چگونه برنامه را بررسی می‌کند؟
ZAP می‌تواند میان مرورگر و برنامه قرار بگیرد و ترافیک درخواست و پاسخ را مشاهده کند. همچنین ابزارهای کشف مسیر و اسکن خودکار دارد.
برای درک درست نتیجه، باید دو فعالیت را جدا کنیم:
- کشف مسیرها: پیدا کردن صفحات، endpointها و ورودی‌های قابل دسترس.
- بررسی امنیتی: تحلیل ترافیک یا ارسال درخواست‌های آزمایشی به مسیرهای کشف‌شده.
اگر بخش مهمی از برنامه کشف نشود، اسکن آن بخش نیز ناقص خواهد بود. به همین دلیل، شناخت جریان‌های اصلی کاربر و APIهای برنامه اهمیت دارد. راهنمای شروع ZAP
تفاوت Passive Scan و Active Scan چیست؟
Passive Scan درخواست‌ها و پاسخ‌های عبوری را تحلیل می‌کند، بدون اینکه خودش payload حمله به آن‌ها اضافه کند.
Active Scan درخواست‌های آزمایشی برای شناسایی آسیب‌پذیری ارسال می‌کند. این درخواست‌ها ممکن است روی داده و رفتار برنامه اثر بگذارند؛ بنابراین اسکن فعال را در محیط آزمایشی مجاز، با دادهٔ قابل بازیابی و محدودهٔ مشخص اجرا کنید.
همچنین غیرفعال‌بودن نوع اسکن به معنای نبود ترافیک نیست. مرور دستی یا crawler همچنان با برنامه تعامل دارد. توضیح رسمی روش‌های اسکن
برای شروع، Baseline Scan چه کاربردی دارد؟
اسکریپت Baseline ابتدا با Spider مسیرها را کشف می‌کند و سپس منتظر پایان تحلیل غیرفعال می‌ماند. این روش حملات Active Scan را اجرا نمی‌کند و می‌تواند نقطهٔ شروع ساده‌ای برای خودکارسازی باشد.
نمونهٔ زیر برای یک محیط آزمایشی تحت کنترل شماست. دستور برای shell لینوکسی نوشته شده و پوشهٔ جاری باید برای کانتینر قابل نوشتن باشد:
docker run --rm \
-v "$(pwd):/zap/wrk/:rw" \
ghcr.io/zaproxy/zaproxy:stable \
zap-baseline.py \
-t https://staging.example.com \
-r zap-report.html \
-J zap-report.jsonنشانی نمونه را با مقصد مجاز جایگزین کنید. برای اجرای تکرارپذیر در CI، نسخهٔ image را نیز مشخص و ثابت کنید.
در Baseline، قواعد می‌توانند به‌صورت WARN، FAIL یا IGNORE تنظیم شوند. کد خروجی پیش‌فرض نیز میان هشدار، شکست قواعد و خطای اجرا تفاوت می‌گذارد؛ آن را با سیاست Pipeline هماهنگ کنید. مستندات Baseline Scan
چرا اسکن احراز هویت‌شده مهم است؟
یک اسکن ممکن است بدون خطای اجرایی پایان یابد، اما فقط صفحهٔ ورود و چند مسیر عمومی را دیده باشد.
برای ارزیابی کاربردی، پیشنهاد می‌کنیم ابتدا فهرستی از جریان‌های مهم تهیه کنید؛ مانند ورود، مشاهدهٔ اطلاعات و ثبت یک درخواست آزمایشی. سپس بررسی کنید اسکنر واقعاً به این مسیرها دسترسی داشته است.
حساب آزمایشی باید نقش مشخص و دادهٔ اختصاصی داشته باشد. اجرای موفق login نیز کافی نیست؛ معتبرماندن نشست در طول اسکن باید بررسی شود.
Automation Framework در ZAP امکان تعریف محیط، احراز هویت، مدیریت نشست و مراحل اسکن را فراهم می‌کند. مستندات Automation Framework
ZAP را چگونه وارد CI/CD کنیم؟
پیشنهاد اجرایی ما، اضافه‌کردن تدریجی تست‌هاست:
- ابتدا گزارش تولید کنید. تیم باید با نوع هشدارها و کیفیت پوشش آشنا شود.
- یافته‌ها را بررسی و اولویت‌بندی کنید. برای هر مورد، شواهد، اثر احتمالی و مسئول رسیدگی مشخص باشد.
- قواعد توقف انتشار را محدود و روشن تعریف کنید. توقف همهٔ انتشارها برای هر هشدار، می‌تواند فرایند را غیرقابل استفاده کند. از طرف دیگر، نادیده‌گرفتن عمومی هشدارها نیز ارزش تست را از بین می‌برد.
- اسکن عمیق‌تر را در محیط مناسب اجرا کنید. برای اسکن‌های طولانی‌تر، زمان اجرا، داده‌های آزمایشی و اثر بر سرویس‌های وابسته را از قبل مشخص کنید.
برای سناریوهای پیچیده‌تر، ZAP استفاده از Automation Framework را توصیه می‌کند. با یک فایل YAML می‌توان مراحل و سیاست نتیجهٔ اسکن را مدیریت کرد. گزینه‌های خودکارسازی ZAP
گزارش اسکن را چگونه به اقدام تبدیل کنیم؟
خروجی ابزار را فهرست قطعی آسیب‌پذیری‌ها تلقی نکنید. هر یافته باید با شواهد بررسی شود.
در فرایند پیشنهادی تیم، برای هر مورد این اطلاعات را ثبت کنید:
- مسیر و شرایط مشاهدهٔ مسئله
- شواهد قابل بازتولید
- نتیجهٔ بررسی فنی
- مسئول و موعد اصلاح
- نتیجهٔ تست مجدد
اگر موردی پذیرفته یا مستثنا می‌شود، دلیل و تاریخ بازبینی آن را ثبت کنید. گزارش‌ها نیز ممکن است اطلاعات درخواست و پاسخ داشته باشند؛ دسترسی به آن‌ها باید متناسب با محتوایشان باشد.
آیا گزارش بدون هشدار یعنی برنامه امن است؟
خیر. نتیجهٔ اسکن به محدوده، مسیرهای کشف‌شده، وضعیت احراز هویت و قواعد اجراشده وابسته است.
برای مثال، نبود یافته در یک endpoint بررسی‌نشده، اطلاعاتی دربارهٔ امنیت آن نمی‌دهد. همچنین خطاهای منطق کسب‌وکار و سناریوهای پیچیدهٔ مجوزدهی ممکن است به ارزیابی دستی نیاز داشته باشند. محدودیت‌های تست خودکار ZAP
معیار موفقیت بهتر است ترکیبی از پوشش مسیرهای مهم، کیفیت یافته‌ها، زمان رسیدگی و تأیید اصلاح باشد؛ نه فقط تعداد هشدارهای گزارش.
برای طراحی Pipelineهای DevSecOps و یکپارچه‌سازی تست امنیتی با فرایند تحویل نرم‌افزار، با خدمات دواپس ایران آشنا شوید.
نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *
نظر دهید تعداد کاراکتر مانده: 300