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

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

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

2. في استدعاء العقود المتعددة، يعتمد تنفيذ العقد على حالة العقد الخارجي، وقد يتم حظره بواسطة العقد الخارجي.

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

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

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

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

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

impl عقد { 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()، الموزع، "غير مصرح له بالعمل" )؛
    للحساب في self.registered.iter() {
        Let balance = self.accounts.get(&account).expect("Get failed");
        self.accounts.insert(&account, &balance.checked_add(amount).expect( "تجاوز الإضافة" )); 
        log!("حاول توزيع إلى الحساب {}", &account);
        ext_ft_token::ft_transfer(
            account.clone() ،
            المبلغ,
            و FTTOKEN ،
            0,
            GAS_FOR_SINGLE_CALL
        );
    }
}

}

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

التوصيات للحلول:

إعادة بناء العقد باستخدام وضع السحب. السماح للمستخدمين باستدعاء دالة السحب بنشاط للحصول على المكافآت، والعقد يحتاج فقط إلى تسجيل مبلغ المكافآت القابلة للسحب للمستخدم.

!

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

اعتبر عقد مزايدة:

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

impl العقد { pub fn bid(&mut self, sender_id: AccountId, amount: u128) -> PromiseOrValue { أكد!(amount > self.highest_bid); إذا كان زعيمنا الحالي == الحساب الافتراضي { 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 ، )); } سجل!( "أعلى مزايد حالي: {} أعلى مزايدة: {}",} self.current_leader، 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!("إرجاع العرض الحالي");
        }
    };
}

}

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

طريقة الحل:

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

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

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

حلول:

إعداد عدة مالكي عقود للحكم الجماعي، أو اعتماد آلية متعددة التوقيعات بدلاً من التحكم في الصلاحيات من قبل مالك واحد، لتحقيق الحكم اللامركزي.

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