ما هي الثغرات الأمنية الشائعة في جسور الربط بين السلاسل؟

ملخص

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

مقدمة

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

الجسر blockchain هو الأساس لتحقيق التفاعل بين سلاسل الكتل في مجال blockchain. فهي تستخدم أنواعًا مختلفة من التحقق على السلسلة وخارجها، وبالتالي قد تكون عرضة لثغرات أمنية مختلفة.

لماذا يعتبر أمان جسور blockchain مهمًا جدًا؟

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

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

وفقًا لتقديرات CertiK، في عام 2022، تسببت هجمات جسور blockchain في خسائر تزيد عن 1.3 مليار دولار، وهو ما يمثل 36٪ من إجمالي الخسائر في ذلك العام.

الثغرات الأمنية الشائعة في الربط بين السلاسل

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

عدم كفاية التحقق على السلسلة

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

أما الأنواع الأخرى من الجسور فتستخدم العقود الذكية للتحقق من الرسائل وإجراء التحقق على السلسلة. في هذه الحالة، عندما يُودع المستخدم أمواله على السلسلة، يقوم العقد الذكي بإنشاء رسالة موقعة وإرجاع التوقيع في المعاملة. يُستخدم هذا التوقيع كدليل على الإيداع، للتحقق من طلب سحب المستخدم على سلسلة أخرى. يجب أن تمنع هذه العملية جميع أنواع الهجمات الأمنية، بما في ذلك هجمات إعادة التشغيل وتزوير سجلات الإيداع.

ومع ذلك، إذا كانت عملية التحقق على السلسلة تحتوي على ثغرات، فقد تتسبب في خسائر كبيرة. على سبيل المثال، إذا استخدم blockchain شجرة ميركل للتحقق من سجلات المعاملات، يمكن للمهاجم إنشاء إثبات مزور. هذا يعني أنه إذا كانت عملية التحقق تحتوي على ثغرة، يمكن للمهاجم تجاوز التحقق من الإثبات، وإنشاء رموز جديدة في حسابه.

بعض جسور blockchain تنفذ مفهوم “الرموز المغلفة(wrapped tokens)”، على سبيل المثال، عندما ينقل المستخدم DAI من إيثريوم إلى BNB Chain، يتم سحب DAI من عقد إيثريوم، ويتم إصدار DAI مغلف بمقدار مماثل على BNB Chain.

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

كما يحتاج المهاجم إلى أن يوافق الضحية مسبقًا على عقد جسر الربط بين السلاسل، لاستخدام وظيفة “TransferFrom” لنقل الرموز، وسرقة الأصول من عقد الجسر.

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

عدم كفاية التحقق خارج السلسلة

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

يعمل جسر الربط بين السلاسل الذي يعتمد على التحقق خارج السلسلة على النحو التالي:

• يتفاعل المستخدم مع dApp، ويودع الرموز في عقد ذكي على السلسلة المصدر.

• ثم يرسل dApp عبر API هاش المعاملة إلى الخادم الخلفي.

• يحتاج هاش المعاملة إلى التحقق عدة مرات من قبل الخادم. إذا اعتُبر شرعيًا، يوقع الموقع رسالة، ويعيد التوقيع إلى واجهة المستخدم عبر API.

• بعد استلام التوقيع، يتحقق منه dApp، ويسمح للمستخدم بسحب الرموز من السلسلة الهدف.

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

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

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

المعالجة غير الصحيحة للعملة الأصلية

تستخدم جسور الربط بين السلاسل طرقًا مختلفة لمعالجة العملات الأصلية والعملات ذات الوظائف. على سبيل المثال، على شبكة إيثريوم، العملة الأصلية هي ETH، ومعظم العملات ذات الوظائف تتوافق مع معيار ERC-20.

إذا كان المستخدم يخطط لنقل ETH إلى سلسلة أخرى، يجب أن يودعها أولاً في عقد جسر الربط بين السلاسل. لهذا، يكفي أن يرفق ETH في المعاملة، ويستطيع استرداد كمية ETH عبر قراءة حقل “msg.value” في المعاملة.

الفرق كبير بين إيداع رموز ERC-20 و ETH. لإيداع رموز ERC-20، يجب على المستخدم أن يسمح لعقد جسر الربط باستخدام رموزه أولاً. بعد أن يوافق ويودع الرموز في عقد الجسر، يقوم العقد باستخدام وظيفة “burnFrom(@” أو “transferFrom)@” بحرق رموز المستخدم أو نقلها إلى العقد.

لتحديد نوع العملية، يمكن استخدام جملة if-else في نفس الوظيفة، أو إنشاء وظيفتين منفصلتين لكل سيناريو. نظرًا لاختلاف طريقة المعالجة، إذا حاول المستخدم استخدام وظيفة إيداع ERC-20 لإيداع ETH، فقد تفقد ETH.

عند معالجة طلبات إيداع ERC-20، عادةً ما يُمرر عنوان الرمز المميز كوسيط إدخال إلى وظيفة الإيداع. هذا يشكل خطرًا كبيرًا، لأنه قد يحدث استدعاء خارجي غير موثوق خلال المعاملة. من الممارسات الشائعة تقنين قائمة بيضاء تحتوي على الرموز المدعومة من قبل جسر الربط، بحيث يتم تمرير عناوين الرموز فقط من خلال القائمة البيضاء. هذا يمنع الاستدعاءات الخارجية، لأن فريق المشروع قام بفلترة عناوين الرموز.

لكن، عند معالجة نقل العملات الأصلية عبر الجسر، هناك مشكلة، لأنها لا تملك عنوانًا. يمكن تمثيل العملات الأصلية بعنوان خاص، وهو “العنوان الصفري”(0x000… 0). لكن، إذا لم يتم تنفيذ التحقق من القائمة البيضاء بشكل صحيح، فإن تمرير العنوان الصفري إلى الوظيفة قد يتجاوز التحقق من القائمة البيضاء.

عندما ينفذ عقد جسر الربط عملية “TransferFrom” لنقل أصول المستخدم إلى العقد، فإن استدعاء العنوان الصفري الخارجي يرجع بقيمة false، لأنه لا يوجد وظيفة “transferFrom” في العنوان الصفري. لكن، إذا لم يعالج العقد القيمة المرجعة بشكل صحيح، قد تستمر المعاملة، مما يتيح للمهاجم فرصة لتنفيذ المعاملة دون نقل رموز إلى العقد.

خطأ في التكوين

في معظم جسور blockchain، هناك دور ذو صلاحية مسؤول عن إضافة الرموز والعناوين إلى القائمة البيضاء أو السوداء، وتعيين أو تغيير الموقعين، وإعدادات أخرى مهمة. من الضروري أن تكون جميع التكوينات دقيقة، لأن الإهمال البسيط قد يؤدي إلى خسائر كبيرة.

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

كيفية تعزيز أمان جسور الربط بين السلاسل

الثغرات الأربعة الشائعة التي تم ذكرها تشير إلى أن التحديات الأمنية في نظام blockchain المترابط ليست بسيطة. لمواجهة هذه الثغرات، من الضروري “الاعتبار من الحالة إلى الحالة”، ولا يوجد طريقة واحدة يمكنها أن تغطي جميع الثغرات بشكل كامل.

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

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

الخاتمة

نظرًا لحجم الأموال الكبيرة، لطالما كانت جسور الربط بين السلاسل هدفًا للمهاجمين. يمكن للمطورين تعزيز أمان جسور الربط بين السلاسل من خلال إجراء اختبارات شاملة قبل النشر، وإشراك مراجعات من طرف ثالث، مما يقلل من مخاطر الهجمات القاتلة التي شهدتها السنوات الأخيرة. تعتبر جسور الربط بين السلاسل ضرورية في عالم متعدد السلاسل، ولكن عند تصميم وبناء بنية Web3 فعالة، يجب أن يكون الأمان أولوية قصوى. ($STO