فهم عميق لهجمات إعادة الدخول وطرق الحماية الفعّالة

**مقدمة عن هجمات إعادة الدخول**

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

**آلية عمل الهجوم الأساسية**

1. **استدعاء الدالة الأولى**: يقوم العقد بإرسال أموال إلى عنوان خارجي
2. **التنفيذ المعاكس**: يستدعي العنوان الخارجي العقد مرة أخرى قبل تحديث الرصيد
3. **الحلقة المفرغة**: يتكرر هذا حتى تنفد الغاز أو يتم سحب كل الأموال

**أشهر الهجمات التاريخية**

- **هجوم DAO (2016)**: خسارة 50 مليون دولار
- **هجوم Uniswap/Lendf.me**: استخراج أموال باستخدام إعادة دخول معقدة

**طرق الحماية الفعّالة**

**1. نمط Checks-Effects-Interactions (CEI)**
```
- التحقق من الشروط أولاً
- تحديث حالة العقد ثانياً
- التفاعل مع العقود الخارجية أخيراً
```

**2. استخدام Mutex (Reentrancy Guard)**
- إضافة متغير قفل لمنع الاستدعاءات المتزامنة
- OpenZeppelin توفر `ReentrancyGuard`

**3. تحديث الحالة قبل الاستدعاء**
- تغيير الأرصدة المحفوظة قبل إرسال الأموال
- يضمن عدم تكرار السحب

**4. استخدام الدوال الآمنة**
- استبدال `call()` بـ `transfer()` أو `send()`
- توفير حد أقصى من الغاز

**5. الاختبار الشامل**
- اختبار جميع سيناريوهات إعادة الدخول
- استخدام أدوات التحليل الثابتة

**أفضل الممارسات**

✓ تصميم العقود بأسلوب دفاعي
✓ استخدام معايير معروفة مثل OpenZeppelin
✓ إجراء عمليات تدقيق الأمان المتخصصة
✓ اختبار المحاكاة على الشبكات الاختبارية
✓ تطبيق التأمين على الأموال الضخمة

**الخلاصة**

الحماية من هجمات إعادة الدخول تتطلب فهماً عميقاً للآلية وتطبيق معايير أمان صارمة في جميع مراحل التطوير.

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

للحصول على صورة كاملة، سنبدأ بالمفاهيم الأساسية، ثم نحلل شفرة المصادر لهجمات حقيقية، وأخيرًا نستكشف ثلاثة تقنيات مثبتة للوقاية: من modifier nonReentrant() إلى GlobalReentrancyGuard() ونموذج التحقق-تأثير-تفاعل.

ما هو نوع هجوم إعادة الدخول؟

تخيل عقدين ذكيين يتفاعلان مع بعضهما البعض. ContractA و ContractB يمكنهما استدعاء بعضهما البعض بشكل كامل. يبدو ذلك طبيعيًا، لكنه في الواقع ثغرة يمكن للمهاجم استغلالها.

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

لتوضيح ذلك، انظر إلى الحالة التالية: ContractA يحتفظ بـ 10 إيثريوم، و ContractB أرسل إليه 1 إيثريوم. بشكل طبيعي، عندما يطلب ContractB سحب الأموال، يتم التحقق (الرصيد > 0)، ثم يتم استلام الإيثريوم، ويتم تعيين الرصيد إلى 0. لكن مع إعادة الدخول، يمكن تكرار هذه العملية عدة مرات قبل تحديث الرصيد.

آلية عمل هجوم إعادة الدخول

المهاجم يحتاج إلى عنصرين رئيسيين: دالة attack() ودالة fallback().

دالة fallback هي دالة خاصة في Solidity — دالة خارجية بدون اسم، بدون معلمات، وبدون قيمة إرجاع. يتم تفعيلها تلقائيًا عندما:

• يستدعي أحدهم دالة غير موجودة في العقد
• يتم إرسال بيانات إلى العقد بدون تحديد دالة
• يتم تحويل إيثريوم إلى العقد بدون بيانات

الآن، تابع كيف يتم تنفيذ الهجوم خطوة بخطوة:

الخطوة 1: المهاجم يستدعي attack()، التي تستدعي سحب الأموال من ContractA.

الخطوة 2: ContractA يتحقق مما إذا كان رصيد ContractB أكبر من 0. إذا كان كذلك، يرسل 1 إيثريوم إلى ContractB ويشغل دالة fallback.

الخطوة 3: هنا النقطة الحرجة — لم يتم تحديث الرصيد بعد. ContractA لا زال ينفذ كود سحب.

الخطوة 4: يتم تفعيل دالة fallback وتستدعي على الفور سحب الأموال مرة أخرى من ContractA.

الخطوة 5: ContractA يتحقق مرة أخرى — رصيد ContractB لا زال 1 إيثريوم (لأن التحديث لم يحدث بعد). يرسل إيثريوم آخر ويشغل fallback مرة أخرى.

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

تحليل شفرة الهجوم بالتفصيل

لفهم الأمر بشكل أعمق، لننظر إلى مثال محدد مع عقد EtherStore. هذا العقد يحتوي على دالتين رئيسيتين:

• deposit(): يخزن ويحدث رصيد المرسل
• withdrawAll(): يسحب كل الرصيد دفعة واحدة

دالة withdrawAll() تتبع الترتيب: التحقق (الرصيد > 0)، إرسال الإيثريوم، ثم تعيين الرصيد إلى 0.

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

تم تصميم عقد Attack لاستغلال ذلك. يحتوي على:

• منشئ (constructor) يأخذ عنوان EtherStore
• دالة fallback() تعيد استدعاء withdrawAll() طالما هناك إيثريوم
• دالة attack() لبدء الهجوم

عملية الهجوم بسيطة:

1. المهاجم يستدعي attack() مع إيثريوم كافٍ
2. attack() يرسل 1 إيثريوم إلى EtherStore لخلق رصيد > 0
3. attack() يستدعي withdrawAll() من EtherStore
4. EtherStore يرسل 1 إيثريوم → يُشغل fallback الخاص بـ Attack
5. fallback يعيد استدعاء withdrawAll() لأن الرصيد لم يُحدث بعد
6. تتكرر الحلقة حتى ينفد Ether من EtherStore

ثلاثة تقنيات للوقاية من هجمات إعادة الدخول

التقنية 1: استخدام Modifier nonReentrant

أسهل طريقة لحماية دالة واحدة هي استخدام modifier nonReentrant. الـ modifier هو نوع خاص من الدوال في Solidity يضيف شروط أو وظائف إضافية إلى دوال أخرى دون إعادة كتابة المنطق بالكامل.

كيفية عمل nonReentrant:

• يقفل العقد عند بدء تنفيذ الدالة
• أي استدعاء رجعي خلال ذلك يُرفض
• يُفتح القفل فقط عند اكتمال الدالة

العيب: nonReentrant يحمي دالة واحدة فقط، ولا يمنع هجمات إعادة الدخول بين دوال مختلفة.

التقنية 2: نموذج Check-Effect-Interaction

هذه طريقة أكثر تطورًا لحماية عدة دوال. بدلاً من قفل العقد، تغير ترتيب تنفيذ الكود.

يجب أن يتبع هذا النموذج:

• Check (التحقق): التحقق من جميع الشروط مسبقًا (require)
• Effect (التأثير): تحديث الحالة فورًا
• Interaction (التفاعل): استدعاء العقود الخارجية أو إرسال الإيثريوم في النهاية

مقارنة بين الكود المعرض للهجوم والكود الآمن:

• عرضة للهجوم: التحقق → إرسال الإيثريوم → تحديث الرصيد (الثغرة بين الإرسال والتحديث)
• آمن: التحقق → تحديث الرصيد → إرسال الإيثريوم

بوضع تحديث الرصيد بعد التحقق، تضمن أن أي استدعاء رجعي سيجد الرصيد محدثًا، مما يُعطل الهجوم.

التقنية 3: GlobalReentrancyGuard للمشاريع متعددة العقود

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

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

• بالتحكم في إعادة الدخول بين العقود المختلفة
• بتجنب هجمات chain-reentrancy المعقدة

مثال عملي: إذا أرسل ScheduledTransfer إيثريوم إلى AttackTransfer، ودالة fallback في AttackTransfer تحاول استدعاء دوال أخرى في ScheduledTransfer، فإن GlobalReentrancyGuard يكتشف ويمنع ذلك.

اختيار التقنية المناسبة للوقاية

استخدام nonReentrant عندما:

• تحتاج فقط لحماية دالة أو دوال قليلة
• لا يهم تكلفة التنفيذ الزائدة
• لا تحتاج إلى حماية بين دوال متعددة

استخدام Check-Effect-Interaction عندما:

• تريد تحسين كفاءة استهلاك الغاز
• لديك العديد من الدوال التي تحتاج حماية
• تريد تطبيق أفضل الممارسات على كامل المشروع

استخدام GlobalReentrancyGuard عندما:

• مشروعك يتضمن أنظمة عقود معقدة
• تتفاعل العقود بشكل متكرر
• تحتاج إلى طبقة حماية مركزية موحدة

أفضل نهج هو الجمع بين هذه التقنيات حسب الحاجة في أجزاء مختلفة من مشروعك.

الخلاصة

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

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

لمتابعة آخر أخبار أمان Web3، Solidity، فحص العقود الذكية، والمسائل ذات الصلة، تابع @TheBlockChainer على تويتر.