تحليل ثغرات هجمات DoS في العقود الذكية باستخدام Rust

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

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

2. الاعتماد على حالة تنفيذ العقود الخارجية عند استدعاء العقود المتعددة. قد تؤدي موثوقية تنفيذ العقود الخارجية المنخفضة إلى حظر هذا العقد.

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

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

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");

لكل حساب حالي في 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 بسبب تجاوز استهلاك الغاز للحد.

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

!

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

فكر في عقد "المزايدة":

صدأ #[near_bindgen] #[derive(BorshDeserialize ، BorshSerialize)] عقد بنية pub { الحانة المسجلة: Vec ، pub bid_price: UnorderedMap<accountid,balance>, pub current_leader: AccountId ، حانة highest_bid: 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.current_leader،
    self.highest_bid
);

PromiseOrValue::Value(0)

}

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

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

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

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

طريقة الحل:

• تعيين عدة مالكين للحكم المشترك
• اعتماد خطة توقيع متعدد بدلاً من التحكم في صلاحيات مالك واحد
• تحقيق آلية الحكم اللامركزي

يمكن أن يؤدي تصميم الصلاحيات المعقول وآلية الحوكمة إلى تقليل مخاطر نقطة الفشل الواحدة بشكل فعال وزيادة متانة العقود.

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