إصلاح XRPL لتفويض الأذونات بعد اكتشاف ثغرة حرجة

قامت شبكة XRPL بسحب تعديل تفويض الصلاحيات بعد أن اكتشف تقرير مكافآت الأخطاء خللاً خطيراً أثناء الاختبار. الآن، أصبح الإصدار المحسّن V1.1 يكمل مراجعة الأمان وفحوصات الجودة.
توضح هذه الحادثة سبب حاجة التفويض على مستوى البروتوكول إلى حمايات تتجاوز الميزة الأساسية نفسها.
XRPL تعيد تصميم تفويض الصلاحيات بعد تقرير عن خلل
تفويض الصلاحيات، المعروف باسم XLS-75، يسمح لحساب واحد بمنح حساب آخر صلاحيات محددة للتصرف نيابة عنه. الهدف من هذه الصلاحيات أن تكون ضيقة ومحدودة، وليس منح المفوَّض سيطرة كاملة على الحساب.
أوضح ج. أيو أكينيلي، رئيس الهندسة في RippleX، أن الإصدار الأصلي V1.0 تم سحبه بعد الإبلاغ عن ثغرة عبر برنامج مكافآت الأخطاء قبل وصوله إلى الشبكة الرئيسية XRPL. وبدلاً من إصلاح ذلك الإصدار في مكانه، قدّم الفريق V1.1 لفصل الإصدار الأصلي عن النسخة المحسّنة.
اكتشف باحث يُدعى Shotes مشكلة عالية الخطورة تتعلق بصلاحيات التفويض غير القابلة للإلغاء. كان بإمكان المفوَّض حذف حسابه ثم إعادة إنشائه لاحقاً مع الاحتفاظ بكل الصلاحيات التي مُنحت له من حساب آخر، دون أي طريقة للحساب الأصلي لإلغائها.
التغييرات تجاوزت مجرد خلل واحد. يعالج V1.1 حالات حساسة تتعلق بهوية المفوَّض، ويمنع تفويض قدرات جديدة مثل عمليات Vault وLending بشكل غير مقصود. كما يصلح حساب الاحتياطي للمدفوعات المفوَّضة، ويغلق مسار توقيع متعدد كان يمكن أن يتجاوز فحوصات التفويض. كما تم تشديد سلوك الإلغاء.
وجدت المراجعة أيضاً خللاً متوسط الخطورة من نوع تجاوز عدد صحيح غير مُوقّع في isDelegable، والذي قد يسمح بتفسير قيمة صلاحية غير صحيحة كنوع معاملة قابلة للتفويض. لكن الباحثين قالوا إن المشكلة ليس لها تأثير حقيقي بدون سلوك خاطئ من المفوض.
اختبارات موسعة عبر سطح التفويض في XRPL
سجّل تقرير ضمان الجودة الذي نشره Ramkumar SG في 26 أغسطس 179 اختباراً مخصصاً لتفويض الصلاحيات، شملت 112 اختباراً وظيفياً و48 اختبار أمان عدائي و19 اختباراً بين الميزات. كما غطى الاختبار التفاعلات مع Batch وConfidential MPT وقائمة انتظار المعاملات والتوقيع المتعدد.
قالت عمليات XRPLedger إن جميع النتائج تم إصلاحها في V1.1 وتم التحقق منها من قبل شركة الأمان Cantina. كما أفاد فريق ضمان الجودة بعدم وجود أي تراجع في 5088 اختباراً، ولم تكن هناك أخطاء داخلية مفتوحة مصنفة كحرجة، وخلصوا إلى أن الميزة جاهزة للاستخدام الإنتاجي على مستوى الإصدار المختبر.
تم تقديم تفويض الصلاحيات في مايو 2025، وتم وضع علامة غير مدعوم في سبتمبر 2025 بانتظار إصلاح أمني، وأعيدت تسميته إلى PermissionDelegationV1_1 في أكتوبر، وأعيد دعمه في يونيو 2026.
كما ذكر CryptoPotato الأسبوع الماضي، أن لوحة معلومات عامة بناها المطور Denis Angell كانت تتابع مدى تطبيق تعديلات XRPL على شبكة devnet قبل وصولها إلى الشبكة الرئيسية، وكان التفويض من بين التعديلات التي تم وضع علامة عليها كغير مكتملة.
بالنسبة للمستخدمين ومزودي الحفظ، القدرة المقصودة لم تتغير. وكما قال أكينيلي، فإن V1.1 لا يغيّر ما يمكن أن يفعله XLS-75، بل يغيّر الشروط التي يتم تفعيل هذه القدرة فيها.
الأسئلة الشائعة
ما هو تفويض الصلاحيات في XRPL؟
هو ميزة تسمى XLS-75 وتسمح لحساب واحد بإعطاء حساب آخر صلاحيات محددة للتصرف نيابة عنه، دون منحه سيطرة كاملة على الحساب.
لماذا تم سحب الإصدار الأول من تفويض الصلاحيات؟
تم سحبه بعد اكتشاف ثغرة خطيرة عبر برنامج مكافآت الأخطاء. الثغرة كانت تسمح للمفوَّض بحذف حسابه وإعادة إنشائه مع الاحتفاظ بالصلاحيات دون إمكانية إلغائها.
ما الجديد في الإصدار V1.1؟
يعالج V1.1 مشكلات الهوية والصلاحيات غير المقصودة، ويصلح حساب الاحتياطي، ويغلق مسار توقيع متعدد كان يتجاوز الفحوصات، ويشدد سلوك الإلغاء. كما تم اختباره في 5088 اختباراً دون أي تراجع، وأصبح جاهزاً للاستخدام الإنتاجي.












