اختبرت Cloudflare جدار حماية تطبيقات الويب (WAF) التابع لها باستخدام نماذج ذكاء اصطناعي متقدمة قادرة على تعديل الطلبات الهجومية بعد كل محاولة، بدلاً من الاكتفاء بمجموعة ثابتة من الاختبارات. نفذت الشركة التجربة في بيئة staging خاصة بعميل وبموافقة مسبقة، وسجلت 1,107 محاولة ضمن 45 سيناريو.
الفكرة الأساسية هي محاكاة جانب من سلوك المهاجم الذي يستطيع تجربة ترميزات مختلفة، ونقل الحمولة إلى مواضع أخرى داخل طلب HTTP، أو تغيير طريقة تمثيل الوجهة، ثم استخدام الاستجابة لاختيار المحاولة التالية. ولم يحصل النموذج على شفرة التطبيق أو قواعد WAF الداخلية أو أرقام القواعد، بل تعامل فقط مع سياق الطلب وبيانات استجابة HTTP محددة.
كيف عمل الاختبار التكيفي؟
بدأ كل سيناريو بطلب معروف بأن WAF يحجبه، ثم اقترح النموذج تعديلاً جديداً. بعد إرسال الطلب، راجع نموذج آخر أو استدعاء مراجعة من النموذج الاستجابة، قبل أن يحدد النظام الخطوة التالية ضمن حد أقصى للمحاولات. تولت الشفرة تنفيذ الطلبات وتسجيل الأدلة، كما تحققت قبل كل محاولة من اسم النطاق عبر قائمة مسموحة، وأوقفت إعادة التوجيه، ومنعت النظام من تغيير قواعد الحماية أو نشرها.
شملت 44 من السيناريوهات ست فئات: البرمجة النصية عبر المواقع (XSS)، وحقن SQL، وحقن الأوامر، وتزوير الطلبات من جانب الخادم (SSRF)، واجتياز المسارات أو تضمين الملفات المحلية (LFI)، وهجمات Log4j. أما السيناريو الخامس والأربعون فتناول حقن السجلات بصورة منفصلة.
من 1,107 محاولة إلى 49 نتيجة قابلة للتحقيق
كان أداء WAF قوياً إجمالاً، مع تغطية شبه كاملة لفئات XSS وLFI وSQLi وLog4j. وبعد المراجعة البشرية، بقيت 49 نتيجة تستحق التحقيق، انتمت 48 منها إلى فئتي حقن الأوامر وSSRF. وبلغ عدد الطلبات المحجوبة 558، بينما استُبعدت محاولات أخرى لأنها كانت غير صالحة، أو حميدة، أو مكررة، أو لم تصل إلى الهدف.
لم تعتبر Cloudflare الطلب غير المحجوب ثغرة مؤكدة. اشترطت أن يكون الطلب صالحاً ووصل إلى الهدف، وأن يبقى ضاراً بوضوح، وأن يكون السلوك منسوباً إلى WAF، وأن يتمكن المهندسون من إعادة إنتاجه بأمان. هذا التفريق مهم لأن تجاوز WAF لا يثبت وحده نجاح استغلال التطبيق أو الوصول إلى بيانات حساسة.
مثال على فجوة في اكتشاف SSRF
في أحد السيناريوهات، غيّر النظام طريقة كتابة عنوان خدمة البيانات الوصفية السحابية، واستخدم تمثيلات رقمية مختلفة ووضع العنوان في أجزاء متعددة من الطلب. حُجبت معظم المحاولات، لكن إحدى المحاولات التي استخدمت تمثيلاً بنقطة لاحقة أدت إلى إعادة توجيه بدلاً من حجب WAF. اعتبرت Cloudflare ذلك إشارة تستحق التحقيق، لا دليلاً على الوصول إلى بيانات الاعتماد أو نجاح الاستغلال.
ما الذي تغير عملياً؟
راجعت Cloudflare النتائج لتحديد ما إذا كانت تحتاج إلى قاعدة جديدة، أو إلى تحسين تطبيع الطلبات، أو إلى تدخل من طبقة أمنية أخرى. وأسهمت النتائج في ثلاثة تغييرات ضمن Managed Ruleset: إضافة اكتشافات SSRF - Obfuscated Host وSSRF - Restricted Protocol في إصدار 21 يوليو، وتحسين اكتشاف SSRF - Cloud. وجاء اكتشاف المضيف المموه مباشرة من طلبات استخدمت صيغاً رقمية غير اعتيادية لعناوين داخلية.
توضح التجربة أن الذكاء الاصطناعي هنا أداة لتوسيع مساحة الاختبار وليس بديلاً عن الحكم الهندسي. فقد أنتج نموذجان من العائلة نفسها تنويعات مختلفة، لكن المشكلات الأساسية ظهرت في كليهما. كما أن زيادة المحاولات داخل السيناريو الواحد لم تضمن اكتشاف نتائج إضافية؛ إذ بدأت بعض السلاسل بتكرار الأفكار، بينما وفرت زيادة نقاط البداية وفئات الهجوم ومواضع الإدخال تغطية أوسع.
وتبقى حدود WAF حاضرة: الحمولة التي تتجاوز الجدار لا تنجح إلا إذا كان التطبيق نفسه قابلاً للاستغلال، لذلك يظل تحديث البرمجيات وإصلاح الثغرات ضرورياً. كما توصي Cloudflare بتفعيل القواعد في وضع التسجيل أولاً، ومراجعة الطلبات المطابقة والأحداث الأمنية، ثم الانتقال إلى الحجب بعد التحقق من عدم تأثر الحركة المشروعة. وتخطط الشركة لاحقاً لعرض اختبار white-box يعرف فيه النموذج ثغرات التطبيق وقواعد WAF معاً.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.