ما تغليف توقيع XML؟

تهدف هجمات تغليف عنصر التوقيع إلى تجاوز المصادقة والوصول غير المصرح به عن طريق معالجة بنية مستند XML دون إبطال توقيعه الرقمي.

يستغل هجوم تغليف توقيع XML الفجوة بين عملية التحقق من صحة التوقيع ومعالجة البيانات. يقوم المهاجم بحقن عنصر مكرر أو تم التلاعب به (مثل تأكيد SAML أو نص SOAP مزور) خارج الجزء الموقّع، وينتهي الأمر بالتطبيق بمعالجة البيانات الضارة.

لغة الترميز القابلة للتوسعة (XML) هي تنسيق بيانات قائم على النص يُستخدم لهيكلة البيانات وتخزينها بطريقة يمكن للبشر والآلة قراءتها. ويتم استخدامها في خدمات الويب وأنظمة الهوية وتبادل البيانات بين التطبيقات. 

مثل HTML، يتم تنظيم XML بعلامات مصممة لتمثيل البيانات. وتدعم العناصر والسمات المتداخلة، ما يسمح بتسلسلات هرمية معقدة.

غالبا ما تُستخدم XML في بروتوكولات SOAP وSAML وWS-Security.

<User>

 <Name>Bob</Name>

 <Role>Admin</Role>

</User> 

توقيع XML هو توقيع رقمي يتم تطبيقه على بيانات XML، ويتم تعريفه بواسطة مواصفات توقيع XML W3C. ويساعد عنصر توقيع XML على ضمان سلامة البيانات من خلال التأكيد على أن البيانات موثوقة ويمكن التحقق منها ولم يتم العبث بها.

• يتم تحديد جزء من مستند XML للتوقيع باستخدام <Reference> عنصر يحمل مُعرِّفًا (على سبيل المثال، #ID123).
  
  

• يتم احتساب التجزئة أو الملخص على تلك البيانات.

• يتم تشفير التجزئة باستخدام المفتاح الخاص للمرسل لتشكيل التوقيع.

• في <Signature> وتتم إضافة الكتلة إلى المستند باستخدام SignedInfo، الذي يحتوي على عنوان URI المرجعي وSignatureValue مع التجزئة المشفرة وKeyInfo مثل المفتاح العام أو الشهادة.

<ds:Signature>

 <ds:SignedInfo>

  <ds:Reference URI=”#ID123”/>

  <!-- تفاصيل أخرى مثل DigestMethod وCanonicalizationMethod -->

 </ds:SignedInfo>

 <ds:SignatureValue> ABC123xyz...</ds:SignatureValue>

</ds:Signature>

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

في ما يأتي كيفية عمل هجمات تغليف توقيع XML (XSW) عادةً:

• يبدأ المهاجمون برسالة XML حقيقية وموثوق بها، مثل استجابة تسجيل دخول صالحة موقعة رقميًا (مثل استجابة SAML شرعية). 

• ينقلون الجزء الموقع (الجزء المشار إليه في <ds:Reference URI=”#ID123”/> ) إلى مكان مختلف في المستند حيث لا يزال موجودًا تقنيًا ولكنه غير مستخدم. 

• قاموا بوضع بيانات مزورة في الموقع الأصلي. ولم يتم توقيع هذه البيانات المزورة ولكنها مصممة لتبدو شرعية. 

• تبحث معظم التطبيقات عن البيانات عن طريق اسم العلامة أو تعبير XPath، وليس عن طريق التحقق ما إذا كانت النسخة الموقّعة، لذلك ينتهي بهم الأمر باستخدام البيانات المزورة. 

• لا يزال التوقيع الرقمي صحيحًا لأنه يتحقق من الجزء الأصلي (المخفي الآن) الموقّع عليه، وليس الجزء المزوّر الذي يستخدمه التطبيق. 

لذا، يعتقد التطبيق أنه يعمل مع مستند موقّع آمن، ولكنه في الواقع يعمل على بيانات غير مصرح بها وتم التلاعب بها.

يوضح هذا المثال كيف يمكن للمهاجم أن يتلاعب بتأكيد SAML موقّع للحصول على وصول غير مصرح به للمسؤول من خلال استغلال منطق تحليل XML الضعيف والتحقق من صحته.

SAML هو بروتوكول يستند إلى XML يستخدم لتبادل معلومات المصادقة بأمان بين نظامين: موفر الهوية (IdP) وموفر الخدمة (SP). إنه يُمكّن تسجيل الدخول الموحد (SSO)، ما يسمح للمستخدمين بالمصادقة مرة واحدة والحصول على حق الوصول إلى خدمات متعددة دون الحاجة إلى تسجيل الدخول المتكرر.

هذا طلب SAML حقيقي تم التقاطه بواسطة أداة مثل SAML Raider في مجموعة Burp. يتضمن قسمًا موقعًا رقميًا، يعرف باسم تأكيد SAML، الذي يحتوي على تفاصيل هوية المستخدم. ضمن هذا التأكيد يوجد <NameID> علامة تمثل عادةً هوية المستخدم العادي. 

يحتوي الطلب أيضًا على توقيع رقمي صالح (<ds:Signature> )، ما يساعد على ضمان عدم العبث بمحتويات التأكيد. في هذه المرحلة، يكون الطلب آمنًا وموثوقًا به ويعمل على النحو المنشود.

في استجابة التطبيق، يظهر المستخدم على أنه قام بتسجيل الدخول باستخدام الهوية من الأصل <NameID> الحقل (عنوان البريد الإلكتروني للمستخدم العادي). يقوم التطبيق بقراءة المعلومات من بيانات SAML الموقعة واستخدامها بشكل صحيح كما هو متوقع.

يقوم المهاجم بتعديل طلب SAML سرًا عن طريق نقل التأكيد الأصلي والمُوقَّع رقميًا إلى جزء آخر من مستند XML، ما يسمح للتوقيع بالبقاء صالحًا واجتياز التحقق. 

مزيف <Assertion> يتم بعد ذلك إدخال تأكيد مُزيَّف في مكانه، ويحتوي على قيمة معّرف اسم (NameID) مُزيَّفة <NameID> قيمة مثل admin@libcurl.so. ينتهي التطبيق باستخدام هذا التأكيد الجديد غير المُوقَّع والذي يتحكم فيه المهاجم بدلاً من البيانات الأصلية المُوقَّعة. 

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

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

يوضح هذا المثال كيف يمكن خداع التحقق من توقيع XML الضعيف للوثوق في البيانات المزيفة. لا يُبطل المُهاجِم صلاحية التوقيع الرقمي. بدلاً من ذلك، يتم نقل البيانات المُوقَّعة إلى مكان آخر، ويتم وضع المعلومات المزيفة في المكان حيث يتوقع التطبيق البيانات الحقيقية. ثم يقوم التطبيق عن طريق الخطأ بمعالجة البيانات المزيفة، معتقدًا أنها آمنة.

تنقسم هجمات XSW عمومًا إلى بضع مجموعات فرعية أو أنواع رئيسية، يستغل كل منها طريقة تنفيذ التحقق من توقيع XML وتحليلها.

في ما يأتي تفصيل لأكثرها شيوعًا:

الطريقة: يقوم المهاجم بنقل العنصر الموقّع إلى جزء مختلف من مستند XML وإدراج عنصر خبيث في مكانه الأصلي.

الهدف: يستمر التحقق من صحة التوقيع (لأن البيانات المُوقَّعة لم تتغير)، ولكن التطبيق يعالج البيانات التي أدخلها المهاجم بدلاً من ذلك.

مثال: المُوقَّعة <Assertion> يتم نقله إلى الأسفل <Extra> واستبدالها بمزورة <Assertion> التي تمنح حقوق المسؤول.

الطريقة: يستغل المهاجم استخدام سمات معرف XML للإشارة إلى البيانات الموقعة.

الهدف: يقوم المهاجم بإنشاء عنصر مكرر بالمعرف نفسه ولكنه يضعه في موقع يقوم التطبيق بمعالجته أولاً.

مثال: يشير التوقيع إلى #ID-1234، لكن المحلّل يستخدم عنصر المهاجم المزيف بهذا المعرف بدلاً من المعرف الموقّع.

الطريقة: يتلاعب المهاجم بمساحات أسماء XML لإرباك عملية التحقق من صحة التوقيع.

الهدف: تغيير تفسير العنصر أو تجاوز عمليات التحقق الصارمة من المخطط مع الحفاظ على صحة التوقيع.

مثال: حقن عنصر خبيث <Assertion> في مساحة اسم جديدة بحيث يمر التحقق من الصحة ولكن منطق المعالجة يقبله.

الطريقة: تعديل الموضع <Signature> داخل XML المُوقَّع بحيث يغطي التحقق من الصحة الجزء الخطأ من المستند. 

الهدف: جعل المدقق يفكر أن كل شيء موقّع، ولكن مع استبعاد الأجزاء التي يتحكم فيها المهاجم من تغطية التوقيع.

مثال: نقل الأصل <ds:Signature> خارج التوقيع <Assertion> في غلاف وإدراج جديد غير موقّع <Assertion> (مثل <NameID>admin@libcurl.so</NameID> ). لا يزال التوقيع يتحقق من الصحة ولكن التطبيق ينتهي بمعالجة التأكيد الذي يتحكم فيه المهاجم.

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

الهدف: خداع مدقق التوقيع للتحقق من البيانات غير الضارة في أثناء معالجة التطبيق للبيانات الخبيثة.

مثال: قم بتعديل XML بحيث يكون XPath الخاص بالمحقق (على سبيل المثال، //Assertion[@ID=’A1’] ) يتم التلاعب بها لتتناسب مع عقدة غير ضارة في أثناء تحكم المهاجم <Assertion> في <NameID>admin@libcurl.so</NameID> المكان الذي يقرأ منه التطبيق. ويتم التحقق من التوقيع، لكن التطبيق يقوم بمعالجة العقدة الضارة.

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

السيناريو: يستخدم التطبيق تسجيل الدخول الموحد المستند إلى SAML لمصادقة المستخدمين. وتتضمن كل استجابة لتسجيل الدخول تأكيدًا موقعًا رقميًا لتطبيق SAML يحدد المستخدم. 

هجوم XSW: يلتقط المهاجم استجابة SAML شرعية وينفّذ حركة التأكيد الموقّع إلى جزء مختلف من مستند XML ويدرج تأكيدًا مزورًا يدعي أنه مسؤول في مكانه. 

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

السيناريو: تستخدم واجهة برمجة تطبيقات خدمة الويب (API) SOAP وWS-Security لمعالجة الطلبات. ويتم توقيع نص رسالة SOAP رقميًا للمساعدة على ضمان موثوقية الأمر.

هجوم XSW: يقوم المهاجم بتغليف جسم SOAP الأصلي الموقّع بعنصر غلاف غير ضار واستبداله بجسم جديد غير موقّع يحتوي على امتيازات مرتفعة أو إجراءات غير مصرح بها.

التأثير: إذا كانت الخدمة تعالج النص غير المُوقَّع، فيمكن للمهاجم تصعيد الامتيازات أو تنفيذ إجراءات مقيدة مثل عرض البيانات الحساسة أو تعديلها.

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

هجوم XSW: ينقل المهاجم الأمر الموقّع إلى موقع ثانوي ويحقن أمرًا غير موقّع (مثل حذف حساب مستخدم آخر أو إعادة تعيين كلمة مرور المسؤول) مكانه.

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

السيناريو: يقوم أحد البنوك بتأمين عمليات تحويل الأموال الخاصة به باستخدام توقيعات XML. ويحتوي كل طلب على تفاصيل المعاملة مثل مبلغ التحويل وأرقام حسابات المرسل والمستلم. يتم توقيع الطلبات رقمياً للمساعدة على ضمان الأصالة.

هجوم XSW: يلتقط أحد المهاجمين طلب تحويل صحيح، وينقل البيانات المُوقَّعة إلى قسم غير حرج من المستند ويدرج معاملة مزورة بمبلغ أكبر وحساب مستلم مختلف.

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

السيناريو: تقوم منصة على الإنترنت بتأمين رموزها المميزة باستخدام توقيعات XML الرقمية. ويحتوي كل رمز مميز على معلومات هوية المستخدم وحقوق الوصول ويتم توقيعه بشكل مشفر لمنع العبث.

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

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

لتحليل ما إذا كان التطبيق عرضة لهجمات تغليف توقيع XML، من المهم فهم كيفية تحليل بيانات XML ومعالجتها. ومن المهم بشكل خاص فهم تحليل XML ومعالجته في السياقات الحساسة للأمان مثل مصادقة SAML أو رسائل SOAP.

في ما يأتي بعض التقنيات والإستراتيجيات لتحديد الثغرات الأمنية هذه في البيئات الحقيقية:

تحقق مما إذا كان التطبيق يستخرج عناصر مثل <Assertion> استنادًا إلى اسم العلامة أو XPath أو الموضع بدلاً من التحقق من أنه العنصر المُوقَّع بالفعل. ويعد هذا السلوك علامة تحذيرية خطيرة على التعرض لهجمات XSW.

استخدم مجموعة Burp مع SAML Raider لحقن عنصر غير موقّع وهمي وتغليف العنصر الموقّع. إذا كان التطبيق يعالج البيانات المزيفة بينما لا يزال التوقيع يتحقق من صحته، فسيكون عرضة لـ XSW.

إدراج تأكيد مُوقَّع في قسم مخفي وتأكيد مزيف في مكان ظاهر. إذا قام التطبيق بمعالجة البيانات المزيفة، فهو عرضة لـ XSW.

نقل العنصر المُوقَّع (العنصر المشار إليه في <ds:Reference URI=”#some-id” /> ) إلى جزء مختلف من XML. بعد ذلك، قم بحقن عنصر جديد غير مُوقَّع بهيكل مماثل في مكانه الأصلي.

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

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

استخدم أدوات مثل SAML Raider أو SoapUI أو تسخير اختبار XML المخصص لتطبيق أنماط هجوم XSW. إذا كان التطبيق يقبل أيًا من الحمولات ويعالجها، فهذا يشير إلى ثغرة أمنية في XSW.

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

لحماية تطبيق ما من هجمات XSW، يمكن للمطورين تنفيذ معالجة XML صارمة، والتحقق من صحة التوقيعات بشكل صحيح والتأكد من استخدام البيانات الموثوقة والمُوقَّعة فقط.

في ما يأتي بعض التدابير المضادة المحددة التي يمكن أن تساعد على الدفاع ضد هجمات XSW:

يمكن أن تقلل هذه الممارسات من خطر استغلال المهاجمين لهياكل XML ومنطق معالجة التوقيع، ما يغلق الباب فعليًا أمام العديد من هجمات XSW.