Akıllı sözleşmelerde hizmet reddi saldırısını derinlemesine analiz

hizmet reddi saldırısı(DoS)akıllı sözleşmelerin geçici veya kalıcı olarak düzgün çalışmamasına neden olabilir. Ana nedenler şunlardır:

1. Sözleşme mantığında hatalar var. Örneğin, bazı açık fonksiyonlar hesaplama karmaşıklığını dikkate almadıysa, bu Gas limitini aşarak işlemin başarısız olmasına neden olabilir.

2. Akıllı sözleşmeler arası çağrılarda, sözleşme yürütülmesi dış sözleşmenin durumuna bağlıdır. Dış sözleşmenin güvenilir olmaması, bu sözleşmenin çalışmasını engelleyebilir; örneğin, kullanıcı fonları kilitlenebilir ve çekim yapılamaz.

3. İnsan faktörleri, örneğin sözleşme sahibinin özel anahtarını kaybetmesi, bazı ayrıcalıklı işlevlerin çağrılamamasına ve önemli sistem durumlarının güncellenememesine neden olur.

Aşağıda belirli örneklerle DoS saldırı açığını analiz edeceğiz:

1. Dışarıdan değiştirilebilen büyük veri yapılarında dolaşma

Aşağıda kullanıcılara "kar payı" dağıtan 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, bakiye="">, }

pub fn register_account(&mut self) { eğer self.accounts.insert(&env::predecessor_account_id(), &0).is_some() { env::panic("Hesap zaten kaydedilmiş".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
    );
}

}

Bu sözleşme durum verisi self.registered boyutu sınırsızdır ve kötü niyetli kullanıcılar tarafından manipüle edilebilir. Kayıtlı kullanıcı sayısı çok fazla olduğunda, distribute_token işlemi Gas sınırını aşabilir ve işlem başarısız olabilir.

Çekim modunu dönüştürmeyi öneriyorum: Tüm kullanıcılara aktif olarak kar payı dağıtmamak, bunun yerine muhasebe yapmak ve kullanıcının ödülleri kendisinin çekebilmesi için withdraw fonksiyonu ayarlamak.

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

Bir ihale sözleşmesi senaryosunu düşünün:

pas #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] pub struct Sözleşme { pub kayıtlı: Vec, pub bid_price: UnorderedMap\u003caccountid,balance\u003e, pub current_leader: AccountId, en yüksek teklif: u128, pub iade: bool }

PromiseOrValue { assert!(miktar > self.highest_bid); eğer self.current_leader == DEFAULT_ACCOUNT { self.current_leader = sender_id; self.highest_bid = amount; } else { ext_ft_token::account_exist( self.current_leader.clone)(, &FTTOKEN, 0, env::ön ödenmiş_gas() - GAS_FOR_SINGLE_CALL * 4, (.then)ext_self::account_resolve) gönderici_id, miktar, &env::current_account_id((, 0, GAS_FOR_SINGLE_CALL * 3, (); } log!) "current_leader: {} highest_bid: {}", self.current_leader, self.highest_bid ); PromiseOrValue::Value(0) }

#( pub fn account_resolve)&mut self, sender_id: AccountId, amount: u128[private] { eşleşme env::promise_result(0) { PromiseResult::NotReady => ulaşılamaz!(), 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.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"); } }; }

Bu sözleşme, en yüksek teklifi verenin token'inin iade edilmesini gerektirir, aksi takdirde en yüksek teklif güncellenemez. Eğer önceki teklif sahibi dış bir sözleşmede hesabını iptal ederse, sistem en yüksek teklifi güncelleyemez.

Hata işleme mekanizmasının artırılmasını öneriyorum, örneğin geri alınamayan tokenleri sözleşmenin lost_found hesabına yatırmak, daha sonra kullanıcıların çekmesine izin vermek.

3. Sahibi özel anahtar kayboldu

Bazı sözleşme işlevleri yalnızca owner tarafından yürütülecek şekilde ayarlanmıştır, bu kritik sistem değişkenlerini değiştirmek için kullanılır. Owner görevini yerine getiremediğinde (, örneğin özel anahtar kaybolduğunda ), fonların kilitlenmesine veya işlemlerin durdurulmasına neden olabilir.

Birden fazla imza mekanizmasının tek bir sahip yetkilendirmesi yerine kullanılmasını öneriyorum, merkeziyetsiz yönetişim sağlamak için.

Yukarıda belirtilenlere göre, sözleşme geliştirme sürecinde çeşitli potansiyel hizmet reddi saldırısı (DoS) risklerini dikkate almak, uygun önlemleri almak ve sözleşmenin uzun vadeli istikrarlı bir şekilde çalışmasını sağlamak önemlidir.

<accountid,balance><accountid,>