هجوم إعادة التشغيل

ما هو هجوم إعادة التشغيل؟

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

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

لتجنّب التكرار، تستخدم شبكات البلوكشين معرفًا فريدًا يُسمى Nonce، وهو بمثابة رقم تسلسلي لكل عملية لا يتكرر أبدًا. يقبل النظام فقط الـ Nonce غير المستخدم.

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

لماذا تحدث هجمات إعادة التشغيل؟

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

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

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

كيف تُنفذ هجمات إعادة التشغيل على البلوكشين؟

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

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

على طبقة العقد الذكي، إذا لم تتتبع العقود معرفات الرسائل المعالجة أو تفتقر للخاصية Idempotency (أي أن التكرار يؤدي إلى آثار تراكمية)، يمكن للمهاجمين تنفيذ العمليات عدة مرات بينما كان المقصود تنفيذها مرة واحدة فقط.

أمثلة واقعية لهجمات إعادة التشغيل

في عام 2016، شهدت شبكة Ethereum انقسامًا نتج عنه ETH وETC. ولأن المعاملات الأولى لم تميز بين السلاسل، ظهرت مخاطر إعادة التشغيل عبر السلاسل. تم تقديم EIP-155 في 2016 لإضافة chainId إلى المعاملات، مما قلل بشكل كبير من هذه الهجمات (المرجع: تاريخ اقتراح تحسين Ethereum).

في سيناريوهات التفويض، إذا كانت الموافقات القائمة على التوقيع لتحويلات أو حدود الإنفاق تفتقر إلى تاريخ انتهاء الصلاحية وNonce فريدة، يمكن إعادة تقديم التوقيعات. تم تقديم EIP-2612 في 2020 لتوحيد التفويضات القائمة على التوقيع لرموز ERC-20، مع اشتراط وجود Nonce وتاريخ انتهاء الصلاحية (المرجع: اقتراح تحسين Ethereum).

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

كيف تكتشف إشارات هجوم إعادة التشغيل؟

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

بعد ذلك، تحقق مما إذا كان التفويض يتضمن تاريخ انتهاء الصلاحية وNonce فريدة. غياب أي منهما يزيد من تعرضك للخطر.

تحقق من وجود سياق السلسلة بشكل صريح. غياب chainId أو فصل المجال (كما في مجالات EIP-712) يزيد من خطر إعادة التشغيل عبر بيئات مختلفة.

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

إجراءات تقنية للدفاع ضد هجمات إعادة التشغيل

الخطوة 1: اربط المعاملات بسياق السلسلة الخاص بها. استخدم chainId في EIP-155 لتقييد كل معاملة بالسلسلة المقصودة ومنع إعادة التشغيل عبر السلاسل.

الخطوة 2: خصص Nonce فريدة ووقت انتهاء صلاحية لكل تفويض. تتطلب المعايير مثل EIP-2612 وPermit2 أن يتضمن كل توقيع Nonce وموعد نهائي؛ تصبح التفويضات المنتهية الصلاحية غير صالحة.

الخطوة 3: سجّل الرسائل أو الـ Nonce "المستخدمة" في العقود الذكية. يجب أن يكون لكل رسالة معرف غير قابل لإعادة الاستخدام وحالة استهلاكها مخزنة على السلسلة للمعالجة Idempotent.

الخطوة 4: استخدم التوقيعات المنظمة وفقًا لـ EIP-712. يجب أن تتضمن التوقيعات اسم المجال (verifyingContract, name, version)، chainId، ومحتوى واضح وسهل القراءة لتقليل فرص سوء الاستخدام وإعادة التشغيل.

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

كيف يتجنّب المستخدمون هجمات إعادة التشغيل في العمليات اليومية؟

الخطوة 1: وقّع فقط على واجهات تعرض تفاصيل نصية واضحة. ارفض التوقيعات العمياء، وتأكد من أن الرسالة تحتوي على معلومات المجال، السلسلة، ووصف الغرض.

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

الخطوة 3: افصل الأموال عن المحافظ التشغيلية. خزّن الأصول الأساسية في محافظ الأجهزة أو محافظ المشاهدة فقط، وتفاعل مع DApps باستخدام محافظ ساخنة صغيرة لتقليل الخسائر الناتجة عن التفويضات المتكررة.

الخطوة 4: استخدم دفاتر العناوين والقوائم البيضاء. احفظ عناوين المستلمين المتكررة مع ملاحظات في دفتر عناوين Gate وفعّل قوائم السحب البيضاء لتقليل المخاطر الناتجة عن الأخطاء أو توقيعات التصيد التي تؤدي إلى تكرار الإرسال.

الخطوة 5: راقب النشاط غير الطبيعي. إذا لاحظت معاملات أو تفويضات مكررة في فترة قصيرة، أوقف العمليات فورًا، وألغِ التفويضات، وتحقق من أمان الجهاز والإضافات.

كيف يختلف هجوم إعادة التشغيل عن الإنفاق المزدوج أو هجوم Sybil؟

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

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

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

كيف تتطور هجمات إعادة التشغيل في Web3؟

منذ تقديم chainId في EIP-155 عام 2016، انخفضت هجمات إعادة التشغيل عبر السلاسل بشكل حاد؛ كما أن EIP-2612 (2020) وPermit2 عززت آليات الـ Nonce وتاريخ الانتهاء في الموافقات القائمة على التوقيع. وبحلول عام 2025، مع انتشار الشبكات متعددة السلاسل وطبقة الثانية، أصبحت قنوات الرسائل، ومعرفات مكافحة إعادة التشغيل، وتصميم Idempotent من البنى التحتية الأساسية.

يدعم التجريد الحسابي (مثل ERC-4337) إدارة الـ Nonce حسب المجال والاستراتيجيات، حيث يقلل استخدام Nonce مميزة للعمليات المختلفة من خطر إعادة التشغيل داخل المجال الواحد. تركز الجسور عبر السلاسل الآن على التحقق من المصدر وتتبع الرسائل الفريدة للحد من فرص التنفيذ المتكرر.

ملخص هجوم إعادة التشغيل والإجراءات الموصى بها

جوهر هجوم إعادة التشغيل هو "تنفيذ محتوى صالح في سياق خاطئ." الحل يكمن في توضيح السياق: معرفات السلاسل، Nonce فريدة، أوقات انتهاء الصلاحية، ربط المجال، وتسجيل الحالات المستهلكة دائمًا على السلسلة. للمطورين: اعتمد معايير EIP-155، EIP-712، EIP-2612/Permit2 مع تصميم Idempotent. للمستخدمين: تجنب التوقيعات العمياء، استخدم تفويضات محددة بوقت، افصل المحافظ حسب الوظيفة، وفعّل قوائم بيضاء في المنصات لتقليل المخاطر. إذا لاحظت تكرارًا غير طبيعي للأموال، أوقف العمليات فورًا وألغِ التفويضات.

الأسئلة الشائعة

هل يمكن أن تتسبب هجمات إعادة التشغيل في فقدان أصولي؟

لا تسرق هجمات إعادة التشغيل أصولك بشكل مباشر، لكنها قد تؤدي إلى معاملات متكررة خبيثة. على سبيل المثال، إذا حولت ١٠٠ رمز على السلسلة A وأعاد المهاجم تنفيذ تلك المعاملة على السلسلة B، قد تخسر أموالًا على كلتا السلسلتين. الدفاع الأساسي هو استخدام محافظ تدعم التحقق من chain ID وتوخي الحذر الشديد أثناء العمليات عبر السلاسل.

هل يجب أن أقلق من هجمات إعادة التشغيل عند التداول على Gate؟

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

هل يمكن أن تؤدي أحداث كبيرة مثل اندماج Binance إلى هجمات إعادة تشغيل واسعة النطاق؟

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

إذا تم تسريب المفتاح الخاص الخاص بي، هل تزيد هجمات إعادة التشغيل من الخسائر؟

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

كيف يساعد EIP-155 في منع هجمات إعادة التشغيل؟

قدم EIP-155 آلية معرف السلسلة بحيث تحمل كل معاملة معرف شبكة فريد، مما يمنع تنفيذها على سلاسل أخرى. اعتمدت جميع شبكات Ethereum الحديثة والسلاسل المتوافقة هذا المعيار، مما جعل معظم هجمات إعادة التشغيل غير ممكنة. اختيار محفظة تدعم EIP-155 هو أبسط وسيلة لحماية المستخدمين لأنفسهم.