تستی که تأیید می‌کند کاربر می‌تواند وارد حسابش شود، لزوماً بررسی نمی‌کند که اطلاعات نشست چگونه محافظت می‌شود یا برنامه در برابر ورودی غیرمنتظره چه رفتاری دارد.
تست امنیت پویای برنامه یا DAST روشی برای بررسی امنیت نرم‌افزار در حال اجراست. این روش کمک می‌کند رفتار واقعی برنامه از طریق صفحات وب، درخواست‌های HTTP و APIها ارزیابی شود.
پرسش اصلی DAST این است: برنامهٔ مستقرشده هنگام تعامل با ورودی‌ها و درخواست‌های امنیتی چه رفتاری نشان می‌دهد؟
DAST چگونه کار می‌کند؟
DAST مخفف Dynamic Application Security Testing است. در این روش، ابزار یا ارزیاب با برنامهٔ اجراشده تعامل می‌کند و پاسخ‌های آن را برای شناسایی ضعف‌های امنیتی بررسی می‌کند.
DAST معمولاً به دسترسی به کد منبع نیاز ندارد. بررسی ورودی و خروجی، برخی مسائل احراز هویت و خطاهای پیکربندی سرور از حوزه‌های کاربرد آن هستند. شناسایی مواردی مانند SQL Injection یا XSS نیز به قابلیت ابزار، مسیرهای در دسترس و نوع آزمون وابسته است. راهنمای DAST در OWASP
بنابراین، اجرای اسکن روی صفحهٔ اصلی سایت با ارزیابی جریان‌های داخلی یک سامانه یکسان نیست. محدودهٔ واقعی تست باید در کنار نتیجهٔ آن گزارش شود.
تفاوت DAST با SAST چیست؟
SAST کد یا سایر مصنوعات نرم‌افزار را بدون نیاز به اجرای برنامه بررسی می‌کند. DAST بر رفتار برنامهٔ در حال اجرا تمرکز دارد.
برای مثال، بررسی کد می‌تواند یک الگوی برنامه‌نویسی ناامن را آشکار کند؛ درحالی‌که تست پویا می‌تواند رفتار نسخهٔ مستقرشده را در برابر یک درخواست مشخص بررسی کند.
این دو روش پاسخ‌گوی پرسش‌های متفاوت‌اند. انتخاب یکی به‌عنوان جایگزین کامل دیگری، بخشی از دید امنیتی تیم را محدود می‌کند. راهنمای OWASP نیز DAST را در کنار دیگر فعالیت‌های امنیت نرم‌افزار قرار می‌دهد. راهنمای DevSecOps و DAST
چرا پوشش تست از تعداد هشدارها مهم‌تر است؟
فرض کنید گزارش یک اسکن هیچ هشدار مهمی ندارد. پیش از نتیجه‌گیری، باید بدانیم ابزار چه بخش‌هایی را دیده است.
آیا فقط صفحات عمومی بررسی شده‌اند؟ آیا درخواست‌های API کشف شده‌اند؟ آیا ابزار توانسته وارد حساب آزمایشی شود؟
یک گزارش بدون یافته، وقتی بخش مهمی از برنامه بررسی نشده، اطمینان زیادی ایجاد نمی‌کند. در ارزیابی پوشش، پیشنهاد می‌کنیم فهرست مسیرهای مهم را پیش از اجرا مشخص کنید و نتیجهٔ اسکن را با همان فهرست مقایسه کنید.
برای نمونه، در یک فروشگاه اینترنتی می‌توان این جریان‌ها را در برنامهٔ تست قرار داد:
- ورود و خروج کاربر
- جست‌وجو و مشاهدهٔ محصول
- مدیریت سبد خرید با دادهٔ آزمایشی
- مشاهدهٔ سفارش‌های حساب آزمایشی
- APIهای مرتبط با این فعالیت‌ها
این فهرست باید متناسب با کسب‌وکار باشد؛ تعداد زیاد URL به‌تنهایی معیار پوشش مناسب نیست.
اسکن احراز هویت‌شده چه اهمیتی دارد؟
بخش زیادی از قابلیت‌های سامانه‌ها پس از ورود قابل استفاده‌اند. اگر اسکنر خارج از نشست معتبر کار کند، ممکن است درخواست‌های آن مرتب به صفحهٔ ورود هدایت شوند.
در چنین شرایطی، پایان موفق فرایند اسکن به معنای بررسی موفق بخش داخلی نیست.
برای اجرای مناسب، حساب‌های آزمایشی با نقش‌های مشخص تعریف کنید و بررسی کنید نشست در طول تست معتبر می‌ماند. در سامانه‌ای با نقش‌های مختلف، نتیجهٔ تست حساب عادی را به حساب مدیر تعمیم ندهید. مدیریت جریان‌های احراز هویت یکی از بخش‌های مهم اجرای DAST است. راهنمای اجرای DAST
تفاوت بررسی غیرفعال و آزمون فعال
در ابزارهایی مانند ZAP، بررسی غیرفعال ترافیک درخواست و پاسخ را تحلیل می‌کند. اسکن فعال درخواست‌های آزمایشی برای شناسایی آسیب‌پذیری ارسال می‌کند.
آزمون فعال می‌تواند بر داده یا عملکرد برنامه اثر بگذارد؛ به همین دلیل باید روی مقصد مجاز و در محیطی متناسب با نوع تست اجرا شود. همچنین crawler یا مرور کاربر حتی هنگام تحلیل غیرفعال، همچنان با برنامه تعامل دارد. توضیح رسمی ZAP
برای شروع سازمانی، محیط آزمایشی دارای دادهٔ اختصاصی و امکان بازگردانی، انتخاب قابل‌کنترل‌تری است.
یک فرایند کاربردی برای اجرای DAST
پیشنهاد اجرایی ما این است که DAST را به یک چرخهٔ مشخص متصل کنید:
- محدوده را تعریف کنید. برنامه، نسخه، نقش‌های کاربری و مسیرهای هدف را ثبت کنید.
- محیط را آماده کنید. دادهٔ آزمایشی، حساب‌ها و سرویس‌های وابسته باید برای سناریوی تست مناسب باشند.
- پوشش را بررسی کنید. پیش از اعتماد به یافته‌ها، تأیید کنید مسیرهای مورد انتظار واقعاً بررسی شده‌اند.
- یافته‌ها را اعتبارسنجی کنید. شواهد، شرایط بازتولید و اثر احتمالی هر مورد را بررسی کنید.
- اصلاح و تست مجدد انجام دهید. بسته‌شدن یک مورد باید با تأیید نتیجهٔ اصلاح همراه باشد.
DAST در CI/CD چه جایگاهی دارد؟
DAST پس از آماده‌شدن نسخهٔ قابل اجرا می‌تواند به فرایند تحویل اضافه شود. برای شروع، بهتر است گزارش‌ها بررسی شوند و سپس قواعد توقف انتشار بر اساس یافته‌های معتبر و سیاست سازمان تعریف شوند.
توقف انتشار برای هر هشدار، بدون بررسی کیفیت آن، می‌تواند اعتماد تیم به آزمون را کاهش دهد. از طرف دیگر، تولید گزارش بدون مالک رسیدگی نیز به اصلاح مسئله منجر نمی‌شود.
برای هر یافته، مسئول، اولویت، موعد رسیدگی و وضعیت تست مجدد مشخص کنید.
آیا DAST همان تست نفوذ است؟
یک اسکن خودکار می‌تواند بخشی از ارزیابی امنیت باشد، اما معادل یک ارزیابی جامع نیست. سناریوهای پیچیدهٔ مجوزدهی، زنجیرهٔ چند ضعف و منطق اختصاصی کسب‌وکار ممکن است به بررسی انسانی نیاز داشته باشند.
ابزار ZAP نیز محدودیت‌های تست خودکار و نیاز به بررسی بیشتر را توضیح می‌دهد. راهنمای ارزیابی امنیت با ZAP
نتیجهٔ مفید DAST، صرفاً یک گزارش نیست؛ مجموعه‌ای از یافته‌های قابل بررسی و اقدام است که محدوده و محدودیت‌های آن روشن باشد.
برای آشنایی با اجرای عملی، مقالهٔ تست DAST با ZAP را بخوانید. همچنین برای یکپارچه‌سازی تست‌های امنیتی با Pipeline تحویل نرم‌افزار، می‌توانید با خدمات دواپس ایران آشنا شوید.
نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *
نظر دهید تعداد کاراکتر مانده: 300