Rust akıllı sözleşmelerde hizmet reddi saldırısı

hizmet reddi saldırısı(DoS)akıllı sözleşmelerin bir süre boyunca hatta kalıcı olarak normal çalışamaz hale gelmesine neden olabilir. Başlıca sebepler şunlardır:

1. Sözleşme mantığında yüksek hesaplama karmaşıklığına sahip bir kusur var, bu da Gas tüketiminin sınırı aşmasına neden oluyor.

2. Akıllı sözleşmeler arası çağrılar sırasında, sözleşme yürütmesi dışarıdan güvenilir olmayan sözleşmelere bağımlıdır ve bu durum tıkanmalara yol açar.

3. Sözleşme sahibinin özel anahtarını kaybetmesi, ayrıcalıklı işlevleri güncelleyerek önemli durumu gerçekleştiremeyeceği anlamına gelir.

Aşağıda somut örnekler üzerinden hizmet reddi saldırısı açığını analiz edeceğiz.

1. Dışarıdan kontrol edilebilen büyük veri yapılarının gezinilmesi

Aşağıda kullanıcılara "temettü" veren basit bir 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ı".to_string().as_bytes()); } else { self.registered.push(env::predecessor_account_id()); }
log!("Kayıtlı hesap {}", env::önceki_hesap_id()); }

pub fn distribute_token(&mut self, amount: u128) { assert_eq!(env::predecessor_account_id(), DAĞITICI, "ERR_NOT_ALLOWED"); for cur_account in self.registered.iter() { let balance = self.accounts.get(&cur_account).expect("ERR_GET"); self.accounts.insert(\u0026cur_account, \u0026balance.checked_add(amount).expect("ERR_ADD")); log!("Hesaba {} dağıtmaya çalışın", &cur_account); ext_ft_token::ft_transfer( cur_account.clone(), miktar, &FTTOKEN, 0, TEK ÇAĞRI İÇİN GAZ ); } }

Burada self.registered boyutu sınırsızdır, kötü niyetli kullanıcılar tarafından kontrol edilerek çok büyük hale getirilebilir, bu da distribute_token yürütüldüğünde Gas ücretinin sınırı aşmasına neden olur.

Çözüm: Harici kontrol edilebilen büyük veri yapılarının dolaşımını önermiyoruz. Kullanıcıların "temettü" geri almasını sağlamak için withdrawal modunu kullanabilirsiniz.

2. Akıllı sözleşmeler arası durum bağımlılığı nedeniyle tıkanma

Bir "ihale" 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: HesapKimliği, en yüksek teklif: u128, pub iade: bool }

PromiseOrValue { assert!(amount > self.highest_bid); 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::önceden ödenmiş_gas() - TEK_ARAMA_IÇIN_GAS * 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) }

Burada, önceki en yüksek teklif sahibinin tokeninin iade edilmesi, durumu güncellemenin ön koşuludur. Eğer bu kullanıcının hesabı kapatılmışsa, tüm ihale süreci bloke olur.

Çözüm: Dış çağrıların başarısız olabileceğini göz önünde bulundurarak hata işleme ekleyin. Geri alınamayan tokenleri geçici olarak saklayabilir, sonrasında kullanıcıların kendilerinin çekmesine izin verebilirsiniz.

3. Sahip özel anahtar kayboldu

Bazı anahtar fonksiyonlar yalnızca sahibi tarafından yürütülebilir. Eğer sahip görevini yerine getiremiyorsa ( özel anahtar kaybolursa ), sözleşmenin düzgün çalışmamasına neden olacaktır.

Çözüm: Birden fazla sahibin ortak yönetişimi için ayarlanması veya tek bir sahibin kontrolü yerine çoklu imza talebi kullanılması ile merkeziyetsiz yönetişimin sağlanması.

</accountid,balance></accountid,>