يتيح نمط الوكيل للعقود الذكية ترقية منطقها مع الحفاظ على عناوينها على السلسلة وقيم الحالة. سيؤدي استدعاء عقد الوكيل إلى تنفيذ الكود من العقد المنطقي من خلال مندوب الاتصال لتعديل حالة عقد الوكيل.
ستقدم هذه المقالة نظرة عامة على أنواع عقود الوكيل ، والحوادث والتوصيات الأمنية ذات الصلة ، وأفضل الممارسات لاستخدام عقود الوكيل.
** مقدمة في العقود القابلة للترقية ووضع الوكيل **
نعلم جميعًا ميزة "عدم التلاعب" في blockchain ، ولا يمكن تعديل رمز العقد الذكي بعد نشره على blockchain.
لذلك عندما يرغب المطورون في تحديث رمز العقد للترقيات المنطقية أو إصلاحات الأخطاء أو تحديثات الأمان ، يجب عليهم نشر عقد جديد ، وسيتم إنشاء عنوان عقد جديد.
لحل هذه المشكلة ، يمكنك استخدام وضع الوكيل.
يدرك وضع الوكيل إمكانية ترقية العقد دون تغيير عنوان نشر العقد ، والذي يعد حاليًا وضع ترقية العقد الأكثر شيوعًا.
وضع الوكيل هو ** نظام عقد قابل للترقية ** ، بما في ذلك عقد الوكيل وعقد التنفيذ المنطقي.
يعالج عقد الوكيل تفاعل المستخدم والبيانات وتخزين حالة العقد. سيؤدي استدعاء المستخدم لعقد الوكيل إلى تنفيذ الكود من العقد المنطقي من خلال devatecall () ، وبالتالي تغيير حالة عقد الوكيل. تتحقق الترقية من خلال تحديث عنوان العقد المنطقي المسجل في فتحة التخزين المحددة مسبقًا لعقد الوكيل.
أوضاع الوكيل الثلاثة الأكثر تقليدية هي الوكيل الشفاف ، وكيل UUPS ووكيل منارة.
** وكيل شفاف **
في وضع الوكيل الشفاف ، يتم تنفيذ وظيفة الترقية في عقد الوكيل. يُمنح دور المسؤول لعقد الوكيل السلطة المباشرة لتشغيل عقد الوكيل لتحديث عنوان التنفيذ المنطقي المقابل للوكيل. المتصلون الذين ليس لديهم امتيازات المسؤول سوف يفوضون مكالماتهم لعقد التنفيذ.
ملاحظة: لا يمكن أن يكون مسؤول العقد الوكيل دورًا رئيسيًا في التنفيذ المنطقي للعقد ، ولا يمكنه حتى أن يكون مستخدمًا عاديًا ، لأن مدير الوكيل لا يمكنه التفاعل مع عقد التنفيذ.
** وكيل UUPS **
في وضع UUPS (معيار الوكيل العالمي القابل للترقية) ، يتم تنفيذ وظيفة ترقية العقد في العقد المنطقي. نظرًا لأنه يتم تخزين آلية الترقية في العقد المنطقي ، يمكن للإصدار الذي تمت ترقيته حذف المنطق المتعلق بالترقية لمنع الترقيات المستقبلية. في هذا الوضع ، يتم تحويل جميع استدعاءات عقد الوكيل إلى عقد تنفيذ المنطق.
** وكيل منارة **
يسمح وضع الوكيل منارة بعقود الوكيل المتعددة بمشاركة نفس التنفيذ المنطقي من خلال الرجوع إلى عقد منارة. يوفر عقد الإشارة التنبيهية عنوان عقد التنفيذ المنطقي لعقد الوكيل المسمى. عند الترقية إلى عنوان تنفيذ منطقي جديد ، يحتاج فقط العنوان المسجل في عقد المنارة إلى التحديث.
** إساءة استخدام الوكيل والحوادث الأمنية **
يمكن للمطورين الاستفادة من عقود وضع الوكيل لتنفيذ أنظمة عقود قابلة للترقية. ومع ذلك ، فإن وضع الوكيل له أيضًا عتبات تشغيلية معينة.إذا تم استخدامه بشكل غير صحيح ، فقد يؤدي إلى مشاكل أمنية مدمرة للمشروع. تعرض الأقسام التالية الحوادث المتعلقة بإساءة استخدام الوكيل ، ومخاطر المركزية التي يشكلها الوكلاء.
** الإفصاح عن المفتاح المُدار بواسطة الوكيل **
يتحكم مسؤول الوكيل في آلية الترقية لوضع الوكيل الشفاف ، إذا تم تسريب المفتاح الخاص للمسؤول ، يمكن للمهاجم ترقية العقد المنطقي وتنفيذ منطقه الضار في حالة الوكيل.
في 5 مارس 2021 ، تعرضت شبكة PAID لهجوم "سك" بسبب سوء إدارة المفتاح الخاص. تم استغلال شبكة PAID من قبل مهاجم سرق المفتاح الخاص لمسؤول الوكيل وقام بتشغيل آلية ترقية لتغيير عقد المنطق.
بعد الترقية ، يمكن للمهاجم إتلاف المبلغ المدفوع للمستخدم وسك دفعة من مدفوعة الأجر لنفسه ، والتي يمكن بيعها لاحقًا. لا توجد ثغرة أمنية في الكود نفسه ، لكن المهاجم حصل على المفتاح الخاص لترقية العقد من المسؤول.
** تنفيذ وكيل UUPS غير مهيأ **
بالنسبة لوضع وكيل UUPS ، أثناء تهيئة عقد الوكيل ، يتم تمرير المعلمات الأولية إلى عقد الوكيل بواسطة المتصل ، ثم يستدعي عقد الوكيل وظيفة التهيئة () في العقد المنطقي لتحقيق التهيئة.
عادة ما تكون وظيفة التهيئة () محمية بواسطة معدِّل "التهيئة" لتقييد استدعاء الوظيفة مرة واحدة فقط. بعد استدعاء دالة التهيئة () ، من منظور عقد الوكيل ، يتم تهيئة العقد المنطقي.
ومع ذلك ، من منظور العقد المنطقي ، لا تتم تهيئة العقد المنطقي لأن التهيئة () لا يتم استدعاؤها مباشرة في العقد المنطقي. بالنظر إلى أن العقد المنطقي نفسه لم تتم تهيئته ، يمكن لأي شخص استدعاء وظيفة التهيئة () لتهيئته ، وتعيين متغير الحالة إلى قيمة ضارة ، ومن المحتمل أن يتولى عقد المنطق.
يعتمد تأثير العقد المنطقي الذي يتم توليه على رمز العقد في النظام. في أسوأ الحالات ، يمكن للمهاجم ترقية العقد المنطقي في وضع وكيل UUPS إلى عقد ضار وتنفيذ استدعاء وظيفة "التدمير الذاتي" ، مما قد يتسبب في أن يصبح عقد الوكيل بأكمله عديم الفائدة ، وستكون الأصول الموجودة في العقد تضيع بشكل دائم.
قضية
① تجميد Parity Multisig: لم تتم تهيئة العقد المنطقي. يقوم المهاجم بتشغيل العديد من المحافظ ويغلق الأثير في العقد عن طريق استدعاء selfdestruct ().
② تستخدم كل من Harvest Finance و Teller و KeeperDAO و Rivermen عقودًا منطقية غير مهيأة ، والتي ستسمح للمهاجمين بتعيين معلمات التهيئة للعقود بشكل تعسفي ، وتنفيذ التدمير الذاتي () أثناء الاستدعاء المفوض () لتدمير عقد الوكيل.
** تعارض التخزين **
في نظام عقد قابل للترقية ، لا يعلن عقد الوكيل عن متغيرات الحالة ، ولكنه يستخدم فتحات تخزين عشوائية زائفة لتخزين البيانات المهمة.
تخزن عقود الوكيل قيم متغيرات حالة العقد المنطقية المتعلقة بالمكان الذي تم الإعلان عنه فيه. إذا أعلن عقد الوكيل عن متغيرات الحالة الخاصة به وحاول كل من الوكيل والعقد المنطقي استخدام نفس فتحة التخزين ، فسيحدث تعارض في التخزين.
لا يعلن عقد الوكيل المقدم من مكتبة OpenZeppelin عن متغيرات الحالة في العقد ، ولكن استنادًا إلى معيار EIP 1967 ، يحفظ القيمة التي يجب تخزينها (مثل عنوان الإدارة) في فتحة تخزين محددة لمنع التعارضات.
قضية
في 23 يوليو 2022 ، بتوقيت بكين ، تم اختراق منصة الموسيقى اللامركزية Audius ، وكان سبب الحادث إدخال منطق جديد في عقد الوكيل ، مما أدى إلى تعارض في التخزين.
يعلن عقد الوكيل عن متغير حالة عنوان proxyAdmin ، وستتم قراءة قيمته بشكل غير صحيح عند تنفيذ رمز العقد المنطقي.
تم اعتبار قيمة proxyAdmin التي خصصها طرف المشروع عن طريق الخطأ على أنها قيمة تمت التهيئة والتهيئة ، بحيث أرجع معدِّل المُهيئ نتيجة خاطئة ، مما سمح للمهاجم باستدعاء وظيفة التهيئة () مرة أخرى ومنح نفسه سلطة إدارة عقد. ثم قام المهاجمون بتغيير معلمات التصويت وتمرير اقتراحهم الخبيث لسرقة أصول Audius.
** استدعاء مندوب الاتصال () في عقد منطقي أو عقد غير موثوق به **
لنفترض وجود مندوب () في عقد منطقي ، وأن العقد لا يقوم بالتحقق من صحة هدف المكالمة بشكل صحيح. في هذه الحالة ، يمكن للمهاجم استغلال هذه الوظيفة لتنفيذ استدعاءات للعقود الضارة التي يتحكم فيها ، أو لإفساد تطبيقات المنطق ، أو لتنفيذ منطق مخصص.
وبالمثل ، إذا كانت هناك وظيفة عنوان غير مقيد.call () في العقد المنطقي ، فبمجرد أن يقوم المهاجم بتوفير العنوان وحقول البيانات بشكل ضار ، يمكن استخدامه كعقد وكيل.
قضية
هجمات Pickle Finance و Furucombo و dYdX.
في هذه الحوادث ، تمت الموافقة على العقد الضعيف بواسطة رمز المستخدم ، وهناك مكالمة () / مندوب اتصال () في العقد يتم توفيرها من قبل المستخدم للاتصال بعنوان العقد والبيانات ، وسيكون المهاجم قادرًا على استدعاء عقد الوظيفة TransferFrom () لسحب أرصدة المستخدم. خلال حادثة dYdX ، نفذت dYdX هجوم القبعة البيضاء الخاص بها لحماية الأموال.
أفضل الممارسات
عمومًا
(1) استخدم وضع الوكيل فقط عند الضرورة
ليس كل عقد يحتاج إلى ترقية. كما هو موضح أعلاه ، هناك العديد من المخاطر التي ينطوي عليها استخدام نمط الوكيل. تثير الخاصية "القابلة للترقية" أيضًا مشكلات تتعلق بالثقة ، حيث يمكن لمسؤولي البروكسي ترقية العقود دون موافقة المجتمع. نوصي بدمج نمط الوكيل في المشاريع عند الضرورة فقط.
(2) لا تقم بتعديل مكتبة الوكيل
مكتبة عقود الوكيل معقدة ، خاصة الجزء الذي يتعامل مع إدارة التخزين وآليات الترقية. أي أخطاء في التعديل ستؤثر على عمل عقود التوكيل والمنطق. كان سبب عدد كبير من الأخطاء المتعلقة بالوكيل عالية الخطورة والتي وجدناها أثناء عمليات التدقيق لدينا هي تعديلات مكتبة الوكيل غير الصحيحة. حادثة أوديوس هي مثال رئيسي على عواقب التعديل غير المناسب لعقود الوكالة.
** النقاط الرئيسية لتشغيل وإدارة عقد الوكالة **
(1) بدء العقد المنطقي
يمكن للمهاجم تولي عقد منطق غير مهيأ وربما يعرض نظام عقد الوكيل للخطر. لذا يرجى تهيئة العقد المنطقي بعد النشر ، أو استخدام \ _disableInitializers () في مُنشئ العقد المنطقي لتعطيل التهيئة تلقائيًا.
(2) التأكد من أمان حساب إدارة الوكيل
يتطلب نظام العقد القابل للترقية دورًا متميزًا "لمسؤول الوكيل" لإدارة ترقيات العقد. إذا تم تسريب مفتاح الإدارة ، يمكن للمهاجم ترقية العقد بحرية إلى عقد ضار ، والذي يمكن أن يسرق أصول المستخدمين. نوصي بإدارة دقيقة للمفاتيح الخاصة لحسابات مسؤول الوكيل لتجنب أي مخاطر محتملة للقرصنة. يمكن استخدام محافظ التوقيع المتعدد لمنع فشل إدارة المفتاح أحادي النقطة.
(3) استخدم حسابًا منفصلاً لإدارة الوكيل الشفافة
يجب أن تكون إدارة الوكيل والحوكمة المنطقية عناوين منفصلة لمنع فقدان التفاعل مع تنفيذ المنطق. إذا كانت إدارة الوكيل والحوكمة المنطقية تشير إلى نفس العنوان ، فلن تتم إعادة توجيه أي مكالمات لأداء وظائف ذات امتياز ، مما يحظر إجراء تغييرات على وظائف الحوكمة.
** متعلق بتخزين عقد الوكيل **
(1) كن حذرًا عند الإعلان عن متغيرات الحالة في عقود التوكيل
كما هو موضح في اختراق Audius ، يجب أن تكون عقود الوكيل حذرة عند الإعلان عن متغيرات الحالة الخاصة بها. يمكن أن تتسبب متغيرات الحالة المعلنة بالطريقة العادية في عقود الوكيل في حدوث تعارض في البيانات عند قراءة البيانات وكتابتها. إذا كان عقد الوكيل يتطلب متغير حالة ، فاحفظ القيمة في فتحة تخزين مثل EIP1967 لمنع التعارضات عند تنفيذ كود العقد المنطقي.
(2) الحفاظ على أمر الإعلان المتغير ونوع العقد المنطقي
يجب أن تحافظ كل نسخة من العقد المنطقي على نفس ترتيب ونوع متغيرات الحالة ، ويجب إضافة متغيرات الحالة الجديدة في نهاية المتغيرات الحالية. خلاف ذلك ، يمكن أن تتسبب مكالمات المفوضين في قراءة عقود الوكيل أو الكتابة فوق القيم المخزنة غير الصحيحة ، وقد ترتبط البيانات القديمة بالمتغيرات المعلنة حديثًا ، مما قد يتسبب في مشاكل خطيرة للتطبيقات.
(3) قم بتضمين فجوات التخزين في العقد الأساسي
تحتاج العقود المنطقية إلى تضمين فجوات التخزين في كود العقد لتوقع متغيرات الحالة الجديدة عند نشر تطبيقات منطقية جديدة. بعد إضافة متغير حالة جديد ، يجب تحديث حجم الفجوة بشكل مناسب.
(4) لا تقم بتعيين قيمة متغير الحالة في عملية الإنشاء أو الإعلان
يؤثر تعيين متغير حالة أثناء الإعلان أو في المنشئ فقط على القيمة في العقد المنطقي ، وليس عقد الوكيل. يجب تعيين المعلمات غير الثابتة باستخدام دالة التهيئة ().
** وراثة العقد **
(1) يمكن أن ترث العقود القابلة للترقية فقط من العقود الأخرى القابلة للترقية
العقود القابلة للترقية لها هيكل مختلف عن العقود غير القابلة للترقية. على سبيل المثال ، المُنشئ غير متوافق مع تغيير حالة الوكيل ، فهو يستخدم وظيفة التهيئة () لتعيين متغيرات الحالة.
يحتاج أي عقد يرث من عقد آخر إلى استخدام وظيفة التهيئة () لعقده الموروث لتعيين المتغيرات الخاصة به. عند استخدام مكتبة OpenZeppelin أو كتابة التعليمات البرمجية الخاصة بك ، تأكد من أن العقود القابلة للترقية يمكنها فقط أن ترث العقود الأخرى القابلة للترقية.
(2) لا تقم بإنشاء عقود جديدة في العقود المنطقية
العقود التي تم إنشاؤها وإنشاء مثيل لها من خلال Solidity لن تكون قابلة للترقية. يجب نشر العقود بشكل فردي وتمرير عنوانها كمعامل لعقد المنطق القابل للترقية لتحقيق حالة قابلة للترقية.
(3) مخاطر بدء عقد الوالدين
عند تهيئة عقد الوالدين ، ستعمل وظيفة \ _ \ _ {ContractName} \ _ init على تهيئة عقد الوالدين. المكالمات المتعددة لـ \ _ \ _ {ContractName} \ _ init قد ينتج عنها تهيئة ثانية لعقد الأصل. لاحظ أن \ _ \ _ {ContractName} \ _ init \ _unchained () سيهيئ فقط معلمات {ContractName} ، ولن يستدعي مُهيئ عقد الأصل الخاص به.
ومع ذلك ، هذه ليست ممارسة موصى بها ، لأن جميع عقود الوالدين تحتاج إلى التهيئة ، وعدم تهيئة العقود المطلوبة سيؤدي إلى مشاكل التنفيذ في المستقبل.
** تنفيذ العقد المنطقي **
** تجنب التدمير الذاتي () أو selegatecall () / call () لعقود غير موثوق بها **
إذا كان هناك إتلاف ذاتي () أو تفويض استدعاء () في العقد ، فمن الممكن للمهاجم استخدام هذه الوظائف لكسر تطبيق المنطق أو تنفيذ منطق مخصص. يجب على المطورين التحقق من صحة إدخال المستخدم وعدم السماح للعقود بتنفيذ استدعاءات التفويض / المكالمات للعقود غير الموثوق بها. أيضًا ، لا يوصى باستخدام devatecall () في العقود المنطقية لأنه سيكون مرهقًا لإدارة تخطيط التخزين في سلسلة المفوضين لعقود متعددة.
** مكتوبة في النهاية **
تتجاوز عقود البروكسي الطبيعة غير القابلة للتغيير لشبكات البلوكشين من خلال تمكين البروتوكولات لتحديث منطق الكود الخاص بها بعد النشر. ومع ذلك ، لا يزال تطوير عقود الوكيل بحاجة إلى توخي الحذر الشديد ، وقد يتسبب التنفيذ غير الصحيح في مشاكل تتعلق بأمان المشروع ومنطقه.
بشكل عام ، تتمثل أفضل الممارسات في استخدام حلول موثوقة ومُختبرة على نطاق واسع ، حيث أثبت كل من أوضاع الوكيل الشفافة و UUPS و Beacon Proxy آليات ترقية مثبتة لحالات الاستخدام الخاصة بكل منها. بالإضافة إلى ذلك ، يجب أيضًا إدارة الأدوار المميزة لعملاء التصعيد بشكل آمن لمنع المهاجمين من تغيير منطق الوكيل.
يجب أن يحرص عقد التنفيذ المنطقي أيضًا على عدم استخدام devatecall () ، والذي يمكن أن يمنع المهاجمين من تنفيذ بعض التعليمات البرمجية الضارة ، مثل selfdestruct ().
بينما يضمن اتباع أفضل الممارسات عمليات نشر ثابتة لعقد الوكيل مع الحفاظ على المرونة القابلة للترقية ، فإن جميع التعليمات البرمجية معرضة لمشاكل أمنية أو منطقية جديدة قد تعرض المشروع للخطر. لذلك ، يتم تدقيق جميع التعليمات البرمجية بشكل أفضل من قبل فريق من خبراء الأمن ذوي الخبرة في تدقيق وتأمين بروتوكولات عقد الوكيل.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
كسر ثبات blockchain: كيف يمكن للنموذج الوكيل تحقيق ترقيات العقد الذكية
يتيح نمط الوكيل للعقود الذكية ترقية منطقها مع الحفاظ على عناوينها على السلسلة وقيم الحالة. سيؤدي استدعاء عقد الوكيل إلى تنفيذ الكود من العقد المنطقي من خلال مندوب الاتصال لتعديل حالة عقد الوكيل.
ستقدم هذه المقالة نظرة عامة على أنواع عقود الوكيل ، والحوادث والتوصيات الأمنية ذات الصلة ، وأفضل الممارسات لاستخدام عقود الوكيل.
** مقدمة في العقود القابلة للترقية ووضع الوكيل **
نعلم جميعًا ميزة "عدم التلاعب" في blockchain ، ولا يمكن تعديل رمز العقد الذكي بعد نشره على blockchain.
لذلك عندما يرغب المطورون في تحديث رمز العقد للترقيات المنطقية أو إصلاحات الأخطاء أو تحديثات الأمان ، يجب عليهم نشر عقد جديد ، وسيتم إنشاء عنوان عقد جديد.
لحل هذه المشكلة ، يمكنك استخدام وضع الوكيل.
يدرك وضع الوكيل إمكانية ترقية العقد دون تغيير عنوان نشر العقد ، والذي يعد حاليًا وضع ترقية العقد الأكثر شيوعًا.
وضع الوكيل هو ** نظام عقد قابل للترقية ** ، بما في ذلك عقد الوكيل وعقد التنفيذ المنطقي.
يعالج عقد الوكيل تفاعل المستخدم والبيانات وتخزين حالة العقد. سيؤدي استدعاء المستخدم لعقد الوكيل إلى تنفيذ الكود من العقد المنطقي من خلال devatecall () ، وبالتالي تغيير حالة عقد الوكيل. تتحقق الترقية من خلال تحديث عنوان العقد المنطقي المسجل في فتحة التخزين المحددة مسبقًا لعقد الوكيل.
أوضاع الوكيل الثلاثة الأكثر تقليدية هي الوكيل الشفاف ، وكيل UUPS ووكيل منارة.
** وكيل شفاف **
في وضع الوكيل الشفاف ، يتم تنفيذ وظيفة الترقية في عقد الوكيل. يُمنح دور المسؤول لعقد الوكيل السلطة المباشرة لتشغيل عقد الوكيل لتحديث عنوان التنفيذ المنطقي المقابل للوكيل. المتصلون الذين ليس لديهم امتيازات المسؤول سوف يفوضون مكالماتهم لعقد التنفيذ.
ملاحظة: لا يمكن أن يكون مسؤول العقد الوكيل دورًا رئيسيًا في التنفيذ المنطقي للعقد ، ولا يمكنه حتى أن يكون مستخدمًا عاديًا ، لأن مدير الوكيل لا يمكنه التفاعل مع عقد التنفيذ.
** وكيل UUPS **
في وضع UUPS (معيار الوكيل العالمي القابل للترقية) ، يتم تنفيذ وظيفة ترقية العقد في العقد المنطقي. نظرًا لأنه يتم تخزين آلية الترقية في العقد المنطقي ، يمكن للإصدار الذي تمت ترقيته حذف المنطق المتعلق بالترقية لمنع الترقيات المستقبلية. في هذا الوضع ، يتم تحويل جميع استدعاءات عقد الوكيل إلى عقد تنفيذ المنطق.
** وكيل منارة **
يسمح وضع الوكيل منارة بعقود الوكيل المتعددة بمشاركة نفس التنفيذ المنطقي من خلال الرجوع إلى عقد منارة. يوفر عقد الإشارة التنبيهية عنوان عقد التنفيذ المنطقي لعقد الوكيل المسمى. عند الترقية إلى عنوان تنفيذ منطقي جديد ، يحتاج فقط العنوان المسجل في عقد المنارة إلى التحديث.
** إساءة استخدام الوكيل والحوادث الأمنية **
يمكن للمطورين الاستفادة من عقود وضع الوكيل لتنفيذ أنظمة عقود قابلة للترقية. ومع ذلك ، فإن وضع الوكيل له أيضًا عتبات تشغيلية معينة.إذا تم استخدامه بشكل غير صحيح ، فقد يؤدي إلى مشاكل أمنية مدمرة للمشروع. تعرض الأقسام التالية الحوادث المتعلقة بإساءة استخدام الوكيل ، ومخاطر المركزية التي يشكلها الوكلاء.
** الإفصاح عن المفتاح المُدار بواسطة الوكيل **
يتحكم مسؤول الوكيل في آلية الترقية لوضع الوكيل الشفاف ، إذا تم تسريب المفتاح الخاص للمسؤول ، يمكن للمهاجم ترقية العقد المنطقي وتنفيذ منطقه الضار في حالة الوكيل.
في 5 مارس 2021 ، تعرضت شبكة PAID لهجوم "سك" بسبب سوء إدارة المفتاح الخاص. تم استغلال شبكة PAID من قبل مهاجم سرق المفتاح الخاص لمسؤول الوكيل وقام بتشغيل آلية ترقية لتغيير عقد المنطق.
بعد الترقية ، يمكن للمهاجم إتلاف المبلغ المدفوع للمستخدم وسك دفعة من مدفوعة الأجر لنفسه ، والتي يمكن بيعها لاحقًا. لا توجد ثغرة أمنية في الكود نفسه ، لكن المهاجم حصل على المفتاح الخاص لترقية العقد من المسؤول.
** تنفيذ وكيل UUPS غير مهيأ **
بالنسبة لوضع وكيل UUPS ، أثناء تهيئة عقد الوكيل ، يتم تمرير المعلمات الأولية إلى عقد الوكيل بواسطة المتصل ، ثم يستدعي عقد الوكيل وظيفة التهيئة () في العقد المنطقي لتحقيق التهيئة.
عادة ما تكون وظيفة التهيئة () محمية بواسطة معدِّل "التهيئة" لتقييد استدعاء الوظيفة مرة واحدة فقط. بعد استدعاء دالة التهيئة () ، من منظور عقد الوكيل ، يتم تهيئة العقد المنطقي.
ومع ذلك ، من منظور العقد المنطقي ، لا تتم تهيئة العقد المنطقي لأن التهيئة () لا يتم استدعاؤها مباشرة في العقد المنطقي. بالنظر إلى أن العقد المنطقي نفسه لم تتم تهيئته ، يمكن لأي شخص استدعاء وظيفة التهيئة () لتهيئته ، وتعيين متغير الحالة إلى قيمة ضارة ، ومن المحتمل أن يتولى عقد المنطق.
يعتمد تأثير العقد المنطقي الذي يتم توليه على رمز العقد في النظام. في أسوأ الحالات ، يمكن للمهاجم ترقية العقد المنطقي في وضع وكيل UUPS إلى عقد ضار وتنفيذ استدعاء وظيفة "التدمير الذاتي" ، مما قد يتسبب في أن يصبح عقد الوكيل بأكمله عديم الفائدة ، وستكون الأصول الموجودة في العقد تضيع بشكل دائم.
قضية
① تجميد Parity Multisig: لم تتم تهيئة العقد المنطقي. يقوم المهاجم بتشغيل العديد من المحافظ ويغلق الأثير في العقد عن طريق استدعاء selfdestruct ().
② تستخدم كل من Harvest Finance و Teller و KeeperDAO و Rivermen عقودًا منطقية غير مهيأة ، والتي ستسمح للمهاجمين بتعيين معلمات التهيئة للعقود بشكل تعسفي ، وتنفيذ التدمير الذاتي () أثناء الاستدعاء المفوض () لتدمير عقد الوكيل.
** تعارض التخزين **
في نظام عقد قابل للترقية ، لا يعلن عقد الوكيل عن متغيرات الحالة ، ولكنه يستخدم فتحات تخزين عشوائية زائفة لتخزين البيانات المهمة.
تخزن عقود الوكيل قيم متغيرات حالة العقد المنطقية المتعلقة بالمكان الذي تم الإعلان عنه فيه. إذا أعلن عقد الوكيل عن متغيرات الحالة الخاصة به وحاول كل من الوكيل والعقد المنطقي استخدام نفس فتحة التخزين ، فسيحدث تعارض في التخزين.
لا يعلن عقد الوكيل المقدم من مكتبة OpenZeppelin عن متغيرات الحالة في العقد ، ولكن استنادًا إلى معيار EIP 1967 ، يحفظ القيمة التي يجب تخزينها (مثل عنوان الإدارة) في فتحة تخزين محددة لمنع التعارضات.
قضية
في 23 يوليو 2022 ، بتوقيت بكين ، تم اختراق منصة الموسيقى اللامركزية Audius ، وكان سبب الحادث إدخال منطق جديد في عقد الوكيل ، مما أدى إلى تعارض في التخزين.
يعلن عقد الوكيل عن متغير حالة عنوان proxyAdmin ، وستتم قراءة قيمته بشكل غير صحيح عند تنفيذ رمز العقد المنطقي.
تم اعتبار قيمة proxyAdmin التي خصصها طرف المشروع عن طريق الخطأ على أنها قيمة تمت التهيئة والتهيئة ، بحيث أرجع معدِّل المُهيئ نتيجة خاطئة ، مما سمح للمهاجم باستدعاء وظيفة التهيئة () مرة أخرى ومنح نفسه سلطة إدارة عقد. ثم قام المهاجمون بتغيير معلمات التصويت وتمرير اقتراحهم الخبيث لسرقة أصول Audius.
** استدعاء مندوب الاتصال () في عقد منطقي أو عقد غير موثوق به **
لنفترض وجود مندوب () في عقد منطقي ، وأن العقد لا يقوم بالتحقق من صحة هدف المكالمة بشكل صحيح. في هذه الحالة ، يمكن للمهاجم استغلال هذه الوظيفة لتنفيذ استدعاءات للعقود الضارة التي يتحكم فيها ، أو لإفساد تطبيقات المنطق ، أو لتنفيذ منطق مخصص.
وبالمثل ، إذا كانت هناك وظيفة عنوان غير مقيد.call () في العقد المنطقي ، فبمجرد أن يقوم المهاجم بتوفير العنوان وحقول البيانات بشكل ضار ، يمكن استخدامه كعقد وكيل.
قضية
هجمات Pickle Finance و Furucombo و dYdX.
في هذه الحوادث ، تمت الموافقة على العقد الضعيف بواسطة رمز المستخدم ، وهناك مكالمة () / مندوب اتصال () في العقد يتم توفيرها من قبل المستخدم للاتصال بعنوان العقد والبيانات ، وسيكون المهاجم قادرًا على استدعاء عقد الوظيفة TransferFrom () لسحب أرصدة المستخدم. خلال حادثة dYdX ، نفذت dYdX هجوم القبعة البيضاء الخاص بها لحماية الأموال.
أفضل الممارسات
عمومًا
(1) استخدم وضع الوكيل فقط عند الضرورة
ليس كل عقد يحتاج إلى ترقية. كما هو موضح أعلاه ، هناك العديد من المخاطر التي ينطوي عليها استخدام نمط الوكيل. تثير الخاصية "القابلة للترقية" أيضًا مشكلات تتعلق بالثقة ، حيث يمكن لمسؤولي البروكسي ترقية العقود دون موافقة المجتمع. نوصي بدمج نمط الوكيل في المشاريع عند الضرورة فقط.
(2) لا تقم بتعديل مكتبة الوكيل
مكتبة عقود الوكيل معقدة ، خاصة الجزء الذي يتعامل مع إدارة التخزين وآليات الترقية. أي أخطاء في التعديل ستؤثر على عمل عقود التوكيل والمنطق. كان سبب عدد كبير من الأخطاء المتعلقة بالوكيل عالية الخطورة والتي وجدناها أثناء عمليات التدقيق لدينا هي تعديلات مكتبة الوكيل غير الصحيحة. حادثة أوديوس هي مثال رئيسي على عواقب التعديل غير المناسب لعقود الوكالة.
** النقاط الرئيسية لتشغيل وإدارة عقد الوكالة **
(1) بدء العقد المنطقي
يمكن للمهاجم تولي عقد منطق غير مهيأ وربما يعرض نظام عقد الوكيل للخطر. لذا يرجى تهيئة العقد المنطقي بعد النشر ، أو استخدام \ _disableInitializers () في مُنشئ العقد المنطقي لتعطيل التهيئة تلقائيًا.
(2) التأكد من أمان حساب إدارة الوكيل
يتطلب نظام العقد القابل للترقية دورًا متميزًا "لمسؤول الوكيل" لإدارة ترقيات العقد. إذا تم تسريب مفتاح الإدارة ، يمكن للمهاجم ترقية العقد بحرية إلى عقد ضار ، والذي يمكن أن يسرق أصول المستخدمين. نوصي بإدارة دقيقة للمفاتيح الخاصة لحسابات مسؤول الوكيل لتجنب أي مخاطر محتملة للقرصنة. يمكن استخدام محافظ التوقيع المتعدد لمنع فشل إدارة المفتاح أحادي النقطة.
(3) استخدم حسابًا منفصلاً لإدارة الوكيل الشفافة
يجب أن تكون إدارة الوكيل والحوكمة المنطقية عناوين منفصلة لمنع فقدان التفاعل مع تنفيذ المنطق. إذا كانت إدارة الوكيل والحوكمة المنطقية تشير إلى نفس العنوان ، فلن تتم إعادة توجيه أي مكالمات لأداء وظائف ذات امتياز ، مما يحظر إجراء تغييرات على وظائف الحوكمة.
** متعلق بتخزين عقد الوكيل **
(1) كن حذرًا عند الإعلان عن متغيرات الحالة في عقود التوكيل
كما هو موضح في اختراق Audius ، يجب أن تكون عقود الوكيل حذرة عند الإعلان عن متغيرات الحالة الخاصة بها. يمكن أن تتسبب متغيرات الحالة المعلنة بالطريقة العادية في عقود الوكيل في حدوث تعارض في البيانات عند قراءة البيانات وكتابتها. إذا كان عقد الوكيل يتطلب متغير حالة ، فاحفظ القيمة في فتحة تخزين مثل EIP1967 لمنع التعارضات عند تنفيذ كود العقد المنطقي.
(2) الحفاظ على أمر الإعلان المتغير ونوع العقد المنطقي
يجب أن تحافظ كل نسخة من العقد المنطقي على نفس ترتيب ونوع متغيرات الحالة ، ويجب إضافة متغيرات الحالة الجديدة في نهاية المتغيرات الحالية. خلاف ذلك ، يمكن أن تتسبب مكالمات المفوضين في قراءة عقود الوكيل أو الكتابة فوق القيم المخزنة غير الصحيحة ، وقد ترتبط البيانات القديمة بالمتغيرات المعلنة حديثًا ، مما قد يتسبب في مشاكل خطيرة للتطبيقات.
(3) قم بتضمين فجوات التخزين في العقد الأساسي
تحتاج العقود المنطقية إلى تضمين فجوات التخزين في كود العقد لتوقع متغيرات الحالة الجديدة عند نشر تطبيقات منطقية جديدة. بعد إضافة متغير حالة جديد ، يجب تحديث حجم الفجوة بشكل مناسب.
(4) لا تقم بتعيين قيمة متغير الحالة في عملية الإنشاء أو الإعلان
يؤثر تعيين متغير حالة أثناء الإعلان أو في المنشئ فقط على القيمة في العقد المنطقي ، وليس عقد الوكيل. يجب تعيين المعلمات غير الثابتة باستخدام دالة التهيئة ().
** وراثة العقد **
(1) يمكن أن ترث العقود القابلة للترقية فقط من العقود الأخرى القابلة للترقية
العقود القابلة للترقية لها هيكل مختلف عن العقود غير القابلة للترقية. على سبيل المثال ، المُنشئ غير متوافق مع تغيير حالة الوكيل ، فهو يستخدم وظيفة التهيئة () لتعيين متغيرات الحالة.
يحتاج أي عقد يرث من عقد آخر إلى استخدام وظيفة التهيئة () لعقده الموروث لتعيين المتغيرات الخاصة به. عند استخدام مكتبة OpenZeppelin أو كتابة التعليمات البرمجية الخاصة بك ، تأكد من أن العقود القابلة للترقية يمكنها فقط أن ترث العقود الأخرى القابلة للترقية.
(2) لا تقم بإنشاء عقود جديدة في العقود المنطقية
العقود التي تم إنشاؤها وإنشاء مثيل لها من خلال Solidity لن تكون قابلة للترقية. يجب نشر العقود بشكل فردي وتمرير عنوانها كمعامل لعقد المنطق القابل للترقية لتحقيق حالة قابلة للترقية.
(3) مخاطر بدء عقد الوالدين
عند تهيئة عقد الوالدين ، ستعمل وظيفة \ _ \ _ {ContractName} \ _ init على تهيئة عقد الوالدين. المكالمات المتعددة لـ \ _ \ _ {ContractName} \ _ init قد ينتج عنها تهيئة ثانية لعقد الأصل. لاحظ أن \ _ \ _ {ContractName} \ _ init \ _unchained () سيهيئ فقط معلمات {ContractName} ، ولن يستدعي مُهيئ عقد الأصل الخاص به.
ومع ذلك ، هذه ليست ممارسة موصى بها ، لأن جميع عقود الوالدين تحتاج إلى التهيئة ، وعدم تهيئة العقود المطلوبة سيؤدي إلى مشاكل التنفيذ في المستقبل.
** تنفيذ العقد المنطقي **
** تجنب التدمير الذاتي () أو selegatecall () / call () لعقود غير موثوق بها **
إذا كان هناك إتلاف ذاتي () أو تفويض استدعاء () في العقد ، فمن الممكن للمهاجم استخدام هذه الوظائف لكسر تطبيق المنطق أو تنفيذ منطق مخصص. يجب على المطورين التحقق من صحة إدخال المستخدم وعدم السماح للعقود بتنفيذ استدعاءات التفويض / المكالمات للعقود غير الموثوق بها. أيضًا ، لا يوصى باستخدام devatecall () في العقود المنطقية لأنه سيكون مرهقًا لإدارة تخطيط التخزين في سلسلة المفوضين لعقود متعددة.
** مكتوبة في النهاية **
تتجاوز عقود البروكسي الطبيعة غير القابلة للتغيير لشبكات البلوكشين من خلال تمكين البروتوكولات لتحديث منطق الكود الخاص بها بعد النشر. ومع ذلك ، لا يزال تطوير عقود الوكيل بحاجة إلى توخي الحذر الشديد ، وقد يتسبب التنفيذ غير الصحيح في مشاكل تتعلق بأمان المشروع ومنطقه.
بشكل عام ، تتمثل أفضل الممارسات في استخدام حلول موثوقة ومُختبرة على نطاق واسع ، حيث أثبت كل من أوضاع الوكيل الشفافة و UUPS و Beacon Proxy آليات ترقية مثبتة لحالات الاستخدام الخاصة بكل منها. بالإضافة إلى ذلك ، يجب أيضًا إدارة الأدوار المميزة لعملاء التصعيد بشكل آمن لمنع المهاجمين من تغيير منطق الوكيل.
يجب أن يحرص عقد التنفيذ المنطقي أيضًا على عدم استخدام devatecall () ، والذي يمكن أن يمنع المهاجمين من تنفيذ بعض التعليمات البرمجية الضارة ، مثل selfdestruct ().
بينما يضمن اتباع أفضل الممارسات عمليات نشر ثابتة لعقد الوكيل مع الحفاظ على المرونة القابلة للترقية ، فإن جميع التعليمات البرمجية معرضة لمشاكل أمنية أو منطقية جديدة قد تعرض المشروع للخطر. لذلك ، يتم تدقيق جميع التعليمات البرمجية بشكل أفضل من قبل فريق من خبراء الأمن ذوي الخبرة في تدقيق وتأمين بروتوكولات عقد الوكيل.