أمن التطبيقات · مقال تقني معمّق

آلية عمل WAF من الداخل

كيف يتخذ جدار حماية تطبيقات الويب قراره فعليًا؟#

هذا المقال لا يشرح ما هو WAF فحسب، بل يشرح ما يحدث داخله فعليًا: كيف يقوم بتحليل طلب الويب، وكيف يقيّم مدى خطورته، ثم كيف يقرر السماح بمروره أو حجبه — والأهم، أين يمكن أن يخطئ هذا المنطق أو يفشل.

هذا المحتوى موجّه للمهندسين الذين يتولون تهيئة WAF وضبط قواعده، وتحسين دقته، والدفاع عن قرار استخدامه في البنية الأمنية للتطبيقات.

01 · البنية المعمارية

أين تتم عملية الفحص فعليًا؟#

يقوم جدار الحماية الشبكي التقليدي (Stateful Network Firewall) بتصفية حركة المرور اعتمادًا على عنوان IP، والمنفذ، وحالة جلسة TCP/UDP، أي ضمن الطبقتين الثالثة والرابعة من نموذج OSI (Layer 3/4).

في هذه المرحلة، لا يستطيع الجدار معرفة ما يوجد داخل طلب HTTP نفسه، لأنه ببساطة لم يتم التعامل مع طلب HTTP كطلب متكامل بعد. ما يراه هو حزم بيانات واتصالات على مستوى الشبكة والنقل، وليس محتوى مثل POST body أو cookies أو query parameters.

أما جدار حماية تطبيقات الويب (WAF) فيعمل على الطبقة السابعة (Layer 7)، أي طبقة التطبيقات. وهنا يستطيع التعامل مع طلب HTTP/HTTPS باعتباره طلبًا كاملًا. يقوم الـWAF بإنهاء جلسة HTTP(S)، أو بمراقبتها بعد فك تشفيرها، ثم يعيد بناء الطلب وتحليله بمكوناته المختلفة، مثل:

• HTTP Method — مثل GET أو POST

• Path — مسار الطلب

• Query String — المعاملات الموجودة في عنوان URL

• Headers — ترويسات HTTP

• Cookies — ملفات تعريف الارتباط

• Request Body — محتوى الطلب، بما في ذلك بيانات multipart/form-data

بعد ذلك، يطبّق قواعد الفحص والتحليل على هذا الطلب قبل أن يصل إلى خادم التطبيق الأصلي (Origin Server).

وهنا تظهر نقطة معمارية مهمة جدًا: يجب أن يكون الـWAF موجودًا عند نقطة إنهاء اتصال TLS أو قبلها بطريقة تتيح له الوصول إلى المحتوى بعد فك التشفير.

فإذا كان الجهاز أو الـProxy لا يرى سوى البيانات المشفرة، فلن يتمكن من فحص محتوى طلب HTTP. في هذه الحالة، سيقتصر دوره على تصفية الاتصالات على مستوى الشبكة، وهي وظيفة يستطيع جدار الحماية الشبكي القيام بها أصلًا.

لذلك، فإن أي قرار يتعلق بمكان وضع الـWAF داخل البنية التحتية يبدأ من هذا القيد الأساسي:

إذا لم يستطع الـWAF الوصول إلى محتوى طلب HTTP بعد فك تشفيره، فلا يمكنه إجراء فحص فعلي على مستوى التطبيق.

ومن هنا تبدأ جميع القرارات المعمارية المتعلقة بنشر الـWAF: أين يتم إنهاء TLS؟ ومن يملك القدرة على رؤية الطلب وفحصه قبل وصوله إلى التطبيق؟

الشكل 1 — جدار الحماية الشبكي يكتفي بتصفية الاتصالات ولا يرى محتوى الطلب إطلاقًا، بينما يجب أن يتموضع الـ WAF عند نقطة إنهاء TLS كي تتاح له فرصة قراءة هذا المحتوى أصلًا.

٢ · منهجية الكشف

النموذجان الإيجابي والسلبي في تقييم الأمان

يُبنى أي محرك قواعد داخل الـ WAF على واحدة من فلسفتين متعاكستين، وغالبًا ما تنتهي الأنظمة الإنتاجية إلى الجمع بينهما بشكل عملي.

نموذج الأمان السلبي (Negative Security Model)#

ويُعرف أيضًا باسم القائمة السوداء (Blocklisting). يقوم هذا النموذج بتحديد الأنماط المعروفة بأنها ضارة، مثل وجود كلمات أو عبارات خاصة بـSQL في أماكن غير متوقعة، أو استخدام وسوم script، أو تسلسلات تشير إلى محاولة Directory Traversal، ثم يحظر أي طلب يطابق أحد هذه الأنماط.

وهذه هي الفكرة التي تعمل بها محركات الكشف المعتمدة على التواقيع (Signatures)، مثل OWASP Core Rule Set في إعداداته الافتراضية.

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

نموذج الأمان الإيجابي (Positive Security Model)#

أما نموذج الأمان الإيجابي، أو القائمة البيضاء (Allowlisting)، فيعمل بطريقة معاكسة تمامًا. فبدلًا من تحديد ما هو ضار، يقوم بتحديد الشكل الدقيق الذي يُسمح للطلب المشروع أن يكون عليه.

يمكن أن يشمل ذلك:

• أسماء المعاملات (Parameters)

• أنواع البيانات

• أطوال القيم المسموح بها

• مخطط واجهة برمجة التطبيقات (API Schema)

• البنية المتوقعة للطلب

وأي طلب يخرج عن هذا النموذج يتم رفضه، سواء كان الانحراف ناتجًا عن هجوم معروف أو عن هجوم جديد لم يتم التعرف عليه من قبل.

ولهذا السبب، يستطيع هذا النموذج التعامل مع بعض هجمات اليوم صفر (Zero-Day) دون الحاجة إلى وجود توقيع مسبق لها؛ لأن الطلب يُرفض لمجرد أنه لا يتوافق مع الشكل المسموح به.

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

بعبارة مختصرة:

النموذج السلبي يسأل: «هل يبدو هذا الطلب كأنه هجوم معروف؟»

بينما النموذج الإيجابي يسأل: «هل هذا الطلب يطابق بالضبط ما نسمح به؟»

الشكل 2 — النموذج السلبي يتعامل مع الأنماط التي يعرفها مسبقًا، بينما يقوم النموذج الإيجابي برفض أي شيء لم يتم السماح به بشكل صريح. والموازنة الفعلية هنا هي بين نطاق التغطية الأمنية والجهد المطلوب لصيانة القواعد والسياسات.

من الناحية العملية: نادرًا ما يتم الاعتماد على نموذج القائمة البيضاء (Allowlisting) بشكل كامل، باستثناء بعض واجهات الـAPI المحدودة والواضحة المواصفات. أما معظم أنظمة WAF في بيئات الإنتاج، فتستخدم كنقطة انطلاق نموذجًا سلبيًا مضبوطًا بعناية، مثل OWASP Core Rule Set (CRS) أو مجموعة قواعد مُدارة.

ثم تتم إضافة قواعد مبنية على النموذج الإيجابي بشكل يدوي لعدد محدود من نقاط النهاية الحساسة، مثل:

• المصادقة (Authentication)

• الدفع (Payment)

• لوحة الإدارة (Admin)

وذلك عندما تكون حجم الأضرار المحتملة في حال اختراق هذه النقاط كبيرًا بما يكفي لتبرير الوقت والجهد اللازمين لصيانة هذه القواعد.

٣ · الآلية

مسار فحص الطلب

هذا هو الجزء الذي تتجاهله معظم المراجعات والمقالات التقنية: جدار حماية التطبيقات (WAF) لا يقوم بتطبيق تعبير نمطي (Regex) ضخم واحد على البايتات الخام للطلب. بل تعتمد محركات الفحص الفعلية — وتُعد بيئة ModSecurity المجهزة بقواعد OWASP CRS المرجع المعياري الذي تحاكيه الأنظمة الأخرى — على إمرار الطلب عبر مراحل متتابعة ومستقلة، لتكون النتيجة النهائية عبارة عن تقييم تراكمي (Score) يحسُب مستوى الخطر، وليس مجرد قرار مباشر بالقبول أو الرفض بناءً على تطابق قاعدة واحدة.

1. التطبيع (Normalization):
   أولًا، تتم معالجة الطلب وتحويله إلى صيغة موحدة يمكن تحليلها بشكل موثوق. ويشمل ذلك:

   • فك ترميز عناوين URL (URL Decoding)، وقد يتم ذلك بشكل متكرر لاكتشاف الترميز المزدوج (Double Encoding).

   • توحيد حالة الأحرف.

   • معالجة محارف Unicode المتشابهة بصريًا (Homoglyphs).

   • التعامل مع تسلسلات UTF-8 غير الطبيعية أو المفرطة في الطول.

   • تبسيط مسارات الملفات وإزالة الأجزاء التي يمكن استخدامها في Directory Traversal، مثل ..%2f و%2e%2e/.

   تجاهل هذه المرحلة يُعد من أكثر الطرق شيوعًا التي يمكن من خلالها تجاوز قواعد الـWAF في البيئات الحقيقية، لأن المهاجم قد يكتب الحمولة بطريقة مختلفة عن الشكل الذي تتوقعه القاعدة. وستتم مناقشة ذلك بالتفصيل في §5.

2. التحليل (Parsing): بعد تطبيع الطلب، يُقسَّم إلى مجموعات منظمة بحسب نوعها: معاملات GET، معاملات POST، الرؤوس، ملفات تعريف الارتباط، والملفات المرفوعة — وتُحلَّل كل حزمة من هذه الملفات المرفوعة (متعددة الأجزاء) على حدة، وحتى محتوى JSON المتداخل إن وُجد .

3. مطابقة القواعد (Rule Matching): تُقارَن كل مجموعة بقواعد مصنّفة حسب فئة الهجوم: حقن SQL، البرمجة النصية عبر المواقع (XSS)، تنفيذ الأوامر عن بُعد، تضمين الملفات المحلي أو البعيد، شذوذ في البروتوكول، وتوقيعات أدوات الفحص الآلي. ليس مستبعدًا أن يطابق طلب واحد قواعد من عدة فئات في آنٍ معًا.

4. تسجيل نقاط الشذوذ (Anomaly Scoring): بدلًا من حظر الطلب بمجرد تطابقه مع أول قاعدة، تقوم القواعد التي تم تشغيلها بإضافة نقاط إلى درجة الشذوذ، وتختلف قيمة النقاط حسب مستوى خطورة القاعدة.

   يستخدم OWASP CRS تقريبًا المستويات التالية:

   • Notice = نقطتان

   • Warning = 3 نقاط

   • Error = 4 نقاط

   • Critical = 5 نقاط

   وتتراكم هذه النقاط عبر الطلب بأكمله.

   وهذا يعني أن تطابق عدة قواعد منخفضة أو متوسطة الخطورة يمكن أن يؤدي في النهاية إلى تجاوز الحد المسموح به، حتى لو لم تكن أي قاعدة منفردة كافية لحظر الطلب

5. القرار (Decision): في نهاية سلسلة مراحل الفحص، تتم مقارنة درجة الشذوذ المتراكمة بالحد (Threshold) الذي تم ضبطه في إعدادات الـWAF.

   على سبيل المثال، يُستخدم 5 كنقطة بداية شائعة للطلبات الواردة في OWASP CRS.

   • أقل من الحد: يتم السماح بالطلب وإرساله إلى الخادم الأصلي (Origin).

   • يساوي الحد أو يتجاوزه: يتم حظر الطلب، وغالبًا تكون الاستجابة HTTP 403 Forbidden، مع تسجيل معرّفات القواعد (Rule IDs) .

   وبذلك يصبح القرار النهائي نتيجة تراكم عدة مؤشرات داخل الطلب، وليس مجرد قاعدة واحدة تقول: «تطابق → احظر».

الشكل 3 — خط سير ModSecurity وCRS: التطابقات الفردية لا تحظر الطلب بمفردها، وإنما تتجمّع كنقاط شذوذ على مستوى الطلب كاملًا، وهذا المجموع هو ما يُقارَن بالحد فعليًا.

هذا التصميم القائم على احتساب الدرجات هو السبب في أن ضبط مستوى الشك (Paranoia Level) في OWASP CRS له أهمية كبيرة.فعند رفع مستوى الشك، يتم تفعيل قواعد أكثر تشددًا، وتهدف إلى اكتشاف نطاق أوسع من الهجمات، لكنها في المقابل تزيد أيضًا احتمالية ظهور الإنذارات الكاذبة (False Positives).لذلك، فإن عملية الضبط الفعلية لا تتمثل في تغيير Threshold أو Paranoia Level كلٌّ على حدة، ولا في تشغيل أو تعطيل معرّفات القواعد (Rule IDs) يدويًا واحدة تلو الأخرى.بل إن مستوى الشك والحد المطلوب للحظر يجب ضبطهما معًا للوصول إلى التوازن المناسب بين مستوى الحماية واحتمالية حظر الطلبات المشروعة.ومع ذلك، ستظل بحاجة أحيانًا إلى تعطيل أو تعديل قواعد محددة يدويًا، خصوصًا عندما تكون هناك قواعد لا تتوافق فعليًا مع طبيعة تطبيقك أو طريقة عمله.

٤ · النشر

بنى توزيع الـWAF (Deployment Topologies)

مسار الفحص الذي شرحناه سابقًا يظل نفسه بغض النظر عن المكان الذي يتم فيه تشغيله فعليًا.

لكن موقع الـWAF داخل البنية التحتية يحدد أمرين مهمين: ما الذي يستطيع رؤيته من حركة المرور، وما الذي يمكنه فعله عندما يتخذ قرارًا بحجب الطلب.

الشكل 4 — لاحظ الخط المتقطع هنا: الـ WAF العامل خارج المسار يستقبل نسخة من الطلب بعد أن يكون الطلب الأصلي قد وصل الخادم فعليًا. بإمكانه أن يُنبِّهك، لكن لا سبيل أمامه لمنع طلب سبق ووصل بالفعل.

٥ · أين يفشل ال WAF

التطبيع (Normalization) وأساليب التحايل (Evasion)

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

وفيما يلي بعض الأساليب الشائعة، وجميعها تعتمد على تجاوز أو إرباك المرحلة الأولى من مسار الفحص التي شرحناها في القسم الثالث:

• الترميز المزدوج أو المختلط (Double/Mixed Encoding) — مثل %2527، حيث تم ترميز القيمة مرتين، أو خلط %2f مع / بشكل مباشر. في هذه الحالة، قد يؤدي فك الترميز مرة واحدة فقط إلى ترك جزء من القيمة مشفّرًا، وبالتالي لا تتعرف عليه القاعدة كما ينبغي.

• التعليقات داخل استعلامات SQL (Inline SQL Comments) — مثل /*!SEL*/ECT أو UNI/**/ON SEL/**/ECT. بعض محركات قواعد البيانات لا تزال قادرة على تفسير هذه الصياغات كاستعلام صالح، بينما قد تفشل قاعدة تعتمد على مطابقة الكلمات المفتاحية حرفيًا في اكتشافها، لأنها تبحث عن الكلمة كاملة كما هي.

• حيل الأحرف وحالة الأحرف وUnicode (Case & Unicode Tricks) — مثل استخدام كلمات مفتاحية بأحرف كبيرة وصغيرة بشكل مختلط، أو استخدام Homoglyphs من Unicode تشبه الأحرف ASCII، أو استخدام تسلسلات UTF-8 طويلة بشكل غير قياسي (Overlong UTF-8) يمكن أن تُفك لاحقًا إلى محرف ASCII، بينما لم يقم محرّك المطابقة البسيط بتوحيدها إلى تمثيلها القياسي أولًا.

• تلوث معاملات HTTP (HTTP Parameter Pollution — HPP) — وذلك بإرسال المعامل نفسه أكثر من مرة، مثل:
  id=1&id=1%20OR%201=1

  هنا قد يختلف تفسير الـWAF عن تفسير إطار العمل الذي يستخدمه التطبيق حول أي نسخة من المعامل هي التي يجب اعتمادها. ونتيجة لذلك، قد يفحص الـWAF النسخة غير الضارة، بينما يعالج التطبيق النسخة التي تحتوي على الحمولة الخبيثة.

• حيل Multipart وCharset في رفع الملفات — يمكن أن تتضمن الحمولة Content-Type مزيفًا، أو صيغة غير معتادة للـboundary، أو ترميز أحرف (Charset) لا يدعمه المحلل (Parser) بشكل كامل. عندها قد يتم تمرير الجزء إلى التطبيق من دون تحليله بدلًا من إخضاعه للفحص، وبالتالي لا يرى الـWAF محتواه الفعلي.

الفكرة الأساسية

المشكلة ليست دائمًا أن الـWAF لا يعرف توقيع الهجوم؛ أحيانًا يعرفه تمامًا، لكن الحمولة لم تصل إلى محرّك القواعد بالشكل الذي يتوقعه.

وهنا تظهر أهمية التطبيع: يجب أن يصل الـWAF إلى تمثيل موحّد للطلب قبل أن يبدأ بمطابقة القواعد، وإلا يمكن أن تصبح هناك فجوة بين ما يراه الـWAF وما يفسره التطبيق فعليًا.

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

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

٦ · الاستخدام التشغيلي

الترقيع الافتراضي (Virtual Patching)

عندما يتم الإعلان عن ثغرة أمنية (CVE) في مكتبة أو إطار عمل تستخدمه، فإن إصلاحها فعليًا — أي ترقية الاعتمادية (Dependency)، وإعادة بناء التطبيق، وإجراء الاختبارات، ثم نشر الإصدار الجديد — يستغرق عادةً من عدة أيام إلى أسابيع، خصوصًا في التطبيقات الموجّهة للعملاء، والتي تحتاج إلى إجراء اختبارات Regression للتأكد من أن التحديث لم يتسبب في كسر وظائف أخرى.

في المقابل، يمكن عادةً نشر قاعدة في الـWAF تستهدف النمط المحدد للاستغلال خلال ساعات.

وهذه الفجوة الزمنية هي ما يغطيه مفهوم الترقيع الافتراضي (Virtual Patching): وضع قاعدة حظر مؤقتة ومحددة النطاق عند حافة الشبكة (Edge)، تمنح فريق التطوير وقتًا لمعالجة الثغرة بشكل صحيح، من دون الحاجة إلى تعديل كود التطبيق مباشرةً.

لكن من المهم جدًا فهم أن الترقيع الافتراضي هو إجراء مؤقت وليس إصلاحًا حقيقيًا.

فالكود الذي يحتوي على الثغرة يظل عرضة للاستغلال، وقاعدة الـWAF لا تمنع بالضرورة جميع طرق استغلالها؛ فهي تحظر فقط أشكال الطلبات (Request Shapes) المحددة التي صُممت القاعدة لاكتشافها.

لذلك، إذا استخدم المهاجم أسلوبًا مختلفًا بما يكفي لاستغلال الثغرة نفسها، فقد يتمكن من تجاوز قاعدة الـWAF والوصول إلى التطبيق.

الخلاصة:
الـVirtual Patching يشتري لك الوقت، لكنه لا يلغي الحاجة إلى إصلاح الثغرة في الكود أو تحديث الاعتمادية المتأثرة.

الشكل 6 — تتمثل مهمة قاعدة الـWAF في تقليص فترة التعرض للخطر بين الإعلان عن الثغرة وتطبيق الإصلاح الفعلي، وليس استبدال الإصلاح الحقيقي.

٧ · النطاق والحدود

الدفاع متعدد الطبقات (Defense in Depth): ما الذي لا يستطيع الـWAF فعله؟#

كل ما سبق يصف أداة أمنية مهمتها فحص الطلبات (Requests). لكن الـWAF لا يمتلك نموذجًا لمنطق الأعمال الخاص بتطبيقك (Business Logic)، ولذلك لا يستطيع اكتشاف الطلبات التي تبدو مشروعة تمامًا، لكنها تستغل وظيفة مشروعة بطريقة غير صحيحة.

ومن أمثلة ذلك: ثغرة تسمح بتصعيد الصلاحيات (Privilege Escalation) من خلال إرسال حقل إضافي يبدو طبيعيًا، أو خلل في التحقق من صلاحيات الوصول إلى الكائنات (Object-Level Authorization)، أو Race Condition تحدث أثناء تنفيذ عملية الدفع.

هذه الطلبات قد تكون، من الناحية الهيكلية، مطابقة تمامًا للطلبات المشروعة؛ ولذلك لا يمتلك الـWAF نمطًا واضحًا يمكنه مطابقته لاكتشافها.

كذلك، لا يستطيع الـWAF إصلاح إعدادات أو كود لم يتم إصلاحه أصلًا، مثل:

• ملف تعريف جلسة (Session Cookie) لا يحتوي على خصائص HttpOnly أو Secure.

• Document Root يكشف ملفات أو مسارات تتجاوز المجلد العام (Public Directory) للتطبيق.

• مسار رفع ملفات (File Upload Path) يسمح بتنفيذ الملفات التي يتم تخزينها فيه.

• غياب ترويسة Content-Security-Policy (CSP).

هذه كلها ضوابط أمنية منفصلة، ووجود الـWAF أمامها لا يجعل إعداداتها صحيحة أو يعالج المشكلة الموجودة فيها.

الشكل 7 — الـWAF هو طبقة واحدة ضمن منظومة الحماية متعددة الطبقات، ويتم وضعه في مرحلة مبكرة بما يكفي لإيقاف قدر كبير من الطلبات الضارة أو غير المرغوبة، لكنه ليس بديلًا عن أي طبقة تأتي بعده.

قاعدة عملية:إذا كان الإصلاح الصحيح يجب أن يتم داخل كود التطبيق أو إعدادات الخادم، فقم بإصلاحه هناك.#

استخدم قاعدة في الـWAF حول المشكلة كإجراء مؤقت فقط (راجع القسم §6)، ولا تجعل الـWAF المكان الدائم لإصلاح مشكلة يجب معالجتها في طبقة أخرى من النظام.

٨ · العمليات

مراحل نشر الـWAF وحلقة التحسين المستمر (Feedback Loop)#

أكثر الأخطاء شيوعًا في بيئات الإنتاج هو تفعيل وضع الحظر (Blocking Mode) مباشرةً منذ اليوم الأول.

فقواعد الـWAF الافتراضية تكون عادةً مضبوطة للتعامل مع حركة مرور عامة (Generic Traffic)، وليس مع حركة المرور الخاصة بتطبيقك تحديدًا. لذلك قد تنتج عنها إنذارات كاذبة (False Positives) عند التعامل مع طلبات مشروعة يرسلها تطبيقك بالفعل.

على سبيل المثال:

• جسم JSON طويل يتسبب في تفعيل قاعدة خاصة بحجم الطلب.

• حقل نص منسق (Rich-Text) يبدو للـWAF وكأنه حمولة XSS.

• عميل داخلي للـAPI يستخدم ترويسة (Header) غير معتادة.

لذلك، من الأفضل نشر الـWAF على مراحل بدلًا من تفعيله مباشرةً في وضع الحظر.

1. المراقبة فقط (Detection Only)#

تقوم القواعد بتحليل الطلبات وتسجيل النتائج في السجلات، من دون حظر أي طلب.

الهدف هنا هو بناء صورة واقعية عن حركة المرور الفعلية لتطبيقك ومقارنتها بمجموعة القواعد المستخدمة.

2. الضبط (Tuning)#

ابدأ بمراجعة حالات الإنذارات الكاذبة (False Positives).

يمكنك استثناء Rule IDs محددة لمسارات أو معاملات محددة، بدلًا من تعطيل القاعدة بشكل عام. لا تعطل قاعدة على مستوى النظام بالكامل إذا كان بإمكانك إنشاء استثناء محدود النطاق.

بعد ذلك، اضبط Anomaly Threshold وأضف قواعد تعتمد على النموذج الإيجابي (Positive Model) لنقاط النهاية ذات القيمة أو الحساسية العالية.

3. التفعيل الانتقائي للحظر (Selective Enforcement)#

فعّل الحظر أولًا لمجموعات القواعد التي تتمتع بأعلى مستوى من الثقة، مثل التواقيع الواضحة لهجمات SQL Injection (SQLi) وRemote Code Execution (RCE).

أما الفئات التي تتمتع بدرجة ثقة أقل، فاستمر في تشغيلها بوضع التسجيل فقط (Log-Only).

4. التفعيل الكامل (Full Enforcement)#

يصبح الحظر فعالًا عبر مجموعات القواعد المختلفة، وتستقر قيم Thresholds، ويصل معدل False Positives إلى مستوى مقبول ومستقر.

5. الضبط المستمر (Continuous Tuning)#

ظهور نقاط نهاية (Endpoints) جديدة، وظهور تواقيع لهجمات جديدة، وتغير أنماط حركة المرور كلها أمور تتطلب استمرار هذه الحلقة.وهذه المرحلة لا تنتهي.

الشكل 8 — العودة إلى مرحلة الضبط ليست علامة على فشل النظام، بل هي جزء أساسي من طريقة تشغيله.

فالـWAF الذي يصل إلى مرحلة Full Enforcement ثم لا تتم مراجعته بعد ذلك، سيبدأ تدريجيًا في فقدان التوافق مع كلٍّ من تطبيقك الحالي وبيئة التهديدات المتغيرة.

ومن الأفضل أيضًا إرسال السجلات الناتجة عن هذه الحلقة إلى نظام مراقبة الأمان الذي تستخدمه بالفعل، مثل SIEM أو حتى Structured Log Pipeline، بدلًا من الاعتماد فقط على لوحة التحكم الخاصة بالـWAF.

فربط أحداث الحظر والتنبيهات الصادرة عن الـWAF مع سجلات التطبيق وأحداث المصادقة (Authentication Events) هو ما يساعد عادةً على اكتشاف الهجمات المنسقة (Coordinated Attacks)، وليس الاعتماد على طلب واحد تم حظره بمعزل عن بقية الأحداث.

ملاحظة ختامية

تبرز قيمة الـWAF الحقيقة من خلال وجوده في البنية الأمنية في مرحلة مبكرة من مسار الطلب، وتنفيذه مهمة محددة بشكل جيد: قراءة محتوى HTTP الذي لا يستطيع جدار الحماية الشبكي رؤيته من الناحية الهيكلية، ثم تقييمه ومقارنته بأنماط معروفة بأنها ضارة أو معروفة بأنها مشروعة.

لكنه لا يحل محل الإدارة الآمنة للجلسات (Secure Session Handling)، أو التحقق الصحيح من الملفات المرفوعة (Validated File Uploads)، أو الاستعلامات المعلّمة (Parameterized Queries)، أو التحقق الصحيح من الصلاحيات (Authorization Checks).

هذه الضوابط يجب أن تكون صحيحة في مصدر المشكلة نفسه.

تعامل مع الـWAF باعتباره مرشحًا سريعًا وقابلًا للضبط، وظيفته تقليل الضوضاء وشراء الوقت، واربط سجلاته بأنظمة الكشف والمراقبة التي تستخدمها، ثم أعد مراجعة إعداداته وفق جدول دوري حقيقي بدلًا من اعتبار الوصول إلى Enforcement Mode نهاية عملية الضبط.

المخططات توضيحية (Schematic) — صُممت لشرح الآلية في كل مرحلة، وليس لتمثيل التنفيذ الداخلي الدقيق لأي منتج أو مزود محدد.