تلوث معلمة HTTP
من حيث تطوير التطبيق خلال المراحل القياسية، تكون بنية التطبيقات متعددة المستويات هي السائدة. البنية متعددة المستويات هي بنية خادم العميل، حيث يكون العرض التقديمي ومعالجة التطبيق وإدارة البيانات عبارة عن عمليات منفصلة كاملة. من الناحية الأساسية، تعتبر البنية متعددة المستويات ملائمة للمطورين. السبب في أنها ملائمة للمطورين هو حقيقة أنه يتعين على المطورين إعادة استخدام التعليمات البرمجية وتطوير التطبيقات التي لا يلزم فيها كتابة إطار التطبيق بالكامل مرة أخرى. يمكنهم فقط تعديل أجزاء من بنية التطبيق بناءً على المستويات ومرونة الربح في استخدام مثل هذه التطبيقات. الجزء المؤسف هو أن التعامل مع نفس البيانات عبر منصات متعددة يمكن أن يؤدي إلى خرق أمني، أو ترك التطبيق عرضة للخطر. يتم تشغيل الأخطاء المنطقية بهذه الطريقة وهي مختلفة تمامًا عن الهجمات المعتمدة على الحقن مثل:
- حقن LDAP/LDAP الأعمى
- حقن XML
- حقن HTML
- حقن SQL
- الحقن القائم على ORM
- حقن الربيع / حقن السبات
- حقن اكس باث
- حقن الأوامر
تقع جميع متغيرات "الحقن" المذكورة أعلاه ضمن ثغرات أمنية في التطبيق على مستوى التعليمات البرمجية وهي مختلفة تمامًا عن الثغرات الأمنية "المنطقية" التي لا يزال لها مستوى أكبر من التأثير على تطبيقات الويب. خلال بحثي القديم في المراحل المبكرة من تشريح النمط السلوكي لتطبيقات مختلفة تعتمد على منصات مختلفة على بنى ويب مختلفة، وجدت أن ذلك أدى إلى وجود اثنتين من نقاط الضعف المنطقية التي يمكن للمهاجم استخدامها لتحقيق فوائد. أدى هذا إلى فضول ذاتي لإجراء المزيد من البحث وتوصلت إلى استنتاج شيء موجود بالفعل يسمى "تلوث معلمات HTTP أو HPC". أثناء بحثي في Defencely، اكتشفت أن منهجية الهجوم المحددة هذه لا تعتمد فقط على نظام أساسي محدد ولكنها تُستخدم على نطاق واسع عبر العديد من الأنظمة الأساسية المختلفة الأخرى المستندة إلى الويب، مثل PHP على Apache، ASP.NET على IIS، الخ.
فائدة تلوث معلمة HTTP
قبل أن أثبت الضرورة المطلقة لاختبار التطبيق اليدوي، يجب أن أقول إن تسليط الضوء على المستفيدين من هذه الثغرة الأمنية سيكون أمرًا ضروريًا للغاية لجميع مجتمع الأمان المشترك. ولكن قبل ذلك، دعونا نرى كيف يتم نشر التطبيقات بطرق مختلفة ومعاملتها بطريقة مختلفة عند التعامل معها أو استدعائها لإنجاز "مهمة مفيدة". أريد أن يعرف القراء بالفعل الأساسيات الأساسية لنشر التطبيق، ولهذا السبب أقوم بنقل الحديث إلى الخطوات التالية التي يجب أن يكون القارئ على دراية بها بالفعل. أصبحت هندسة الويب أكثر تعقيدًا، وللحفاظ على كل شيء أبسط بالنسبة للمطورين، يضيف المطورون طبقات (دورة حياة RAD) لإعادة استخدام وظائف تلك الطبقات ولكن هذا في حد ذاته قد يؤدي إلى ظهور ثغرات أمنية. يوضح الرسم البياني أدناه كيفية نشر تطبيق عام لأغراض الراحة:
بالتوافق مع HTTP تلوث المعلمة، والذي يشير أيضًا إلى وضع سلاسل استعلام بنفس الاسم لمعالجة المنطق الذي يتم به التعامل مع سلسلة الاستعلام المشكلة حديثًا بواسطة معالج HTTP لخادم الويب؛ هناك احتمالات أن يتم استغلال هجمات تلوث معلمات HTTP التي تستهدف نقاط الضعف المنطقية في بنية الويب لصالح المهاجمين. هذا هو المكان الذي تعد فيه مراجعة اختبار الاختراق اليدوي جزءًا أساسيًا من أي اختبار أمني سواء كان ذلك مراجعة رمز التطبيق إلى جانب مراجعة منطق خادم الويب أو اختبار اختراق التطبيق الرسمي. للاستفادة حقًا من قوة تلوث معلمات HTTP، يجب أن يكون لدى مختبر الاختراق أو المهاجم معرفة أعمق بـ HTTP ومعالج HTTP الذي يتعاملون معه. بالإضافة إلى ذلك، يجب أن يعرف المهاجم أو مختبر اختراق الويب كيف يمكن اختبار هجمات تلوث معلمات HTTP لتوفير الأمان أو استهداف تطبيق للمستفيدين. إذن ما هؤلاء المستفيدون؟
- يمكن استخدام تلوث معلمة HTTP للتحايل على عوامل التصفية المختلفة أو القيود الأمنية أو اللوائح لتجاوز جدران حماية تطبيقات الويب.
- يمكن للمهاجم استخدام تلوث معلمة HTTP للاستفادة من الأمان الذي قد يلقيه معالج HTTP مثل أخطاء خادم الويب المستندة إلى تطبيق معلوماتي.
- يمكن للمهاجم استخدام تلوث معلمات HTTP بالتوازي مع الثغرات الأمنية الموجودة لتجاوز قواعد الأمان وبالتالي استغلال هذه الثغرات الأمنية.
على سبيل المثال، دع كود ASP خلفي معين يكون وافترض mod_security أثناء تثبيت جدار حماية التطبيق:
استخدام الحمولة: http://127.0.0.1/test.asp?file=.%./shritam_bhowmick.txt
من الممكن تجاوز القيود الأمنية التي يوفرها mod_security وبالتالي تنفيذ هجمات اجتياز المسار التي لم تكن ممكنة في الأصل. هذا (اجتياز المسار) على النقيض من تلوث معلمة HTTP جعل مثل هذه الهجمات المرنة ممكنة، وبالتالي تلاعب فعليًا بالاستعلام بطريقة ما من أجل إنجاز التجاوز باستخدام كيفية التعامل مع حركة مرور HTTP بواسطة معالج HTTP. يمكن استخدام هذا بالمثل مع MS-SQL حقن حيث يمكن أن يؤدي خادم IIS الذي يستخدم قواعد بيانات MS-SQL إلى تسوية خطيرة وبالتالي يتسبب في أضرار جسيمة.
على سبيل المثال:
النمط هنا لتجاوز حقن MS-SQL الذي كان له قيود أمنية سابقة يستخدم HPC أو HTTP Parameter Contaminating. يمكن أن يستهدف هذا أيضًا مترجمي PHP.
مثال على كود PHP الخلفي:
ولم تعد لغة Perl مضادة للرصاص:
أعطى كود Perl مع تطبيق HTTP Parameter Contaminating النتائج التالية:
الآن، بعد أن أثبتت وجهة نظري عبر تطبيق مختلف يتصرف بطريقة مختلفة باستخدام حمولات تلوث معلمات HTTP، فإن الخلاصة هي عدم استخدام وقت إنتاج المطور لإبقائه مستهلكًا للتطوير وبدلاً من ذلك التركيز فعليًا على اختبار الاختراق اليدوي الخدمات للتخفيف من حدة المشكلات الأعمق التي تعاملت معها سابقًا في تطبيقات المؤسسات واسعة النطاق.
دفاعيًا - غير قابل للكسر
من بين أمن التطبيقات في الهند، تعد شركة Defencely هي الشركة الرائدة التي تمكنت من إثبات خدماتها عالميًا في وقت قصير مع قصص نجاح ضخمة لمشاركتها. Defencely هو مزود خدمة أمان التطبيقات ولديه الآن العديد من الخدمات المميزة بصرف النظر عن أمان التطبيقات. هذا يتضمن:
- أمان تطبيق الويب
- شبكة الأمن
- الأمن موبايل
- أمن منطق الأعمال
لقد أخذت المنطقة الأمنية الصارمة زمام المبادرة بفضل خبرتها الواسعة مع قسم أبحاث قوي. تتمثل الرؤية الأساسية لشركة Defencely في توفير "الأمن" في أفضل حالاته لعملائها وإجراء "أبحاث أمنية" واكتشاف طرق جديدة وابتكار مفاهيم أمنية جديدة وتقديم منتج منها إلى العملاء الكرام. لم يحقق موقع Defencely.com حضورًا هنديًا قويًا فحسب، بل نقل أيضًا خدماته عالميًا لإحداث تأثير عميق على صناعة الأمن من خلال الخبرة المتزايدة في ما يفعله. يعد التركيز والجودة التي تقدمها بمثابة رصيد مثير للدهشة لأي بائع يأخذ خدماتها، وكان هناك الكثير من الضجة بالفعل بين القادة. لاتخاذ الخطوة التالية للأمام، تتجه شركة Defencely الآن من تكساس مع وجود قوي في الهند والولايات المتحدة. إنها توصية أساسية لاحتياجات الأعمال التجارية عبر الإنترنت فيما يتعلق بالأمن. لا شيء يمكن أن يقف أمام فريق Defencely القوي.
قراءة: هل يشكل الأطفال تهديدًا للأمن عبر الإنترنت؟
عن المؤلف
شريتام بوميك هو أحد مختبري اختراق التطبيقات المجهزين بشكل احترافي بخبرة اختبار اختراق التطبيقات التقليدية والمهنية التي تضيف قيمة إلى شركة Defencely Inc. Red Team ويمتلك حاليًا الخبرة الفنية في إعداد التقارير عن تهديدات التطبيقات والتنسيق لعملاء شركة Defencely Inc. العالميين. وفي حزام إنجازاته، يتمتع بخبرة في تحديد نقاط الضعف الهامة في التطبيقات وإضافة قيمة إلى شركة Defencely Inc. من خلال عمله البحثي. ينمو قطاع البحث والتطوير فيما يتعلق بأمن التطبيقات في شركة Defencely ويعتني به. من الناحية المهنية، كان لديه تجارب مع العديد من الشركات الأخرى التي تعمل على المشاركة في اختبار اختراق التطبيقات المهمة، حيث قاد الفريق الأحمر ولديه أيضًا خبرة في تدريب الطلاب الفضوليين في أوقات فراغه. رجل أمن التطبيق!
قام شريتام بهوميك بتقديم العديد من الأوراق البحثية التي تركز في الغالب على أمن التطبيقات ويحب أن يذهب أبعد من ذلك في التفاصيل. وقد دفعه هذا النهج إلى ابتكار الأشياء بدلاً من إعادة اختراع العجلة للآخرين لتسخير المفاهيم الأمنية القديمة. في وقت فراغه، وهو قليل جدًا، يقوم بالتدوين وتبادل الأفكار حول مفاهيم أمان الويب ويفضل الابتعاد عن الحياة العادية. وبصرف النظر عن حياته المهنية، فإنه يجد النعيم في قراءة الكتب، ولعب الشطرنج، والعمل الخيري، وكرة السلة للعرق. يحب بشدة مشاهدة الرعب أفلام من أجل التشويق.






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