Akıllı sözleşmelerde hizmet reddi saldırısı analizi

hizmet reddi saldırısı(DoS)akıllı sözleşmelerin bir süre boyunca hatta kalıcı olarak düzgün bir şekilde kullanılamamasına neden olabilir. Ana nedenler şunlardır:

1. Akıllı sözleşmelerdeki mantık hataları, bazı açık işlevlerin hesaplama karmaşıklığının çok yüksek olması, Gas tüketiminin sınırları aşmasına neden olur.

2. Akıllı sözleşmeler arası çağrılarda, dış sözleşmelerin yürütme durumuna bağımlılık, dış sözleşmelerin güvenilir olmayan bir şekilde çalışması bu sözleşmenin normal işleyişini engelleyebilir.

3. İnsan faktörleri, örneğin sözleşme sahibinin özel anahtarını kaybetmesi nedeniyle bazı ayrıcalıklı işlevlerin çağrılamaması.

Aşağıda, akıllı sözleşmelerdeki DoS saldırı açığını somut örneklerle analiz edeceğiz.

1. Dışarıdan değiştirilebilen büyük veri yapılarının döngüsel olarak gezilmesi

Aşağıda kayıtlı kullanıcılara "kar payı" vermek için basit bir akıllı sözleşme bulunmaktadır:

pas #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] pub struct Sözleşme { pub kayıtlı: Vec\u003caccountid\u003e, pub hesaplar: UnorderedMap<accountid, balance="">, }

pub fn register_account(&mut self) { eğer self.accounts.insert(&env::predecessor_account_id(), &0).is_some() { env::panic('Hesap zaten kayıtlıdır'.to_string().as_bytes()); }else{ self.registered.push(env::predecessor_account_id()); } log!('Kayıtlı hesap{}',env::predecessor_account_id()); }

pub fn distribute_token(&mut self, amount: u128) { assert_eq!(env::predecessor_account_id(),DISTRIBUTOR,'ERR_NOT_ALLOWED'); for cur_account in 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!('Try distribute to account{}',&cur_account); ext_ft_token::ft_transfer( cur_account.clone(), miktar, &FTTOKEN, 0, TEKÇAĞRI İÇİN GAZ ); } }

Sözleşmenin sorunu, self.registered dizisinin boyutunun sınırlı olmamasıdır; kötü niyetli kullanıcılar tarafından manipüle edilerek çok büyük hale getirilebilir ve bu da distribute_token fonksiyonu çalıştırıldığında Gas tüketiminin sınırları aşmasına yol açar.

Önerilen çözümler:

1. self.registered dizisinin maksimum uzunluğunu sınırlayın
2. Çekim modunu benimseyin, ödülleri aktif olarak dağıtmak yerine kullanıcıların çekim fonksiyonunu kendilerinin çağırmalarına izin verin.

2. Sözleşmeler arası durum bağımlılığı sözleşmelerin bloke olmasına neden olur

Bir "teklif" aklı sözleşmesi düşünün:

pas #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] pub struct Sözleşme { pub kayıtlı: Vec, pub bid_price: UnorderedMap<accountid,balance>, mevcut_lider: HesapId, en yüksek teklif: u128, pub iade: bool }

PromiseOrValue { assert!(miktar > self.en yüksek teklif); eğer self.current_leader == DEFAULT_ACCOUNT { self.current_leader = sender_id; self.highest_bid = miktar; } else { ext_ft_token::account_exist( self.current_leader.clone)(, &FTTOKEN, 0, env::ödenmiş_gas() - TEK_AĞRI_CALL * 4, (.then)ext_self::account_resolve) gönderici_id, miktar, &env::current_account_id((, 0, GAS_FOR_SINGLE_CALL * 3, (); } log!) 'mevcut_lider: {} en_yüksek_teklif: {}', self.current_leader, self.highest_bid ); PromiseOrValue::Value(0) }

#( pub fn account_resolve)\u0026mut self,sender_id: AccountId,amount: u128[private] { eşleşme env::promise_result(0) { PromiseResult::NotReady => ulaşılamaz!(), PromiseResult::Başarılı(_) => { 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.en yüksek teklif = miktar; } PromiseResult::Başarısız => { ext_ft_token::ft_transfer) sender_id.clone)(, miktar, &FTTOKEN, 0, GAS_FOR_SINGLE_CALL * 2, (; log!)'Şimdi Geri Dön'); } }; }

Sözleşmenin sorunu, eğer mevcut en yüksek teklif veren kullanıcının hesabı dış token sözleşmesinde iptal edilirse, yeni daha yüksek teklifin önceki tokeni iade edemeyeceği ve bu durumun açık artırma sürecini engelleyeceğidir.

Çözüm:

Dış sözleşme çağrılarının başarısız olabileceği durumları dikkate alarak, makul hata yönetimi uygulayın. Örneğin, geri alınamayan tokenleri sözleşmede geçici olarak saklayın, daha sonra kullanıcıların kendilerinin çekmelerine izin verin.

3. Sözleşme sahibinin özel anahtarının kaybolması

Akıllı sözleşmelerde genellikle yalnızca sahibi tarafından çalıştırılabilen ayrıcalıklı fonksiyonlar bulunur. Eğer sahibin özel anahtarı kaybolursa, bu fonksiyonlar çağrılamayacak ve sözleşmenin düzgün çalışmamasına neden olabilir.

Çözüm:

1. Birden fazla sözleşme sahibini ortak yönetime ayarlayın
2. Tek bir sahip yetki kontrolü yerine çoklu imza mekanizması kullanılması
3. Merkeziyetsiz sözleşme yönetim çözümü gerçekleştirme

\u003c/u128\u003e\u003c/accountid,balance\u003e\u003c/accountid\u003e\u003c/accountid,\u003e\u003c/accountid\u003e