WAF من خلال عيون المتسللين

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

---

إخلاء المسئولية: هذه ترجمة للمقال من الروسية إلى الإنجليزية ، تم إصدار المقال في نهاية عام 2017 ، على التوالي ، قد تصبح بعض المعلومات قديمة.

محتويات

1. مقدمة
2. و WAF الحديثة
3. تحديد WAF
4. WAF الالتفافية cheatsheet
5. WAF الالتفافية في الممارسة العملية
6. استنتاج

إذا كنت تعرف سبب استخدام WAFs وكيفية عملها ، يمكنك القفز مباشرةً إلى القسم الالتفافي.

مقدمة

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



لذا ، ما الذي يجب أن تكون WAF قادرة على تبرير تنفيذه في مشروع؟ وتتمثل مهمتها الرئيسية في اكتشاف ومنع أي طلب يحتوي ، وفقًا لتحليل WAF ، على أي شذوذ أو ناقل للهجوم. يجب ألا يعيق التحليل التفاعل بين المستخدمين الشرعيين وتطبيق الويب بينما في الوقت نفسه ، يجب أن يكتشف بدقة وفي الوقت المناسب أي محاولات هجوم. من أجل تنفيذ هذه الوظيفة ، يستخدم مطورو WAF التعبيرات العادية والرموز الرمزية وتحليل السلوك وتحليل السمعة والتعلم الآلي بالطبع. في كثير من الأحيان ، يتم استخدام كل هذه التقنيات معًا. قد يقوم WAF أيضًا بتنفيذ وظائف أخرى: حماية DDoS ، حظر عناوين IP للمهاجمين ، مراقبة عناوين IP المشبوهة ، إضافة رؤوس الأمان (X-XSS-Protection ، X-Frame-Options ، وما إلى ذلك) ، إضافة علامات http فقط إلى ملف تعريف الارتباط ، وتنفيذ آلية HSTS ورموز CSRF. أيضا ، بعض WAFs لديها وحدات العميل جافا سكريبت للمواقع.

بالطبع ، تخلق WAFs بعض العقبات أمام المتسللين والمثقفين. يجعل WAF اكتشاف الثغرات واستغلالها أكثر كثافة للموارد (باستثناء ما إذا كان المهاجم يعرف طرق تجاوز فعالة لليوم 0 لـ WAF محدد). الماسحات الضوئية التلقائية غير مجدية عملياً عند تحليل تطبيقات الويب المحمية بـ WAF. WAF هو حماية موثوقة ضد "scriptkiddies". على الرغم من ذلك ، ربما لا يرغب أحد المتسللين أو الباحثين ذوي الخبرة دون وجود دوافع كافية في إضاعة الوقت في محاولة لإيجاد طرق لتجاوزه. تجدر الإشارة إلى أن تطبيق الويب الأكثر تعقيدًا هو أكبر مساحة للهجوم ، وأسهل العثور على طريقة الالتفافية.

في عمليات التدقيق التي أجريناها مؤخرًا ، وجدنا في كثير من الأحيان WAFs مختلفة. سنتحدث عن بعضهم لاحقًا. لقد اختبرنا بالفعل WAFs مملوكتين في سيناريوهين رئيسيين:

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

لكن أولاً ، دعونا نلقي نظرة فاحصة على الآليات الأساسية وراء WAF ونرى ما هي المشاكل التي يواجهونها.

و WAF الحديثة

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

القواعد القائمة على التعبيرات العادية

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

Scorebuilding

يجب أن يكون أولئك الذين يعرفون كيفية عمل جدران الحماية والشبكات المضادة للفيروسات على دراية بهذه الآلية. لا يكتشف الهجمات ولكنه يكمل الآليات الأخرى مما يجعلها أكثر دقة ومرونة. الشيء هو أن البنية "المشبوهة" في الطلب ليست شرطا كافيا للكشف عن الهجوم وقد تؤدي إلى العديد من الإيجابيات الخاطئة. يتم حل هذه المشكلة عن طريق تطبيق نظام الدرجات. وتستكمل كل قاعدة تستند إلى التعبيرات العادية بالمعلومات المتعلقة بأهميتها ؛ بعد تحديد جميع القواعد التي يتم تشغيلها ، يتم تلخيص مدى أهميتها. إذا وصلت درجة الأهمية الكلية إلى القيمة الدنيا ، فسيتم اكتشاف الهجوم ويتم حظر الطلب. على الرغم من بساطتها ، أثبتت هذه الآلية أنها فعالة وتستخدم على نطاق واسع لمثل هذه المهام.

Tokenizers

تم تقديم طريقة الكشف هذه في Black Hat 2012 باعتبارها libinjection في مكتبة C / C + ، والتي تسمح بتحديد حقن SQL بسرعة وبدقة. في هذه اللحظة ، هناك العديد من منافذ libinjection للغات البرمجة المختلفة ، مثل PHP ، Lua ، Python ، إلخ. تبحث هذه الآلية عن التوقيعات المقدمة كمجموعة من الرموز. هناك عدد معين من التوقيعات مدرجة في القائمة السوداء ، وتعتبر غير مرغوب فيها وخبيثة. بمعنى آخر ، قبل تحليل بعض الطلبات ، يتم ترجمته إلى مجموعة من الرموز. الرموز مقسمة إلى أنواع معينة ، مثل متغير ، سلسلة ، عامل تشغيل عادي ، غير معروف ، رقم ، تعليق ، عامل تشبه الوحدة ، دالة ، فاصلة ، إلخ. أحد العيوب الرئيسية لهذا الأسلوب هو أنه من الممكن إنشاء بنية تؤدي إلى تكوين الرموز بشكل غير صحيح ، وبالتالي سيختلف توقيع الطلب عن المتوقع. يشار عادةً إلى هذه الهياكل على أنها كسارات رمزية ، وسنناقشها لاحقًا

تحليل السلوك

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

تحليل السمعة

هذه آلية أخرى موروثة مباشرة من جدران الحماية ومكافحة الفيروسات. اليوم ، يشتمل أي WAF تقريبًا على قوائم بعناوين VPN ومجهولي الهوية وعقد Tor وشبكات الروبوت لمنع طلبات من هؤلاء. يمكن لـ WAFs المتقدمة تحديث قواعدها تلقائيًا واستكمالها بإدخالات إضافية بناءً على حركة المرور التي تم تحليلها.

تعلم الآلة

هذا هو واحد من أكثر الجوانب المشكوك فيها في WAF. دعونا نلاحظ أن مصطلح "التعلم الآلي" واسع للغاية ويشمل العديد من التقنيات والطرق. الى جانب ذلك ، انها مجرد واحدة من فئات منظمة العفو الدولية. يعد "تنفيذ" التعلم الآلي أو "استخدام الذكاء الاصطناعي" عبارات تسويقية شائعة للغاية. ليس من الواضح دائمًا الخوارزميات التي يتم استخدامها بالضبط ، وفي بعض الأحيان يبدو الأمر مجرد رطانة. هؤلاء البائعون الذين يستخدمون حقًا التعلم الآلي ويقومون به بفعالية ليسوا على استعداد لمشاركة خبراتهم. وهذا يجعل من الصعب على شخص غريب محاولة معرفة الموقف. ومع ذلك ، دعونا نحاول توضيح بعض النقاط بناءً على المعلومات المتاحة.

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

تحديد WAF

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

فيما يلي قائمة ببصمات WAF المحتملة:

• ملفات تعريف الارتباط الإضافية
• رؤوس إضافية لأي استجابة أو طلب
• محتويات الاستجابة (في حالة الطلب المحظور)
• رمز الاستجابة (في حالة الطلب المحظور)
• عنوان IP (السحابة WAF)
• وحدة جانب عميل JS (جانب العميل WAF)

دعونا توضيح ذلك مع بعض الأمثلة

PT AF
رمز الاستجابة للطلب المحظور: 403
يمكن إدراج الوحدة النمطية للعميل waf.js في صفحة الاستجابة
نص الاستجابة:

<h1>Forbidden</h1> <pre>Request ID: 2017-07-31-13-59-56-72BCA33A11EC3784</pre> 

رأس إضافي يضيف بواسطة waf.js:

 X-RequestId: cbb8ff9a-4e91-48b4-8ce6-1beddc197a30 

نيميسيدا واف
رمز الاستجابة للطلب المحظور: 403
نص الاستجابة:

 <p style="font-size: 16px; align: center;"> Suspicious activity detected. Access to the site is blocked. If you think that is's an erroneous blocking, please email us at <a href="mailto:nwaf@pentestit.ru">nwaf@pentestit.ru</a> and specify your IP-address. </p> 

Wallarm
رمز الاستجابة للطلب المحظور: 403
رأس إضافي: nginx-wallarm

سيتريكس NetScaler AppFirewall
ملف تعريف ارتباط إضافي:

 ns_af=31+LrS3EeEOBbxBV7AWDFIEhrn8A000; ns_af_.target.br_%2F_wat=QVNQU0VTU0lP TklEQVFRU0RDU0Nf?6IgJizHRbTRNuNoOpbBOiKRET2gA 

Mod_Security ver. 2.9
رمز الاستجابة للطلب المحظور: 403
هيئة الاستجابة:

 <head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> <p>You don't have permission to access /form.php on this server.<br /></p> 

Mod_Security ver. <2.9
رمز الاستجابة للطلب المحظور: 406 أو 501
في نص الاستجابة ، يمكنك العثور على mod_security أو Mod_Security أو NOYB

جدار الحماية الورنيش
يضيف الرؤوس التالية إلى الاستجابة:

 X-Varnish: 127936309 131303037. X-Varnish: 435491096 Via: 1.1 varnish-v4 

يقرر مطورو WAF أنفسهم رمز الاستجابة المطلوب إرجاعه في حالة وجود طلب محظور ؛ هناك بعض الرموز المحددة كذلك. على سبيل المثال ، تقوم Web_Knight WAF بإرجاع الرمز 999 ، بينما يعرض dotDefender الكود 200 مع نص استجابة فارغ أو مع رسالة خطأ. إلى جانب ذلك ، يمكن للمطورين إنشاء صفحة استجابة مخصصة مع بعض المحتويات الأخرى.

WAF ، مثل أي تطبيق آخر ، يتطور ويتغير. لهذا السبب من المهم التحقق باستمرار من أهمية بصمات الأصابع لديك.

WAF الالتفافية ورقة الغش

الفكرة العامة وراء إيجاد طرق لتجاوز WAF هي تحويل الطلب الذي نحتاجه بحيث لا يزال صالحًا لتطبيق الويب ولكن ليس بالنسبة إلى WAF أو يبدو أنه غير ضار. من المهم أن يتمكن نوع واحد من WAF من تقديم العديد من أنواع الخوادم المختلفة ، بما في ذلك الخوادم "الغريبة" ، مثل Unicorn و Tornado و Weblogic و Lighttpd ، إلخ. قد ينظر كل خادم إلى حالات استثنائية لتحليل طلبات HTTP بطريقة مختلفة ، والتي يجب أيضًا أن يتم النظر فيها بواسطة WAF. وبالتالي ، يمكن للمهاجم استخدام تفاصيل خوادم تحليل طلب HTTP لإيجاد طريقة لتجاوز WAF.



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

مضيفا الرموز الخاصة

يمكن أن تنتهك الرموز الخاصة المختلفة منطق تحليل WAF وفي نفس الوقت يتم تفسيرها من قبل الخادم. قد تختلف أشكال هذه الرموز: فقد تتحول إلى كود urlencode (على الرغم من أن معظم WAFs يمكنها التعامل مع ذلك) أو ترميزات أخرى. من الممكن أيضًا إدراج رموز خاصة في طلب ما دون أي تشفير ، بتنسيق أولي ، مما قد يفاجئ WAF. على سبيل المثال ، يمكن اعتبار \ r \ n \ r \ n في هذا العرض التقديمي نهاية لنص طلب HTTP ، ويمكن للبايت الفارغة أن تنتهك منطق تحليل التعبيرات العادية ومحللات البيانات تمامًا. أيضًا ، قد تكون الرموز الخاصة الأخرى من الرموز العشرين الأولى لجدول ASCII مفيدة.
الأمثلة على ذلك:

• 0x00 - بايت فارغة ؛
• 0x0D - إرجاع النقل ؛
• 0x0A - تغذية الخط ؛
• 0x0B - علامة تبويب عمودي ؛
• 0x09 - علامة تبويب أفقية ؛
• 0x0C - صفحة جديدة

أثناء البحث عن تجاوز ، من المفيد إدراج رموز خاصة في أماكن مختلفة في نص الطلب وليس فقط في قيم المعلمات. على سبيل المثال ، إذا كان الطلب بتنسيق JSON ، فيمكننا إدراج NULL-بايت على حد سواء في معلمة وبين المعلمات ، سواء في بداية ونهاية JSON. الأمر نفسه ينطبق على الأشكال الأخرى من نص طلب POST. بشكل عام ، نوصي بالقيام بالبحث والاستمتاع ، والبحث عن الأماكن التي يمكن رصدها وتحليلها بواسطة WAF ، ومحاولة استخدام رموز خاصة مختلفة هناك.

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

 {"id":1337,"string0x00":"test' or sleep(9)#"} {"id":1337,"string":"test'/*0x00*/ or sleep(9)#"} {"id":1337,"string"0x0A0x0D:"test' or sleep(9)#"} 

 <a href="ja0x09vas0x0A0x0Dcript:alert(1)">clickme</a> <a 0x00 href="javascript:alert(1)">clickme</a> <svg/0x00/onload="alert(1)"> 

 id=1337/*0x0C*/1 UNION SELECT version(), user() -- 

من أجل الوضوح ، استبدلنا الرموز الخاصة بعرضها السداسي.

استبدال رموز الفضاء

في معظم بناء الجملة ، يجب فصل الكلمات الأساسية والعوامل ، لكن لم يتم تحديد رموز الفضاء المفضلة. وبالتالي ، بدلاً من 0x20 (مساحة) الشائعة ، يمكنك استخدام 0x0B (علامة تبويب عمودي) أو 0x09 (علامة تبويب أفقية). استبدال المساحات بهياكل تقسيم دون معانيها يندرج في نفس الفئة. في SQL ، يكون / ** / (تعليقات SQL متعددة الأسطر) ، # \ r \ n (تعليق SQL من سطر واحد ، ينتهي بتغذية سطر) ، - \ r \ n (تعليق SQL بديل من سطر واحد ، ينتهي مع تغذية الخط). فيما يلي بعض الأمثلة:

 http://test.com/test?id=1%09union/**/select/**/1,2,3 http://test.com/test?id=1%09union%23%0A%0Dselect%2D%2D%0A%0D1,2,3 

أيضًا ، يمكننا تحويل تعبير للتخلص من المسافات باستخدام بناء جملة اللغة. على سبيل المثال ، في SQL ، يمكننا استخدام الأقواس:

 UNION(SELECT(1),2,3,4,5,(6)FROM(Users)WHERE(login='admin')) 

وفي JS ، استخدم / :

 <svg/onload=confirm(1)> 

تغيير الترميز

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

الشكل العشري لرمز HTML هو & # 106 أو & # 0000106. قد يعرف WAF عن الإصدار القصير ولا يعرف عن الإصدار مع الأصفار الإضافية (يجب ألا يزيد مجموع الرموز عن 7 رموز). بالطريقة نفسها ، يكون الشكل السداسي لرمز HTML هو & # x6A أو & # x000006A .

هناك أيضًا خدعة بها حروف متجاوزة بخط مائل عكسي \ ، على سبيل المثال:

 <svg/on\load=a\lert(1)> 

رغم ذلك ، يعتمد ذلك على كيفية معالجة تطبيق الويب لبيانات الإدخال هذه. لذلك ، سيتم معالجة التسلسل \ l كرمز وتحويله إلى رمز واحد ؛ يمكن لـ WAF معالجة كل رمز على حدة ويمكنه كسر التعبيرات العادية أو منطق WAF آخر. وبالتالي ، سوف يغيب WAF الكلمات الرئيسية. باستخدام هذه التقنية ، لا يمكننا الهروب من الشخصيات \ n ، \ r ، \ t ، حيث سيتم تحويلها إلى أحرف مختلفة: سطر جديد ، حرف إرجاع ، وعلامة تبويب.

يمكن استخدام ترميز HTML داخل سمات العلامات ، على سبيل المثال:

 <a href="javascript&colon;alert(1)">clickme</a> <input/onmouseover="javascript&colon;confirm&lpar;1rpar;"> 

يمكن استبدال هذه الأحرف بسهولة بتمثيلات HTML أخرى للأحرف المستهدفة. يمكنك البحث عن تحويلات مختلفة من الشخصيات هنا .

إلى جانب ترميز HTML ، يمكننا إدراج أحرف مع \ u :

 <a href="javascript:\u0061lert(1)">Clickme</a> <svg onload=confir\u006d(1)> 

لنلقِ نظرة أيضًا على المتجه المتعلق بإدخال حرف خاص. دعنا نكسر الحمولة الصافية باستخدام ترميز HTML:

 <a href="ja&Tab;vas&#x0000A;cript:alert(1)">clickme</a> 

في هذه الحالة ، يمكننا أيضًا وضع أحرف فاصلة أخرى.

وبالتالي ، نوصي بدمج ترميزات مختلفة مع طرق أخرى ، على سبيل المثال ، لتشفير الأحرف الخاصة.

البحث عن الهياكل النحوية المكافئة غير التقليدية

تهدف هذه الطريقة إلى إيجاد طريقة للاستغلال لا يعتبرها مطورو WAF ، أو متجهًا غير موجود في نموذج التدريب على التعلم الآلي. أمثلة بسيطة ستكون وظائف JavaScript: هذا ، صورة ذاتية ، أصل ، إطارات ؛ سمات العلامات: ربط البيانات ، ontoggle ، onfilterchange ، onbeforescriptexecute ، onpointerover ، srcdoc؛ عوامل تشغيل SQL: lpad ، الحقل ، bit_count .

فيما يلي بعض الأمثلة:

 <script>window['alert'](0)</script> <script>parent['alert'](1)</script> <script>self['alert'](2)</script> 

 SELECT if(LPAD(' ',4,version())='5.7',sleep(5),null); 

يمكنك أيضًا استخدام التمثيل غير الرمزي لتعبيرات JavaScript:

• JSFuck
• Jjencode .
• Xchars.js .

مشكلة واضحة في ذلك هي الحمولات الطويلة.

WAF الالتفافية مع هذه التقنية يعتمد على الهجوم ومجموعة مكدسة من التقنيات. يعد استغلال ImageTragick الشهير مثالاً جيدًا على ذلك. أدرجت معظم WAFs التي تحمي من هذا الهجوم كلمات رئيسية مثل url ، والسعة ، والتسمية ، حيث تم ذكر تلك الكلمات في غالبية الأوراق ونقاط الاتصال التي تصف مشكلة عدم الحصانة هذه. على الرغم من أنه سرعان ما تم الكشف عن إمكانية استخدام كلمات رئيسية أخرى أيضًا ، على سبيل المثال ، سريعة الزوال و pango . نتيجة لذلك ، يمكن تجاوز WAFs باستخدام هذه الكلمات الرئيسية.

تلوث معلمة HTTP (HPP) وتجزئة معلمة HTTP (HPF)

يعتمد هجوم HPP على كيفية قيام الخادم بترجمة المعلمات بنفس الأسماء. فيما يلي بعض تجاوزات المحتملة:

• يستخدم الخادم المعلمة المستلمة الأخيرة ، ويفحص WAF فقط المعلمة الأولى ؛
• يوحد الخادم القيمة من معلمات مشابهة ، ويقوم WAF بفحصها بشكل منفصل.

يمكنك مقارنة كيفية معالجة الخوادم المختلفة للمعلمات نفسها في الجدول أدناه:



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

 http://test.com/url?a=1+select&b=1+from&c=base 

HPF و HPP متشابهان للغاية ، لكن الأول يستهدف تطبيق ويب ، والأخير هو البيئة التي يعمل فيها. الجمع بين هذه التقنيات يزيد من فرصة تجاوز WAF.

تطبيع يونيكود

Unicode Normalization هي إحدى ميزات Unicode المخصصة لمقارنة رموز Unicode التي تبدو متشابهة. على سبيل المثال ، تحتوي الرموز "ª" و "ᵃ" على رموز مختلفة ولكنهما متشابهان للغاية على خلاف ذلك ، لذلك بعد التطبيع سيبدو كلاهما بسيطًا "a" ويعتبران متماثلين . يتيح التطبيع تحويل بعض رموز Unicode المعقدة إلى بدائل أبسط. هناك جدول تطبيع Unicode مع جميع رموز Unicode وتطبيعاتها المحتملة. باستخدامه ، يمكنك إنشاء حمولات مختلفة ودمجها مع طرق أخرى. على الرغم من أنه لا يعمل مع جميع تطبيقات الويب ويعتمد بشكل كبير على البيئة.

على سبيل المثال ، في الجدول أعلاه ، يمكننا أن نرى أن الرموز ＜ و ﹤ تتحول إلى < بسيطة. إذا كان أحد التطبيقات يستخدم تشفير HTML بعد التطبيع ، فمن المرجح أن يكون رمز التطبيع < سيتم ترميزه في < . ولكن ، في حالات أخرى ، ربما تجاهل المطورون هذه الميزة وليس رموز Unicode المشفرة. وبالتالي ، نحصل على رموز غير مشفرة بتنسيق HTML < و > ، والتي يمكن تحويلها إلى هجوم XSS. قد تواجه WAF مشكلة في فهم رموز Unicode - قد لا تحتوي ببساطة على قواعد لهذه الحيل ، وقد يكون التعليم الآلي عديم الفائدة أيضًا. أثناء العثور على تجاوز في تطبيقات الويب مع تطبيع Unicode ، يمكننا استبدال ليس فقط <> بل الرموز الأخرى من الحمولة النافعة أيضًا.

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

 ＜img src﹦x onerror＝alert︵1)> 

في الآونة الأخيرة ، تم العثور على هذه المشكلة في برنامج Rockstar BugBounty في HackerOne. لم يكن هناك WAF ، فقط تصفية إدخال المستخدم صارمة:

hackerone.com/reports/231444
hackerone.com/reports/231389

قواطع رمزية

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

 SELECT-@1,version() 

حيث - @ هو الكسارة الرمزية.

هناك ورقة chear التي تم الحصول عليها بواسطة mysql fuzzing والتحقق من النتائج في libinjection.

المزيد عن العثور على مشاكل في libinjection:

طنان آخر
زغب لتجاوز
كيفية تجاوز libinjection

باستخدام ميزات RFC

في مواصفات بروتوكول HTTP / 1.1 وأنواع الطلبات المختلفة (مثل البيانات متعددة الأجزاء / النماذج) ، يمكننا أن نجد بعض الأشياء الغريبة المتعلقة بحالات الحدود وحيل معالجة الرؤوس والمعلمات. لا ينظر مطورو WAF غالبًا في مثل هذه المشكلات ، وبالتالي قد يقوم WAF بتحليل الطلب بشكل غير صحيح ويفتقد جزء البيانات ، حيث يتم إخفاء متجه الهجوم. ترتبط معظم المشكلات في WAFs بمعالجة البيانات متعددة الأجزاء / والقيم المحددة للمعلمة الحدودية ، والتي تحدد حدود المعلمات في مثل هذه الطلبات. بالإضافة إلى ذلك ، قد يخطئ مطورو الخادم كذلك ولا يدعمون المواصفات تمامًا ، لذلك قد تكون هناك ميزات غير موثقة في محلل HTTP للخادم.

في طلب HTTP مع بيانات متعددة الأجزاء / النماذج ، تكون حدود المعلمة مسؤولة عن فصل المعلمات المختلفة في نص الطلب. وفقًا لـ RFC ، يجب وضع حدود محددة مسبقًا مع بادئة تحتوي على "-" قبل كل معلمة POST جديدة ، حتى يتمكن الخادم من تمييز المعلمات المختلفة لطلب ما.

 POST /vuln.php HTTP/1.1 Host: test.com Connection: close Content-Type: multipart/form-data; boundary=1049989664 Content-Length: 192 --1049989664 Content-Disposition: form-data; name="id" 287356 --1049989664-- 

قد يعتمد الهجوم أيضًا على حقيقة أن الخادم و WAF يتعاملان بشكل مختلف مع موقف يتم فيه ترك الحدود فارغة. وفقًا لـ RFC ، في هذه الحالة ، "-" هي الحدود بين المعلمات. ومع ذلك ، قد تستخدم WAF محللًا لا يراعي ذلك ، ونتيجة لذلك ، فإن WAF سوف يجتاز الطلب لأن البيانات من معلمات طلب POST لن تظهر في المحلل. يمكن لخادم الويب تحليل مثل هذا الطلب دون مشاكل وتسليم البيانات لمزيد من المعالجة.
فيما يلي بعض الأمثلة الأكثر إثارة للاهتمام.

 POST /vuln.php HTTP/1.1 Host: test.com Connection: close Content-Type: multipart/form-data; boundary= Content-Length: 192 -- Content-Disposition: form-data; name="id" 123' or sleep(20)# ---- 

سنقدم بعض الأمثلة الأكثر إثارة للاهتمام من الشرائح التي كتبها Bo0oM في ZeroNights 2016 ونوضح ذلك:

 POST /vuln.php HTTP/1.1 Host: test.com Content-Type: multipart/form-data; boundary=FIRST; Content-Type: multipart/form-data; boundary=SECOND; Content-Type: multipart/form-data; boundary=THIRD; --THIRD Content-Disposition: form-data; name=param UNION SELECT version() --THIRD-- 

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

 POST /vuln.php HTTP/1.1 Host: test.com Content-Type: multipart/form-data; xxxboundaryxxx=FIRST; boundary=SECOND; --FIRST Content-Disposition: form-data; name=param UNION SELECT version() --FIRST-- 

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

 POST /somepage.php HTTP/1.1 Host: test.com Content-Type: multipart/form-data; boundary=Test0x00othertext; --Test Content-Disposition: form-data; name=param Attack --Test-- 

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

تجاوز التعلم الآلي

المنطق بسيط: علينا أن نؤلف هجومًا يفي بمعايير النموذج الإحصائي المدرب. ولكن هذا يعتمد إلى حد كبير على كيفية تدريب WAF ونموذج التدريب الذي تم استخدامه. أحيانًا يكون من الممكن العثور على ثغرة ، وأحيانًا لا يكون ذلك ممكنًا. عادة ، في مرحلة التنفيذ ، تحتاج WAF مع التعلم الآلي إلى تدريب إضافي بناءً على طلب تطبيق الويب الخاص بالعميل. يمثل ذلك مشكلة بالنسبة للمخترعين: لا يمكن اختبار المعلمات التي تبدو متشابهة ولا تتغير كثيرًا من طلب إلى آخر ، حيث يُعتبر أي انحدار من نموذج المعلمة المعتاد حالة شاذة. دعنا نقول الطريقة التي لديها طلب ل api.test.com/getuser؟id=123 . معرف المعلمة دائمًا ما يكون رقميًا ، وكان رقميًا في نموذج التدريب. إذا وجدت وحدة التعلم الآلي شيئًا إلى جانب الأرقام في هذه المعلمة ، فستقرر على الأرجح أنها حالة شاذة. مثال آخر: افترض أنه تم تدريب WAF لتصنيف طلب POST إلى api.test.com/setMarkDown مع معلمات POST التي تحتوي على نص تخفيض السعر. من الواضح ، قد تكون هناك علامات اقتباس ورموز خاصة وأي شيء أساسي في تخفيض السعر. في هذه الحالة ، من الأسهل تجاوز وحدة التعلم الآلي لأن WAF تتسامح مع علامات الاقتباس والرموز الخاصة.

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

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

عندما WAF لا طائل منه؟

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

المرافق الحالية

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

lightbulb-framework - إطار كامل لاختبار تطبيقات الويب المحمية باستخدام WAF. هو مكتوب على بيثون واستدار بالإضافة إلى ذلك كمكون إضافي لبرنامج Burp Suite. معالمه الرئيسية هي هذه الخوارزميات اثنين:

• GOFA - خوارزمية نشطة للتعلم الآلي تتيح تحليل الترشيح وتعقيم المعلمات في تطبيق ويب.
• SFADiff - خوارزمية اختبار الصندوق الأسود التفضيلي ، استنادًا إلى التدريب باستخدام automat رمزي محدود (SFA). يسمح بالعثور على اختلافات في سلوك تطبيقات الويب مما يساعد على تحديد WAF والعثور على تجاوز.

تجاوز WAF - مكون إضافي لـ Burp Suite ، والذي يسمح بإعداد تغيير تلقائي للعناصر في نص الطلب وفقًا لقواعد مختلفة وتغييرات الترميز. كما يمكن أتمتة هجوم HPP.

WAFW00F - أداة لتحديد WAF ، مكتوبة على بيثون. لديها قاعدة WAF لائقة وما زالت قيد التحديث. على الرغم من أن النتائج قد تكون غير دقيقة لأن العديد من WAFs يتم تحديثها بشكل متكرر أكثر من المشروع نفسه.

تجاوز waf في الممارسة العملية

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

 {"request":{"Count":10,"Offset":0,"ItemName":"Phone"}} 

وضعنا قيم الهاتف والهاتف في المعلمة ItemName ووجدنا أن الخادم يعرض استجابات مختلفة لهذين الطلبين. في الحالة الأولى ، كان الرد فارغًا ؛ في الحالة الثانية ، احتوى على بيانات عن البضائع الأخرى مع كلمة الهاتف باسمهم ، كما لو كانت المعلمة ItemName تحتوي على الهاتف كقيمة له. هذا النوع من السلوك معروف بين المتسللين والمثقفين ويشير إلى وجود مشكلة في التطبيق مع ترشيح إدخال المستخدم ، مما يؤدي إلى حقن SQL من بين آخرين.

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

 SELECT item FROM items WHERE item_name='Phone'' 

من الواضح أنه لن يتم تنفيذه بسبب بناء جملة غير صحيح ولن يعرض أي نتيجة. الطلب الثاني ، مع معلمة الهاتف "+" ، سيبدو كما يلي:

 SELECT item FROM items WHERE item_name='Phone'+'' 

بناء الجملة الخاص به صحيح ، لذلك سيختار البضائع بالاسم الهاتف . تتمتع طريقة الكشف عن الثغرات الأمنية هذه بميزة كبيرة أثناء اختبار تطبيق ويب محمي بواسطة WAF. لا يعتبر رمز الاقتباس الفردي شذوذًا كافيًا في أحد المعلمات من قِبل معظم WAFs الحديثة ، لذلك يقومون بتمرير طلب به.

لقد وصفنا اكتشاف نقاط الضعف ، ولكن ماذا عن تجاوز WAF واستغلال الثغرة الأمنية؟ بعد المرور ببعض الطرق الالتفافية ، وجدنا مشكلة في WAF. اتضح أن WAF هذا عرضة للأحرف الخاصة المضافة إلى معلمات JSON. في الواقع ، إذا أضفنا رموز JSON 0x0A أو 0x0D (\ r \ n أو carrige reutrn and line new) بتنسيق خام ، دون أي تشفير ، في أي حقل نص ، فإن WAF سوف يجتازه ، وسيقوم تطبيق الويب بالنظر فيه إلى أن تكون صحيحة ومعالجتها. على الأرجح ، كانت المشكلة في محلل JSON ، والذي لم يكن مخصصًا للرموز الخاصة ومحلل JSON الصحيح حتى مكان ظهور هذه الرموز فيه. وبالتالي ، لن يحصل محلل WAF على الطلب الكامل ، لذلك يمكننا إدراج أي ناقل للهجوم بعد أحرف خاصة. بالإضافة إلى فاصل الأسطر ، ستعمل الأحرف الأخرى (مثل NULL-byte) أيضًا. ونتيجة لذلك ، يمكننا كتابة الطلب التالي ، والذي سيؤدي إلى إيقاف تشغيل WAF لأنه حاول التحقق من هذا الطلب (تم استبدال فاصل الأسطر وإرجاع النقل بتمثيل نصي):

 {"request":{"kill-waf":"die0x0A0x0D", "Count":10,"Offset":0,"ItemName":["'+(SELECT 'Phone'+CHAR(ASCII(substring(@@version,1,1))-24))+'"]}} 

0x0A و 0x0D هي بايت الخام.

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

تم العثور على نفس المشكلات أيضًا في Nemesida WAF . الفرق الوحيد هو أن الطلب لم يكن بترميز JSON ، لكنه كان طلب POST معتادًا مع المعلمات ، وتم تحديد المعلمة لاستعلام SQL كرقم. إذا تم وضع بعض الرموز في طلب بتشفير عنوان url ، على سبيل المثال ، ٪ 03٪ 04 ، يقوم WAF بحظر طلب ، ولكن إذا تم وضع الرموز في شكل أولي بدون تشفير عنوان url ، فسيتجاهل WAF هذا الطلب. تجدر الإشارة إلى أنه تم وضع SQL- تعبير عادي لطلب وكذلك في WAF السابقة. كان تعبير SQL بسيطًا "UNION SELECT" دون أي تشويش إضافي ، مما يعني أن WAF ببساطة لا يمكن تحليل الطلب بشكل صحيح ونقل التحليل إلى أبعد من ذلك. ولكن هناك مشكلة واحدة - كيفية جعل بناء جملة استعلام SQL صحيحًا؟ لأن استخدام أحرف خاصة مثل ٪ 03٪ 04 في استعلام SQL غير صحيح. الإجابة بسيطة - نحتاج فقط إلى استخدام التعليقات / ** /. لذلك ، بدا طلب النتيجة كما يلي:

 /*0x03 0x04*/1 UNION SELECT version(), user() -- 

0x03 و 0x04 هي بايتات خام.

أيضا ، تم العثور على مشكلة أخرى في Nemesida WAF. كان يتعلق بمعالجة طلبات POST غير الصحيحة باستخدام بيانات متعددة الأجزاء / النماذج. كما وصفنا أدناه ، في طلب HTTP مع بيانات متعددة الأجزاء / النموذج ، تكون حدود المعلمة مسؤولة عن الفصل بين المعلمات المختلفة في نص الطلب. وفقًا لـ RFC ، يجب وضع حدود محددة مسبقًا مع بادئة تحتوي على "-" قبل كل معلمة POST جديدة ، حتى يتمكن الخادم من تمييز المعلمات المختلفة لطلب ما.
لذلك ، كانت المشكلة أن الخادم و WAF تعاملوا مع الموقف بشكل مختلف عندما كانت المعلمة الحدود فارغة. استنادًا إلى RFC ، في هذه الحالة ، ستكون الحدود بين المعلمات سلسلة من الأحرف "-" . ومع ذلك ، استخدم WAF المحلل اللغوي الذي لا يأخذ في الاعتبار هذه الميزة ، وهذا هو السبب في WAF مرة أخرى تمرير الطلب ، لأن البيانات من معلمات طلب POST ببساطة لم تدخل وحدة التحليل ، وقام الخادم بتحليل هذا الموقف دون أي مشاكل ونقل البيانات إلى مزيد من المعالجة. هذا طلب عينة لهذا الهجوم:

 POST /wp-content/plugins/answer-my-question/modal.php HTTP/1.1 Host: example.com Content-Type: multipart/form-data; boundary= Content-Length: 209 -- Content-Disposition: form-data; name="id" 1 UNION SELECT 1,2,3,CONVERT(version() USING utf8) AS name,CONVERT(user() USING utf8) AS name,6,7,8,9,10,11,12 FROM wp_users WHERE id=1 ---- 

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

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

استنتاج

لذا ، هل يجب علينا الاعتماد بالكامل على WAF؟ الجواب هو لا.

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

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

المساهمون

ايليا بولاتوف barracud4
دينيس ريبين thefaeriedragon
الكسندر رومانوف web_rock