عندما تقرأ عناوين عناوين الثغرات، نادرًا ما يستحوذ حقن XML على الأضواء. فهي لا تملك نفس الاسم القوي الذي يميزها مثل RCE أو SQLi، كما أنها ليست مثيرة بصريًا مثل الثغرات البرّاقة عن بُعد. ولكن في العديد من حزم المؤسسات - نقاط نهاية SOAP، وواجهات برمجة تطبيقات XML القديمة، وخطوط معالجة المستندات، وتكامل SAML/SOAP - فإن حقن XML هو وضع الفشل الهادئ الذي يحول المدخلات الموثوقة إلى أخطاء منطقية.
في جوهرها، حقن XML ليس عملية استغلال واحدة. إنها مجموعة من السلوكيات حيث يغير XML الذي يتحكم فيه المهاجم كيفية تفسير الخادم للطلب. يمكن أن يعني ذلك أن استعلام XPath يُرجع فجأة سجلات غير متوقعة، أو أن يقوم المحلل بتحليل موارد خارجية لم تكن تنوي استدعاءها، أو أن توسيع الكيان يستهلك وحدة المعالجة المركزية والذاكرة. من وجهة نظر المهاجم، هذه كتل بناء عملية: قراءة الملفات، أو تشغيل الطلبات الداخلية، أو التسبب في فوضى مفيدة. من وجهة نظر المدافع، هذه القطع نفسها هي خريطة تنقل لإصلاح الثغرات المنطقية وثغرات إمكانية الملاحظة.
مذاق صغير وملموس - دون إعطاء أي شخص كتيب قواعد اللعبة
لا تحتاج إلى حمولات خيالية لرؤية النمط. تخيّل شيفرة من جانب الخادم تُنشئ شيفرة XPath من حقول الطلب عن طريق تسلسل سلسلة ساذج:
// نمط ضعيف (زائف)
UserId = request.xml.user.id.request.xml.user.id
الدور = request.xml.user.role.user.role
الاستعلام = "doc('/db/users.xml)/المستخدمون/المستخدمون/المستخدمون[id = " + userId + " والدور = "" + الدور + ""]"
النتيجة = xmlEngine.assess(query)
يبدو هذا غير ضار إذا معرف المستخدم و الدور مُشكَّلة بشكل جيد. لكن عندما تسمح لمدخلات المستخدم بالتحكم في بنية الاستعلام، فإنك بذلك تطمس الحدود بين البيانات و المنطق. إن حقن XPath هو النتيجة الطبيعية: يمكن التلاعب باستعلام هش لتغيير شروط الحقيقة وإرجاع صفوف لا ينبغي أن تُرجعها.
محور آخر هو التعامل مع الكيانات أو DTD. تسمح العديد من محركات XML بتعريفات نوع المستند والكيانات والمراجع الخارجية - وهي مفيدة للتركيب الشرعي، ولكنها خطيرة عند تشغيلها للإدخال غير الموثوق به. القاعدة الدفاعية بسيطة: إذا لم تكن بحاجة إلى توسيع الكيان أو معالجة نوع المستند DOCTYPE، فقم بإيقاف تشغيله.
لماذا يعدّ تحليل التكوين أكثر أهمية من عمليات الاستغلال الغامضة
هناك مستويان لهذه المشكلة. الأول هو الخطأ في منطق العمل - تمرير قيم غير موثوق بها إلى منطق الاستعلام، وتنسيق XML في مقيّمات XPath أو XPath الشبيهة بـ XPath، وافتراض أن "حسن التشكيل" يعني "آمن". يمكن إصلاح ذلك من خلال التصميم: التحقق من صحة البيانات وفصلها عن الاستعلامات.
والثاني هو سلوك المحلل. إن محللي XML أقوياء؛ حيث يمكنهم جلب محتويات الملفات، أو إجراء طلبات HTTP، أو توسيع الكيانات المتداخلة التي تتضخم ذاكرتها. هذه القدرات جيدة في السياقات الخاضعة للرقابة، وكارثية عندما يتم قبول المدخلات العامة. لذا فإن الدفاع العملي هو تقوية المحلل التحليلي بالإضافة إلى القياس عن بعد السلوكي.
تدابير مضادة عملية وملائمة للمهندسين (مع أمثلة)
ليس عليك حظر XML لتكون آمناً. أنت بحاجة إلى ثلاثة تغييرات اعتيادية
1) الحد من قدرة المحلل التحليلي. في معظم اللغات يمكنك تعطيل الكيانات الخارجية ومعالجة DOCTYPE. على سبيل المثال، في Java (واجهة برمجة التطبيقات الزائفة):
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature(""، صحيح);
dbf.setFeature(""، خطأ);
dbf.setFeature(""، خطأ);
أو في بايثون مع defusedxml (استخدم مكتبة ذات سلوك آمن افتراضيًا):
من defusedxml.ElementTree استيراد من سلسلة
شجرة = fromstring(untrusted_xml)
2) التحقق من الصحة والتقنين. إذا كانت نقطة النهاية الخاصة بك تحتاج فقط إلى مجموعة صغيرة من العلامات، فتحقق من صحة العلامات مقابل XSD أو ارفض أنواع DOCTYPEs غير المتوقعة. يفضل التحليل في هياكل البيانات واستخدام الوصول إلى المعلمات بدلاً من بناء الاستعلامات عن طريق تسلسل السلاسل.
3) الأداة والتنبيه. أضف الخطافات التي تراقب الإشارات الغريبة: استثناءات المحلِّل التي تشير إلى DOCTYPE/ENTITY، أو DNS/TTP الصادر المفاجئ من خدمة التحليل، أو عمليات فتح الملفات التي بدأت أثناء التحليل. هذه الإشارات قابلة للتنفيذ أكثر بكثير من أي قائمة قواعد ثابتة.
إشارات يمكن اكتشافها تساعد المدافعين بالفعل
عندما تقوم بضبط المراقبة، ابحث عن السلوكيات الحقيقية، وليس عن التوقيعات النصية الهشة:
- مكالمات DNS أو HTTP الصادرة من عملية المحلل التحليلي.
- محاولات الوصول إلى الملفات إلى المسارات المحلية التي تحدث أثناء معالجة XML.
- تتبع استثناءات المحلل التحليلي التي تشير إلى دقة DOCTYPE أو دقة الكيان الخارجي.
- الردود التي تتضمن فجأة حقولاً أو بيانات داخلية فقط (تشير إلى معالجة XPath أو الاستعلام).
- طفرات غير عادية في وحدة المعالجة المركزية/الذاكرة في تحليل التعليمات البرمجية تحت الحمل العادي.
هذه هي الأشياء التي يمكنك التنبيه عليها وفرزها بسرعة.
كيفية التدرب دون تهور
إذا كنت ترغب في التجربة - التحقق من قواعد الكشف، أو التأكد من عمل تقوية المحلل، أو التدريب على تحدي على غرار CTF - قم بذلك في المختبرات الخاضعة للرقابة فقط. لا تدفع XML مشوه في الإنتاج. بدلًا من ذلك، استخدم أجهزة افتراضية معزولة، أو نطاقات معملية قابلة للإثبات، أو الأدوات التي تولد معقمة وغير مستغلة حالات الاختبار.
سير عمل اللغة الطبيعية - بينليجنت في الحلقة
هذا هو المكان الذي تؤتي فيه الأتمتة العملية ثمارها. لا يجب أن تضطر إلى برمجة عشرات الاختبارات يدويًا لمجرد التحقق من صحة إعدادات المحلل أو منطق الكشف. باستخدام أداة اختبار خماسية تعتمد على اللغة الطبيعية مثل بنليجنت، يبدو التدفق هكذا في اللغة اليومية:
"تحقق من نقاط نهاية SOAP التدريجية بحثًا عن مخاطر حقن XML. استخدم المجسات الآمنة فقط، واجمع استثناءات المحلل، وأحداث الوصول إلى الملفات، وأي عمليات استدعاء DNS/HTTP صادرة. إنتاج خطوات تقوية ذات أولوية."
يقوم Penligent بتحويل هذه الجملة إلى عمليات فحص مستهدفة ومعقمة ضد بيئة الاختبار المعتمدة لديك. يقوم بتشغيل حالات الاختبار المركزة (وليس سلاسل الاستغلال المباشر)، ويجمع القياس عن بُعد (أخطاء المحلل، وسجلات الوصول إلى الملفات، وعمليات استدعاء DNS)، ويربط الأدلة، ويعيد قائمة مراجعة موجزة للإصلاح. بالنسبة للاعبي CTF، تتمثل الفائدة في السرعة: يمكنك التحقق من صحة الفرضية ومعرفة ما إذا كان اكتشافك قد تم إطلاقه - ثم التكرار - دون كتابة نصوص برمجية أو صياغة عشرات ملفات الحمولة.
فكرة ختامية
يبدو حقن XML غير مثير للإعجاب على لوحة قيادة الثغرات، لكن قوته الحقيقية تكمن في التخفي. إنه يستغل الافتراضات - أن طبقة البيانات غير ضارة، وأن المحلل يتصرف "كما هو متوقع"، وأن المراقبة ستكشف عن الإخفاقات الواضحة. إن إصلاحه لا يتعلق بتصحيح سحري واحد بقدر ما يتعلق بنظافة التصميم: تقليل امتيازات المحلل، وفصل البيانات عن المنطق، والتحقق من صحة الإشارات المهمة. تعمل الأدوات التي تحوّل نوايا اللغة الطبيعية إلى عمليات تحقق آمنة على إزالة الكدح وتسمح للفرق بالتركيز على الإصلاح والتعلم - وهو بالضبط الهدف من الأتمتة الدفاعية الحديثة.
