چرا OWASP ZAP؟
ZAP برای مشاهده و تغییر ترافیک HTTP/HTTPS، تست دستی برنامه وب و اجرای workflowهای Automation طراحی شده است. پروژه برای کاربران تازه‌کار Quick Start و برای تیم‌های DevSecOps گزینه‌های Automation ارائه می‌کند. فقط روی برنامه‌های خودتان یا اهداف دارای مجوز تست استفاده شود.
دریافت امن
برای دانلود از دکمه «دانلود رسمی» همین صفحه استفاده کنید. IROSG فایل installer این نرم‌افزار را mirror نمی‌کند تا کاربر همیشه به نسخه و signature رسمی سازنده دسترسی داشته باشد.
استفاده مسئولانه
در ابزارهای تحلیل، اسکن و Penetration Testing، Scope و مجوز روشن بخشی از کار فنی است. تنظیمات و رفتار ابزار را ابتدا در Lab بررسی کنید و سپس در محیط Production به‌کار ببرید.
ZAP را در جای درست چرخه توسعه قرار دهید
ZAP به تیم کمک می‌کند رفتار یک برنامه وب را از مسیر درخواست و پاسخ بررسی کند. این دید بیرونی مکمل بررسی کد و آزمون واحد است، زیرا آنچه واقعاً روی شبکه ارائه می‌شود ممکن است با تصور توسعه‌دهنده فرق داشته باشد. با این حال اسکن خودکار همه منطق کسب‌وکار را نمی‌فهمد. اینکه کاربر یک پروژه نباید گزارش پروژه دیگر را ببیند، معمولاً به سناریوی مشخص و هویت‌های آزمایشی نیاز دارد. بنابراین از ابتدا معلوم کنید چه سؤال‌هایی را ابزار پاسخ می‌دهد و چه سؤال‌هایی هنوز به آزمون دستی نیاز دارند.
برای شروع، یک نسخه آزمایشی برنامه با داده ساختگی انتخاب کنید. حساب‌های دارای نقش متفاوت، مسیرهای مهم و عملیات دارای اثر مانند حذف یا ثبت سفارش را فهرست کنید. محیط باید قابل بازنشانی باشد تا یک آزمون، داده لازم برای آزمون بعدی را نابود نکند. اگر سرویس بیرونی مانند پرداخت یا ارسال پیام وجود دارد، آن را به نمونه آزمایشی یا جایگزین کنترل‌شده وصل کنید. این آماده‌سازی کیفیت نتیجه را بالا می‌برد و از آلودگی داده واقعی جلوگیری می‌کند.
پراکسی و گواهی در آزمایش HTTPS
وقتی مرورگر از پراکسی عبور می‌کند، ابزار می‌تواند درخواست و پاسخ را برای بررسی نمایش دهد. برای HTTPS، رابطه اعتماد گواهی باید در محیط آزمایش به شکل درست تنظیم شود. این کار را در پروفایل مرورگر مخصوص آزمون انجام دهید تا تنظیمات روزمره کاربر بی‌دلیل تغییر نکند. پس از پایان، وضعیت اعتماد و پراکسی را به حالت مورد نظر برگردانید. مرورگری که هنوز به پراکسی خاموش اشاره می‌کند ممکن است به اشتباه خراب یا بدون اینترنت به نظر برسد.
قبل از هر اسکن، یک صفحه ساده را باز کنید و مطمئن شوید درخواست مورد انتظار در ابزار دیده می‌شود. سپس یک ورود آزمایشی انجام دهید و جریان هدایت‌ها و کوکی‌ها را بررسی کنید. اگر ترافیک دیده نمی‌شود، تنظیم پراکسی، پروفایل مرورگر و مسیر شبکه را بررسی کنید. اگر فقط HTTPS مشکل دارد، زنجیره اعتماد آزمایش را جدا بررسی کنید. غیرفعال کردن عمومی اعتبارسنجی گواهی در برنامه واقعی راه‌حل مناسبی برای این تمرین نیست.
مشاهده غیرفعال با آزمون فعال تفاوت دارد
تحلیل غیرفعال بر ترافیکی که از ابزار عبور می‌کند تکیه دارد و می‌تواند نشانه‌هایی در پاسخ یا تنظیمات پیدا کند. آزمون فعال درخواست‌های اضافی برای سنجش رفتار برنامه می‌فرستد و ممکن است اثر عملی داشته باشد. این تفاوت باید در برنامه آزمون روشن باشد. شروع با مرور عادی و تحلیل غیرفعال، شناخت سطح برنامه را آسان‌تر می‌کند. سپس آزمون فعال را برای محدوده مشخص و با نرخ متناسب اجرا کنید، نه اینکه همه نشانی‌های دیده‌شده را بدون بررسی هدف قرار دهید.
در محیط آزمایش، یک عملیات دارای اثر را مشخص کنید و تصمیم بگیرید آیا باید از اسکن کنار گذاشته شود یا با داده قابل بازنشانی اجرا شود. برای مثال، خروج از حساب، حذف رکورد یا ارسال اعلان می‌تواند جریان آزمون را تغییر دهد. ابزار نمی‌داند همه دکمه‌ها از نظر کسب‌وکار چه معنایی دارند. تعریف محدوده و استثناها بخشی از طراحی فنی آزمون است و باید همراه نتیجه نگه داشته شود تا بازبین بداند کدام بخش‌ها واقعاً پوشش داده شده‌اند.
کشف مسیرها و محدودیت پوشش
خزنده فقط مسیرهایی را می‌بیند که بتواند کشف و دنبال کند. برنامه تک‌صفحه‌ای، مسیرهای وابسته به نقش و فرم‌های چندمرحله‌ای ممکن است به روش متفاوتی برای پیمایش نیاز داشته باشند. نبود هشدار در یک بخش می‌تواند به معنی نرسیدن ابزار به آن باشد. فهرست مسیرهای کشف‌شده را با فهرست قابلیت‌های محصول مقایسه کنید. اگر صفحه گزارش یا تنظیمات کاربر غایب است، قبل از تفسیر نتیجه، مشکل پوشش را حل کنید.
یک سناریوی مرور دستی کوتاه می‌تواند مکمل کشف خودکار باشد. با حساب آزمایشی وارد شوید، چند عملیات نماینده انجام دهید و ترافیک را ثبت کنید. سپس بررسی کنید درخواست‌های API مهم در محدوده قرار گرفته‌اند. برای برنامه دارای API مستند، استفاده از تعریف معتبر رابط نیز می‌تواند به شناخت مسیرها کمک کند، اما تعریف ممکن است قدیمی باشد. نتیجه واقعی شبکه و مستند API را کنار هم ببینید تا اختلاف‌ها آشکار شوند.
احراز هویت و حفظ نشست
آزمون بخش‌های محافظت‌شده نیازمند نشست معتبر است. اگر ابزار پس از چند دقیقه از حساب خارج شود، ممکن است به جای صفحات اصلی فقط صفحه ورود را بارها بررسی کند. یک نشانه قابل اعتماد برای وارد بودن و خارج بودن تعریف کنید و در طول اجرا وضعیت را مشاهده کنید. موفق بودن ورود اولیه کافی نیست. چرخش کوکی، انقضای نشست و هدایت به سامانه هویت می‌توانند پوشش را در میانه آزمون تغییر دهند.
برای کنترل دسترسی، دست‌کم دو حساب با نقش یا مالکیت متفاوت داشته باشید. درخواست مربوط به منبع حساب اول را در چارچوب آزمون مجاز با حساب دوم بررسی کنید و انتظار را پیشاپیش بنویسید. پاسخ موفق شبکه لزوماً دسترسی مجاز نیست؛ محتوا و اثر عملیات را نیز ببینید. در مقابل، پاسخ خطا بدون بررسی داده برگشتی ممکن است هنوز اطلاعات حساس را در متن آشکار کند. این سناریوها را به نمونه‌های ساختگی محدود کنید تا گزارش قابل اشتراک و بازتولید باشد.
خواندن هشدار به عنوان یک فرضیه
هشدار ابزار باید بررسی شود: درخواست چه بوده، پاسخ چه نشانه‌ای داشته و اثر واقعی چیست؟ شدت پیشنهادی ابزار نقطه شروع است، نه اولویت نهایی همه سازمان‌ها. یک مسئله در صفحه عمومی و همان مسئله در مسیر مدیریت داده حساس ممکن است اهمیت متفاوتی داشته باشد. برای هر یافته تأییدشده، پیش‌شرط، مسیر بازتولید و اثر قابل مشاهده را بنویسید. از تبدیل نام یک قاعده به ادعای قطعی آسیب‌پذیری بدون شاهد خودداری کنید.
موارد مثبت کاذب را با دلیل ثبت کنید تا در اجرای بعدی دوباره از صفر بررسی نشوند. اما حذف کلی یک دسته هشدار برای خاموش کردن نویز می‌تواند یافته واقعی آینده را پنهان کند. استثنا بهتر است محدود به مورد مشخص و دارای توضیح باشد. اگر تنظیم یا نسخه برنامه تغییر کرد، استثنا را بازبینی کنید. گزارش ابزار باید به دانش قابل نگهداری تبدیل شود، نه فایلی که فقط روز اجرای اسکن دیده می‌شود.
وارد کردن آزمون به خط تحویل
برای اجرای خودکار، محیط و داده اولیه باید قابل تکرار باشند. نسخه ابزار، افزونه‌ها و پیکربندی آزمون را مشخص کنید. اگر هر اجرا با نسخه یا داده متفاوت انجام شود، مقایسه نتایج دشوار خواهد بود. ابتدا یک مجموعه کوچک از مسیرهای حیاتی را خودکار کنید و زمان اجرا و نرخ خطا را اندازه بگیرید. سپس پوشش را افزایش دهید. یک اسکن طولانی و ناپایدار ممکن است به مرور از خط تحویل کنار گذاشته شود و ارزش عملی خود را از دست بدهد.
معیار شکست ساخت را آگاهانه انتخاب کنید. همه هشدارهای تازه الزاماً نباید یک رفتار یکسان داشته باشند؛ یافته تأییدشده پرخطر با هشدار اطلاعاتی متفاوت است. در آغاز می‌توانید نتیجه را برای بازبینی تولید کنید و پس از تثبیت قواعد، شرایط توقف را فعال کنید. استثناها باید نسخه‌بندی و دارای مالک باشند. هدف این است که خط تحویل بازخورد قابل اقدام بدهد، نه اینکه تیم برای عبور از هشدارهای نامفهوم همه کنترل را خاموش کند.
حفاظت از گزارش و داده آزمون
گزارش اسکن ممکن است شامل کوکی، پارامتر درخواست، نام داخلی و بخش‌هایی از پاسخ باشد. پیش از ارسال به سامانه تیکت یا اشتراک عمومی، داده حساس را حذف کنید. حساب‌های آزمون باید دسترسی محدود و عمر مشخص داشته باشند. اگر برای بازتولید نیاز به نشست معتبر است، روش ایجاد نشست را توضیح دهید و خود راز را در گزارش نگذارید. این کار باعث می‌شود گزارش هم مفید بماند و هم به منبع تازه افشای اطلاعات تبدیل نشود.
پس از پایان، داده‌های ساختگی و حساب‌های موقت را طبق برنامه پاک یا بازنشانی کنید. اگر اسکن رکوردهای زیادی ساخته است، اثر آنها بر آزمون‌های بعدی را بررسی کنید. زمان و محدوده اجرا را در لاگ تغییرات محیط ثبت کنید تا تیم عملیات ترافیک آزمایشی را با حادثه واقعی اشتباه نگیرد. هماهنگی این اطلاعات به معنای نادیده گرفتن هشدار نیست؛ امکان می‌دهد هشدار با زمینه درست تحلیل شود.
ارزیابی اصلاح و محدودیت نتیجه
پس از رفع یک یافته، همان درخواست بازتولید و یک مسیر سالم مرتبط را دوباره آزمایش کنید. اصلاحی که مسئله را می‌بندد ولی قابلیت اصلی را از کار می‌اندازد کامل نیست. سپس بررسی کنید آیا مسیر مشابه دیگری همان الگو را دارد. این کار باید بر اساس ساختار برنامه باشد، نه اجرای بی‌هدف همه آزمون‌ها. نتیجه نهایی را با عبارت دقیق بنویسید: کدام مسیر و کدام نسخه بررسی شد و چه رفتاری مشاهده شد. عبارت کلی «برنامه امن است» از نتیجه یک اسکن قابل استنتاج نیست.
ارزش ZAP زمانی بیشتر می‌شود که مشاهده ترافیک، شناخت برنامه و پیگیری اصلاح کنار هم قرار گیرند. یک اجرای خودکار می‌تواند شروع خوبی باشد، ولی مسئولیت تعریف انتظار، بررسی شواهد و تصمیم درباره خطر بر عهده تیم است. نگهداری سناریوهای کوچک و قابل تکرار، در طول زمان پوشش واقعی را بهتر از گزارش‌های بزرگ بدون پیگیری افزایش می‌دهد.
برای سنجش پیشرفت، تعداد مسیرهای آزموده، یافته‌های تأییدشده و زمان لازم تا اصلاح را کنار هم ببینید. کاهش تعداد هشدار بدون تغییر پوشش می‌تواند نشانه بهبود باشد، اما اگر ورود ابزار خراب شده و صفحات محافظت‌شده دیگر دیده نمی‌شوند، همان کاهش گمراه‌کننده است. هر گزارش باید وضعیت احراز هویت و محدوده واقعی مشاهده‌شده را نیز همراه داشته باشد. این دو شاهد ساده کمک می‌کنند نتیجه یک اجرای ناقص با نتیجه پاک اشتباه نشود و تصمیم انتشار بر پایه داده قابل اعتماد گرفته شود.
