جدار حماية تطبيقات الويب WAF: كيف يصد SQLi وXSS والبوتات

ما هو جدار حماية تطبيقات الويب WAF؟

جدار حماية تطبيقات الويب (WAF) هو طبقة أمان تجلس بين المستخدم وتطبيقك، تفحص كل طلب HTTP وHTTPS قبل أن يصل إلى الخادم، وتوقف الطلبات الخبيثة التي تحاول استغلال ثغرات في الكود. بخلاف جدار الشبكة الذي يفحص عناوين IP والمنافذ فقط، يفهم WAF محتوى الطلب نفسه: المسار، ورؤوس HTTP، وملفات الكوكيز، وحقول النماذج، وجسم الطلب. هذا الفهم على مستوى التطبيق هو ما يمكّنه من التمييز بين طلب تسجيل دخول عادي وطلب يحمل حمولة حقن SQL.

الحاجة إليه ليست ترفاً. بحسب تقرير OWASP، ظلت ثغرات الحقن ضمن أخطر عشر ثغرات ويب لأكثر من عشرين سنة متتالية، وتشير تقارير الصناعة إلى أن قرابة 43% من هجمات اختراق البيانات تستهدف تطبيقات الويب مباشرة. الطلب الخبيث لا يحتاج منفذاً مفتوحاً غير معتاد، بل يدخل من المنفذ 443 نفسه الذي يخدم موقعك، مغلّفاً كطلب HTTPS شرعي. جدار الشبكة يمرره لأنه لا يقرأ ما بداخله، بينما WAF يفتحه ويحلل نيّته.

في كلاود، تجلس هذه الطبقة أمام الاستضافة السحابية والخوادم الافتراضية داخل مراكز البيانات في الرياض، فيُفحص الطلب ويُمرَّر أو يُحجب في أقل من ميلي ثانية إضافية، مع زمن استجابة أساسي قرابة 8ms من داخل المملكة مقابل 100 إلى 120ms للسيرفرات الخارجية. الفحص الأمني لا يعني بطئاً محسوساً، لأنه يجري محلياً وبقرب جغرافي من المستخدم السعودي.

كيف يعمل WAF من الداخل

يعمل WAF كوكيل عكسي (reverse proxy) أو كوحدة داخل خادم الويب مثل ModSecurity على Apache أو Nginx. يستقبل الطلب، يفكّ تغليفه، يطبّق مجموعة قواعد عليه، ثم يقرر: تمرير، حجب، تسجيل، أو تحدٍّ. القرار يبنى على نموذجين أساسيين يعملان معاً غالباً.

النموذج السلبي (القائمة السوداء)

يعتمد على توقيعات وأنماط معروفة للهجمات. مجموعة القواعد الأساسية OWASP Core Rule Set تضم أكثر من 200 قاعدة تغطي حقن SQL، وXSS، وحقن الأوامر، واختراق المسارات. أي طلب يطابق نمطاً خبيثاً يُحجب. ميزته السرعة والوضوح، وعيبه أنه يلاحق الهجمات المعروفة فقط.

النموذج الإيجابي (القائمة البيضاء)

يعرّف الشكل المسموح للطلب: أي حقول يقبلها كل مسار، وما أطوالها، وما أنواع بياناتها. كل ما يخرج عن هذا الشكل يُرفض حتى لو لم يطابق توقيع هجوم معروف. هذا النموذج يحمي من هجمات اليوم صفر (zero-day) لأنه يسمح بالمعروف الآمن بدل أن يلاحق المجهول الخبيث، لكنه يتطلب ضبطاً دقيقاً لكل تطبيق.

الأنظمة الحديثة تضيف طبقة تقييم مخاطر تراكمية: كل قاعدة تخالفها الطلبات تضيف نقاطاً، فإذا تجاوز المجموع عتبة معينة يُحجب الطلب. هذا يقلل الإنذارات الكاذبة، إذ قد لا تكفي مخالفة واحدة بسيطة للحجب بينما يكفي تراكم عدة إشارات مشبوهة. الدراسات تشير إلى أن الإنذارات الكاذبة كانت السبب الأول لتعطيل فرق الأمن لجدرانها، لذا صار ضبط العتبة جوهرياً.

أنماط نشر WAF

يُنشر WAF بثلاثة أنماط رئيسية، ولكل منها موقعه في المعمارية:

• WAF قائم على المضيف: يعمل كوحدة داخل خادم الويب نفسه مثل ModSecurity، يمنح تحكماً دقيقاً وقرباً كاملاً من التطبيق، مقابل استهلاك موارد الخادم.
• WAF على مستوى الشبكة: جهاز أو وحدة أمام مجموعة خوادم، يخدم عدة تطبيقات بزمن استجابة منخفض، مناسب للبنى الكبيرة.
• WAF سحابي مُدار: طبقة أمام البنية تُحدَّث قواعدها آلياً، ويصل قرابة 99% من الطلبات المفحوصة إلى الخادم في أقل من ميلي ثانية إضافية.

الوضع الافتراضي عند بدء أي WAF يجب أن يكون التسجيل فقط (detection mode) لأيام أو أسابيع قبل تفعيل الحجب (prevention mode)، حتى تُرصد الإنذارات الكاذبة وتُضبط القواعد على حركة التطبيق الحقيقية دون تعطيل مستخدم شرعي.

كيف يوقف WAF حقن SQL

حقن SQL (SQLi) يحدث حين يُدرج المهاجم كوداً في حقل إدخال ليصبح جزءاً من استعلام قاعدة البيانات. مثال كلاسيكي في حقل اسم المستخدم يحاول تجاوز التحقق. الأثر مدمّر: تسريب كامل لقاعدة البيانات، أو حذفها، أو تعديل صلاحيات. رغم قدمها ما زالت SQLi ضمن أكثر ثلاث فئات ثغرات تكراراً بحسب OWASP، وقد بقيت على القائمة منذ 2003.

يكشفها WAF عبر عدة إشارات مجتمعة:

• وجود كلمات مفتاحية للاستعلامات مثل UNION وSELECT وDROP في مواضع لا يُتوقع فيها إدخال نصي حر.
• أحرف وتسلسلات مشبوهة مثل علامات الاقتباس المنفردة، والتعليقات، والفواصل المنقوطة داخل قيم النماذج.
• محاولات التمويه عبر الترميز، مثل ترميز URL المزدوج أو تحويل الأحرف إلى صيغتها السداسية عشرية للتحايل على الفلاتر.

الأقوى أن WAF يفكّ الترميز ويطبّع الطلب (normalization) قبل الفحص، فيرى الحمولة بصورتها الحقيقية لا المموّهة. لكن يبقى WAF خط دفاع ثانياً لا بديلاً عن الاستعلامات المُعامَلة (parameterized queries) في الكود نفسه. الجمع بينهما هو الممارسة الصحيحة.

كيف يوقف WAF هجمات XSS

البرمجة عبر المواقع (XSS) تحقن كوداً برمجياً بلغة JavaScript في صفحة يشاهدها مستخدمون آخرون، فيسرق جلساتهم أو يعيد توجيههم أو يزرع محتوى خبيثاً. تبقى XSS من أوسع الثغرات انتشاراً، وتظهر في نسبة كبيرة من التطبيقات المفحوصة سنوياً، إذ تكفي نقطة إدخال واحدة غير مطهّرة لاستغلالها.

يرصد WAF أنماط XSS عبر البحث عن وسوم برمجية مشبوهة، ومعالجات أحداث تُحقن في السمات، ومحاولات استدعاء دوال حساسة داخل قيم يُفترض أنها نص عادي. حين يطبّع الطلب يكشف المتغيرات المموّهة بالترميز أو بتغيير حالة الأحرف، ومثل SQLi، الحماية الكاملة تتطلب تطهير المخرجات (output encoding) في التطبيق، بينما يوفّر WAF شبكة أمان تصد الموجات الآلية والمحاولات المعروفة قبل بلوغ الكود.

كيف يتعامل WAF مع البوتات

ليست كل الحركة الآلية خبيثة، لكن تقارير الصناعة تقدّر أن قرابة نصف حركة الإنترنت العالمية آلية، وأن ثلثها تقريباً بوتات ضارة تفحص الثغرات، وتجرّب كلمات المرور، وتكشط المحتوى. WAF يميّز البوت الخبيث عبر عدة أساليب:

• تحديد المعدل (rate limiting): حجب أو إبطاء مصدر يرسل طلبات بوتيرة تفوق البشر بكثير، مثل مئات المحاولات في الثانية على صفحة تسجيل الدخول.
• تحليل البصمة: فحص ترتيب رؤوس HTTP وقيمة User-Agent وسلوك الجلسة لكشف الأدوات الآلية التي تنتحل صفة متصفح.
• التحديات: طرح تحدٍّ خفيف مثل JavaScript challenge أو CAPTCHA حين يشتبه في المصدر، فيعبره البشر ويعجز عنه الآلي البسيط.
• قوائم السمعة: حجب عناوين IP معروفة بمصادر الهجوم أو شبكات البوت.

هذا يخفف هجمات حشو بيانات الاعتماد (credential stuffing) التي تعتمد على تجربة ملايين أزواج اسم وكلمة مرور مسربة، ويقلل حمل الكشط الذي يستنزف موارد الخادم دون أي عائد.

الفرق بين WAF وجدار الشبكة

الخلط بينهما شائع، لكنهما يعملان على طبقتين مختلفتين من نموذج OSI. جدار الشبكة يعمل على الطبقتين الثالثة والرابعة (IP والمنافذ)، بينما WAF يعمل على الطبقة السابعة (التطبيق).

جدار الشبكة

يقرر بناءً على عنوان المصدر والوجهة، والمنفذ، والبروتوكول. يسأل: هل هذا الاتصال مسموح أصلاً؟ يحجب منفذاً مغلقاً أو نطاق IP محظوراً، لكنه لا يعرف ما بداخل حزمة HTTPS الشرعية القادمة على المنفذ 443. بالنسبة له، طلب تسجيل دخول عادي وطلب يحمل حقن SQL متطابقان تماماً.

جدار حماية التطبيقات

يقرأ محتوى الطلب على مستوى HTTP. يسأل: ماذا يفعل هذا الطلب المسموح؟ يميّز الحمولة الخبيثة داخل حقل شرعي على منفذ شرعي. لهذا لا يُغني أحدهما عن الآخر، بل يكمّلان بعضهما ضمن نموذج الدفاع المتعدد الطبقات (defense in depth). الشبكة تحكم من يدخل، والتطبيق يحكم ماذا يُفعَل بعد الدخول.

جدول مبسّط للفرق:

• الطبقة: الشبكة عند 3 و4، التطبيق عند 7.
• الوحدة المفحوصة: الشبكة تفحص الحزم والمنافذ، التطبيق يفحص طلبات HTTP الكاملة.
• يوقف: الشبكة توقف الوصول غير المصرح والمسح، التطبيق يوقف SQLi وXSS والبوتات.
• يجهله: الشبكة تجهل محتوى الطلب، التطبيق يجهل الاتصالات خارج نطاق الويب.

WAF على بنية سعودية

موقع الفحص يهم كثيراً. حين يجلس WAF داخل مركز بيانات سعودي، تبقى بيانات الطلب المفحوصة داخل المملكة، وهو ما تشترطه ضوابط الهيئة الوطنية للأمن السيبراني (NCA) وسياسات النفاذ الوطني للجهات الحكومية. الفحص خارج المملكة يعني تمرير كل طلب عبر بنية أجنبية، وهذا يرفع زمن الاستجابة إلى ما فوق 100ms ويطرح تساؤلات سيادة البيانات.

في كلاود، تُفعَّل طبقة WAF أمام الاستضافة والخوادم الافتراضية داخل الرياض، والتزويد تلقائي خلال ثوانٍ بعد الدفع، فتحصل على الحماية والقرب الجغرافي معاً. الأرقام واضحة: 8ms زمن أساسي، حجب على مستوى الطبقة السابعة، وبيانات لا تغادر حدود المملكة. الأمان الحقيقي ليس منتجاً واحداً، بل بنية: جدار شبكة يحكم الدخول، وWAF يحكم المحتوى، وكود نظيف يعامل المدخلات بحذر، وكلها مجتمعة تصنع الفرق.