تحليل متعمق لهجوم حجب الخدمة في العقود الذكية

هجوم حجب الخدمة(DoS)قد يؤدي إلى عدم إمكانية استخدام العقود الذكية بشكل طبيعي مؤقتاً أو دائماً. تشمل الأسباب الرئيسية ما يلي:

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

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

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

下面结合具体例子分析هجوم حجب الخدمة漏洞:

1. استعراض الهياكل البيانية الكبيرة القابلة للتغيير من قبل الخارج

以下 هو عقد بسيط "لتوزيع الأرباح" للمستخدمين:

صدأ #[near_bindgen] #[derive(BorshDeserialize ، BorshSerialize)] عقد بنية pub { الحانة المسجلة: Vec ، حسابات pub: UnorderedMap<accountid, balance="">, }

pub fn register_account(&mut self) { إذا كان self.accounts.insert(&env::p redecessor_account_id(), &0).is_ some() { env::panic("الحساب مسجل بالفعل".to_string().as_bytes()); } else { self.registered.push(env::p redecessor_account_id()); } log!("حساب مسجل {}", env::p redecessor_account_id()); }

pub fn distribute_token(& mut self, amount: u128) { assert_eq!(env::p redecessor_account_id(), DISTRIBUTOR, "ERR_NOT_ALLOWED");

ل cur_account في self.registered.iter() {
    Let balance = self.accounts.get(&cur_account).expect("ERR_GET");
    self.accounts.insert(&cur_account, &balance.checked_add(amount).expect("ERR_ADD" ));
    log!("حاول التوزيع إلى الحساب {}", &cur_account);
    ext_ft_token::ft_transfer(
        cur_account.clone(),
        المبلغ،
        و FTTOKEN ،
        0,
        GAS_FOR_SINGLE_CALL
    );
}

}

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

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

!

2. الاعتماد على حالة العقود المتعددة يؤدي إلى الانسداد

افترض سيناريو عقد مزايدة:

صدأ #[near_bindgen] #[derive(BorshDeserialize ، BorshSerialize)] عقد بنية pub { الحانة المسجلة: Vec ، pub bid_price: UnorderedMap<accountid,balance>, pub current_leader: AccountId ، أعلى_عرض: u128, استرداد الحانة: بول }

pub fn bid(&mut self, sender_id: AccountId, amount: u128) -> PromiseOrValue { أكد!(amount > self.highest_bid); إذا كانت القيادة الحالية هي DEFAULT_ACCOUNT { self.current_leader = sender_id ؛ self.highest_bid = المبلغ ؛ } else { ext_ft_token::account_exist( self.current_leader.clone(), و FTTOKEN ، 0, env::p repaid_gas() - GAS_FOR_SINGLE_CALL * 4, ).then(ext_self::account_resolve( sender_id، المبلغ, &env::current_account_id(), 0, GAS_FOR_SINGLE_CALL * 3 ، )); } سجل!( "current_leader: {} highest_bid: {}", الزعيم الحالي الخاص به، self.highest_bid ); PromiseOrValue::Value(0) }

#[private] pub fn account_resolve(&mut self, sender_id: AccountId, amount: u128) { مطابقة ENV::p romise_result(0) { PromiseResult::NotReady => غير قابل للوصول!(), PromiseResult::Successful(_) => { ext_ft_token::ft_transfer( self.current_leader.clone(), self.highest_bid، و FTTOKEN ، 0, GAS_FOR_SINGLE_CALL * 2 ، ); self.current_leader = sender_id ؛ self.highest_bid = المبلغ ؛ } PromiseResult::Failed = > { ext_ft_token::ft_transfer( sender_id.clone(), المبلغ, و FTTOKEN ، 0, GAS_FOR_SINGLE_CALL * 2 ، ); log!("العودة الآن"); } }; }

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

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

3. فقدان المفتاح الخاص للمالك

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

يوصى باستخدام آلية التوقيع المتعدد بدلاً من التحكم في صلاحيات مالك واحد، لتحقيق الحوكمة اللامركزية.

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

! </accountid,balance>< / accountid ، >