«آیا فایروال برنامه کاربردی وب (WAF) شما برای مدلهای هوش مصنوعی پیشرفته آماده است؟» ما مرتباً این سؤال را از مشتریان خود میشنویم، بنابراین تصمیم گرفتیم خودمان پاسخ آن را پیدا کنیم.
وقتی صحبت از سوءاستفاده از برنامههای کاربردی میشود، کاری که مدلهای زبانی بزرگ (LLMs) واقعاً در آن مهارت دارند، تکرار و جهش دادن پیلودهای حمله سریعتر از هر هکر انسانی است. مدلهای زبانی بزرگ میتوانند از پاسخهای بلادرنگ برای تکرار و تغییر تکنیکهای خود استفاده کنند؛ مثلاً با آزمایش رمزگذاریهای مختلف، ارسال پیلود در بخش متفاوتی از درخواست HTTP، یا رفتن به آسیبپذیری بعدی برای آزمایش.
حتی پیش از ظهور مدلهای زبانی بزرگ، مهندسان امنیتی از دو رویکرد رایج برای آزمایش برنامهها استفاده میکردند: تست امنیت برنامههای کاربردی به صورت ایستا (Static) و پویا (Dynamic). روش اول کد را بدون اجرای آن برای شناسایی آسیبپذیریها تجزیهوتحلیل میکند، در حالی که روش دوم برنامههای در حال اجرا را برای یافتن نواقص زمان اجرا بررسی میکند. کارهای زیادی در زمینه اسکن کد با مدلهای هوش مصنوعی پیشرفته انجام شده است، از جمله جزئیاتی درباره چگونگی ساخت ابزار تست آسیبپذیری خودتان (how to build your own harness).
برای پروژه شرح دادهشده در این مقاله، ما یک رویکرد پویا اتخاذ کردیم: وادار کردن مدل زبانی بزرگ به عمل کردن به عنوان یک هکر برای ارزیابی اینکه آیا یک فایروال برنامه کاربردی وب (WAF) وظیفه خود را به درستی انجام میدهد یا خیر. مدل زبانی بزرگ هیچ دیدی نسبت به کد منبع نداشت، قوانین فایروال برنامه کاربردی وب (WAF) را نمیدید و تنها میتوانست دادههای پاسخ HTTP انتخابشده را ببیند.
ما یک آزمایشکننده فایروال برنامه کاربردی وب (WAF) ساختیم که با اکسپلویتهای شناختهشده شروع میشود و سپس با تغییر نحوه رمزگذاری یا تحویل آن، تکرار میکند، دوباره آن را میفرستد و از پاسخ برای انتخاب تغییر بعدی استفاده میکند. درخواستی که مسدود نشده بود، به جای یک اکسپلویت تاییدشده، به عنوان سرنخی برای بررسی انسانی تبدیل شد.
ما این آزمایشکننده را روی یک محیط استیجینگ مجاز مشتری در شش دسته حمله اجرا کردیم و ۱,۱۰۷ تلاش را ثبت نمودیم. پس از بررسی درخواستهای مسدودنشده و حذف موارد نامعتبر، خوشخیم، تکراری و خارج از محدوده، اکثریت قاطع حملات توسط فایروال برنامه کاربردی وب کلودفلر (Cloudflare WAF) مسدود شدند. درخواستهایی که عبور کردند به ما کمک کردند تا شناساییهای جدیدی ایجاد کنیم تا امنیت خود را به نفع همه مشتریان کلودفلر (Cloudflare) تقویت کنیم.
در اینجا توضیح خواهیم داد که چگونه سیستم را راهاندازی کردیم، انواعی از حملاتی که آزمایش کردیم، کدام بردارهای حمله راحتتر از فایروال عبور کردند و چگونه آن را اصلاح کردیم. مهمتر از همه، آنچه را که از این فرآیند آموختیم به اشتراک میگذاریم و اینکه چگونه این تمرین به یک بلوک ساختمانی اساسی در چرخه حیات توسعه فایروال برنامه کاربردی وب (WAF) ما تبدیل میشود.
در نهایت، ما راهنماییهایی ارائه میدهیم تا به شما کمک کند فایروال برنامه کاربردی وب (WAF) خود را به درستی در جلوی برنامه خود مستقر کنید و مهمتر از همه، نرمافزار خود را پچ (Patch) کنید. پیلودی که از فایروال عبور میکند همچنان برای موفقیت به یک برنامه قابل سوءاستفاده نیاز دارد، بنابراین بهروز نگه داشتن پشته (Stack) شما یکی از قویترین دفاعها در برابر مهاجمان باقی میماند.
حلقه تطبیقی چگونه کار میکند
برای آزمایش فایروال برنامه کاربردی وب (WAF) خود با مدلهای پیشرفته، سیستمی ساختیم که سناریوهای متعددی را تکرار میکند. یک سناریو به معنای انتخاب یک دسته حمله، قرار دادن ورودی در بخش خاصی از درخواست، شروع با نسخهای که فایروال از قبل مسدود کرده بود، و دادن تعداد مشخصی تلاش به آزمایشکننده برای امتحان تغییرات دیگر است. حلقه، مدلهای زبانی بزرگ (LLM) را دو بار اجرا میکند: اولین مورد فراخوان پیشنهاد (Proposal call) و دومین مورد فراخوان بررسی (Review call) است.
فراخوان اول درخواست اولیه، زمینه، تاریخچه کوتاهی از نتایج قبلی را دریافت میکند و تغییر بعدی را پیشنهاد میکند، سپس کد، درخواست را میسازد و ارسال میکند. فراخوان بررسی، زمینه درخواست، وضعیت پاسخ، هدرهای انتخابشده و بدنه پاسخ را دریافت میکند. حلقه زمانی متوقف میشود که جهشها دیگر تغییرات مفیدی تولید نکنند یا به حدتکلیف سختافزاری تلاشها رسیده باشد.
هر دو فراخوان مدل بدون دسترسی به اطلاعات داخلی فایروال برنامه کاربردی وب (WAF) کار میکنند. هیچکدام عبارتهای قانون، شناسههای قانون، جزئیات امتیاز حمله فایروال (WAF Attack Score) یا هویت لایه امنیتی که عمل کرده است را دریافت نمیکنند. ما سیستم را به جای بستهبندی یک ابزار تست نفوذ موجود، در پایتون (Python) پیادهسازی کردیم. این سیستم بازپخش HTTP، ارکستراسیون سناریو، ردیابی وضعیت و جمعآوری نتایج را مدیریت میکند.
در پیادهسازی فعلی، مدلها درخواستها را مستقیماً ارسال نمیکنند — کد کنترل میکند که در هر مرحله چه اتفاقی بیفتد. قبل از هر درخواست، نام میزبان هدف را در برابر یک لیست مجاز بررسی میکند، ریدایرکتها را غیرفعال میکند، تلاش را ثبت میکند و محدودیت تلاش را اعمال میکند. پس از هر درخواست، پاسخ را ثبت میکند و از بررسی مدل برای انتخاب مرحله از پیش تعریفشده بعدی استفاده میکند. متن پاسخ ممکن است در یک پرامپت بعدی ظاهر شود، بنابراین آزمایشکننده با آن به عنوان ورودی نامعتبر برخورد میکند. هیچکدام از فراخوانهای مدل نمیتوانند قانونی را مستقر کنند یا اجرای آن را تغییر دهند.
سیستم شواهد ساختاریافتهای را برای هر تلاش ثبت میکند.
شش دسته حمله در برابر یک پیکربندی فایروال
اجرای اصلی، یک محیط استیجینگ مجاز مشتری را که توسط فایروال برنامه کاربردی وب کلودفلر (Cloudflare WAF) محافظت میشود، هدف قرار داد. ما از یک عامل کاربر تست (User-Agent) مجاز استفاده کردیم تا کنترلهای ترافیک خودکار مشتری، آزمایش را قبل از رسیدن درخواستها به فایروال متوقف نکند.
ما ۴۵ سناریو را اجرا کردیم. برای هر کدام، به دنبال راههایی برای ارائه همان حمله به روشی متفاوت بودیم: رمزگذاری متفاوت، بخش متفاوتی از درخواست، یا همان مقصد که به روش دیگری نوشته شده است. از این تعداد، ۴۴ سناریو شش دسته حمله را پوشش دادند: اسکریپتنویسی میان سایت (XSS)، تزریق SQL (SQLi)، تزریق دستور (CMDi)، جعل درخواست سمت سرور (SSRF)، پیمایش مسیر یا گنجاندن فایل محلی (LFI)، و لاگ فور جی (Log4j). سناریوی باقیمانده مربوط به تزریق لاگ (Log injection) بود که به طور جداگانه گزارش شد.
فایروال برنامه کاربردی وب (WAF) در منطقه تست به صورت زیر پیکربندی شد: امتیازات مسدودسازی امتیاز حمله فایروال (WAF Attack Score) ۳۰ یا کمتر، فعال بودن تمام مجموعه قوانین مدیریتشده کلودفلر (Cloudflare Managed Ruleset)، و مجموعه قوانین اصلی OWASP (OWASP Core Ruleset) با سطح پارانویا (Paranoia Level) ۳.
برای اندازهگیری اصلی، ما ثبت کردیم که آیا فایروال هر درخواست را مسدود کرده است یا خیر. نتایج، مرز پیکربندیشده فایروال برنامه کاربردی وب را به عنوان یک کل توصیف میکنند، نه عملکرد هر قانون فردی یا مکانیزم شناسایی.
تطبیقپذیری در یک جلسه ضبطشده چگونه به نظر میرسید
در اینجا نمونهای از نحوه تطبیق مدل زبانی بزرگ (LLM) با یک حمله جعل درخواست سمت سرور (SSRF) در طول آزمایش آورده شده است.
سرویسهای متادیتای ابری میتوانند اعتبارنامههای موقتی را در معرض بارهای کاری قرار دهند. یک آسیبپذیری جعل درخواست سمت سرور (SSRF) میتواند به یک برنامه اجازه دهد آن دادهها را از طرف یک مهاجم دریافت کند. فایروال برنامه کاربردی وب (WAF) میتواند به متوقف کردن درخواست مخرب قبل از رسیدن به برنامه کمک کند، اما این تنها یک لایه حفاظتی است.
در این سناریوی جعل درخواست سمت سرور (SSRF)، آزمایشکننده همان آدرس متادیتای ابری را در اشکال مختلف (مانند نمایشهای صحیح، هشتی و نقطه پایانی همان آیپی) ارسال کرد و آن را در بخشهای مختلفی از درخواست قرار داد. فایروال همه آنها را به جز یکی مسدود کرد. در تلاش ۱۸، مدل همان ساختار درخواست را مانند تلاش مسدودشده قبلی حفظ کرد و به فرم نقطه پایانی سوئیچ کرد. کلاینت به جای مسدود شدن توسط فایروال، با یک ریدایرکت مواجه شد.
جدول زیر لحظات منتخب از جلسه را نشان میدهد. ستون فرضیه خلاصه میکند که مدل قبل از هر حرکت چه چیزی را تلاش میکرد بگوید. این یک رونوشت کلمه به کلمه نیست و دلیلی بر این نیست که توضیح درست بوده است.
تلاشهای ۱۷ و ۱۸ یک جفت جالب هستند: ساختار درخواست یکسان، نمایش میزبان متفاوت. یکی مسدود شد، دیگری مسدود نشد. این به ما یک سؤال مشخص داد: آیا نقطه پایانی نحوه خواندن مقصد توسط فایروال را تغییر میدهد؟ این یک سرنخ برای بررسی بود، اما مدرکی مبنی بر دسترسی به متادیتا نبود.
این یکی از مسیرهای منتخب در میان ۴۵ سناریو بود. بخش بعدی نشان میدهد که چگونه اجرای کامل را شمارش و ارزیابی کردیم.
چه چیزی پیدا کردیم
آزمایشکننده ما ۱,۱۰۷ تلاش تولید کرد و نتیجه کلی قوی بود به طوری که اسکریپتنویسی میان سایت (XSS)، LFI، تزریق SQL (SQLi) و Log4j پوشش تقریباً کاملی داشتند. در حالی که اجرا یافتههای مفیدی ایجاد کرد، سر و صدا (Noise) نیز تولید کرد. پس از بررسی انسانی، ۴۹ یافته قابل بررسی برای ما باقی ماند که ۴۸ مورد متعلق به تزریق دستور (CMDi) و جعل درخواست سمت سرور (SSRF) بودند.
در ادامه تفکیک آنها آورده شده است:
معیار | مقدار | معنای آن |
تلاشهای جهش ثبتشده | ۱,۱۰۷ | تکرارهای مدل در ۴۵ سناریوی فعال؛ همه نتیجه قابل استفادهای تولید نکردند |
مجموعه نتایج پس از ارزیابی | ۶۰۷ | ۵۵۸ درخواست مسدودشده به علاوه ۴۹ یافته مستند مربوط به فایروال |
درخواستهای مسدودشده | ۵۵۸ | فایروال این موارد را قبل از رسیدن به برنامه متوقف کرد |
یافتههای مرتبط با فایروال | ۴۹ | برای تجزیهوتحلیل اصلاحی پس از بررسی انسانی مستند شده است |
بقیه نتیجهای تولید نکردند که ارزش شمارش به عنوان یافته را داشته باشد، زیرا مدل نتوانست یک درخواست HTTP قابل استفاده تولید کند، برخی قبل از رسیدن به هدف شکست خوردند، یا پیلود تولیدشده خوشخیم بود.
هنگامی که یک درخواستی مسدود نمیشد، قبل از شمارش آن به عنوان یک یافته، پنج سوال را بررسی میکردیم:
سوال | چرا اهمیت دارد |
آیا آزمایشکننده واقعاً یک درخواست معتبر ارسال کرده است؟ | اگر مدل با شکست مواجه میشد یا درخواست هرگز به هدف نمیرسید، نتیجه چیزی درباره فایروال به ما نمیگوید. |
آیا درخواست به وضوح مسدود نشده بود؟ | یک پاسخ مبهم برای شمارش کافی نیست. |
آیا درخواست همچنان مخرب بود؟ | تغییر یک درخواست برای عبور دادن آن از فایروال همچنین میتواند آن را بیخطر کند. |
آیا رفتار متعلق به فایروال بود؟ | برخی حملات فقط از طریق مسیرهای دیاناس (DNS) یا شبکه کار میکنند که فایروال نمیتواند در زمان درخواست متوقف کند. |
آیا مهندسان میتوانستند آن را به طور ایمن بازتولید کنند؟ | یک اصلاح به یک مورد آزمایشی پایدار با نتیجه مورد انتظار روشن نیاز دارد. |
ما هر چیزی را که آن بررسیها را رد نکرده بود حذف کردیم و موارد تکراری را ترکیب کردیم. آنچه باقی ماند به ورودی کار قانون، نرمالسازی و کاهش خطر تبدیل شد.
یافتهها به شناساییها تبدیل شدند
هر یافتهای به یک قانون جدید نیاز نداشت. برخی به شکافهایی در پوشش قوانین مدیریتشده (Managed Rules) موجود اشاره داشتند. برخی دیگر به نحوه نرمالسازی درخواست توسط فایروال اشاره داشتند یا متعلق به کنترل امنیتی دیگری بودند. ما هر مورد را بازپخش کردیم و تصمیم گرفتیم تغییر کجا باید اتفاق بیفتد.
ما یافتههای مرتبط را در چهار مجموعه از قوانین نامزد گروهبندی کردیم، هر یافته را تأیید کردیم و نامزدها را در برابر ترافیک زنده آزمایش کردیم قبل از اینکه هر قانونی بتواند از ترافیک مشتری محافظت کند.
قبل از اینکه یک قانون جدید یا بهروزرسانیشده بتواند از ترافیک مشتری محافظت کند، تأثیر آن را بر ترافیک قانونی بررسی میکنیم و خطر مثبت کاذب (False-positive) را ارزیابی میکنیم. برخی از مسائلی که هنگام ارزیابی یک نامزد قانون جدید پیدا میکنیم عبارتند از:
مسئله | مرحله بعدی |
شناسایی گمشده یا محدود | بررسی اینکه آیا قوانین موجود یافته را پوشش میدهند یا خیر |
ورودیهای معادل به طور متفاوتی تفسیر میشوند | بررسی موتور یا نرمالسازی |
خطر مثبت کاذب خیلی زیاد است | بازبینی یا رد نامزد |
این کار به سه تغییر در مجموعه قوانین مدیریتشده کلودفلر (Cloudflare Managed Ruleset) کمک کرد: شناساییهای جدید برای جعل درخواست سمت سرور - میزبان مبهم (SSRF - Obfuscated Host) و جعل درخواست سمت سرور - پروتکل محدود (SSRF - Restricted Protocol) در انتشار ۲۱ ژوئیه، و بهبود قانون موجود جعل درخواست سمت سرور - ابری (SSRF - Cloud). تشخیص میزبان مبهم جعل درخواست سمت سرور مستقیماً از درخواستهایی به دست آمد که آدرسهای داخلی را در اشکال عددی غیر استاندارد رمزگذاری کرده بودند.
آنچه آموختیم
مدل تنها بخشی از آزمایش بود. ما همان سناریوها را با دو نسخه از یک خانواده مدل اجرا کردیم. آنها تغییرات متفاوتی تولید کردند - و همان مسائل زیرین در هر دو ظاهر شد. از آنجا که بازپخش درخواست و ضبط شواهد ثابت ماند، توانستیم اجراها را بدون در نظر گرفتن خروجی هر مدل به عنوان حقیقت مطلق مقایسه کنیم.
تلاشهای بیشتر در یک سناریو همیشه به معنای یافتن بیشتر نبود. برخی سناریوها نزدیک به انتهای محدودیت ۲۵ تلاشی، شروع به تکرار ایدههای قبلی کردند. ما با آزمایش درخواستهای اولیه بیشتر، دستههای حمله و مکانهای ورودی به جای extending یک دنباله، پوشش گستردهتری به دست آوردیم.
مدل درخواستها را تولید کرد. ما تصمیم گرفتیم کدام یک اهمیت دارند. یک درخواستی که مسدود نشده بود همچنان قبل از اینکه به یک یافته، کاهش خطر یا تست رگرسیون تبدیل شود، به بازپخش و بررسی انسانی نیاز داشت. بدون آن بررسی، هیچ یافتهای وجود نداشت.
کارهایی که مشتریان اکنون میتوانند انجام دهند
فایروال برنامه کاربردی وب (WAF) تنها یک لایه از شناساییها است که میتوانید مستقر کنید. وقتی تمام حفاظتهای موجود را مستقر میکنید، اثربخشی پشته کلی خود را افزایش میدهید.
اول از همه، بررسی کنید که قوانین مدیریتشده و امتیاز حمله فایروال به درستی در جلوی برنامه شما راهاندازی شدهاند (set up correctly). سایر ابزارهایی که میتوانید مستقر کنید عبارتند از امنیت API، رباتها و تشخیص تقلّب، و هوش تهدید برای تقویت بیشتر وضعیت خود. به عنوان مثال، کنترلهای امنیتی مثبت (positive security controls) لایه متفاوتی را اضافه میکنند: به جای جستجوی تنها الگوهای حمله شناختهشده، شکلهای درخواستی را که یک برنامه انتظار دارد تعریف میکنند و ورودیهای خارج از آن قرارداد را شناسایی میکنند. این کار سطح حمله شما را به شدت کاهش میدهد.
م مشتریان نیازی به بازپخش این آزمایش ندارند. برای به حداکثر رساندن تعداد قوانین مستقر شده در جلوی برنامه خود، توصیه میکنیم قوانین مدیریتشده را ابتدا در حالت لاگ (Log first) اجرا کنید، درخواستهای منطبق را در رویدادهای امنیتی (Security Events) بررسی کنید و قبل از انتقال یک قانون به حالت مسدود (Block)، تأیید کنید که ترافیک قانونی تحت تأثیر قرار نگرفته است. از طرف دیگر، مشتریان میتوانند با تیم حساب کاربری خود تماس بگیرند تا تشخیص امضای حمله (Attack Signature Detection) را روی مناطق خود فعال کنند. این ویژگی جدید نحوه بررسی ترافیک منطبق و نحوه استقرارهای شناسایی امضا را ساده میکند. اگر از قبل تست امنیت برنامه کاربردی را انجام میدهید، آن آزمایشها را در برابر یک نام میزبان استیجینگ محافظتشده توسط همان کنترلهای کلودفلر مانند پروداکشن اجرا کنید.
مراحل بعدی
با ترکیب آزمایش مبتنی بر هوش مصنوعی تطبیقی با تریاژ و اعتبارسنجی انسانی، شکافهای شناسایی را پیدا کردیم که تستهای ثابت ممکن است از دست بدهند و آن یافتهها را به حفاظتهای قویتر فایروال تبدیل کردیم و نرخ مسدودسازی خود را بهبود بخشیدیم. در مقاله آینده، نتایج حاصل از آزمایشهای بیشتر با استفاده از رویکرد جعبه سفید (White-box) را به اشتراک خواهیم گذاشت که در آن مدل هم آسیبپذیریهای برنامه و هم قوانین فایروال محافظ آن را میداند.
منبع: blog.cloudflare.com