Rust akıllı sözleşmeler yetiştirme günlüğü: hizmet reddi saldırısı önleme

hizmet reddi saldırısı ( DoS ) saldırısı, akıllı sözleşmelerin bir süreliğine ya da kalıcı olarak düzgün çalışamamasına neden olabilir. Yaygın nedenler arasında:

1. Sözleşme mantığındaki hesaplama karmaşıklığı sorunu, Gas tüketiminin sınırını aşmasına neden olur.

2. Akıllı sözleşmeler arası çağrılarda, dış sözleşmelerin yürütme durumuna yanlış bağımlılık, bu sözleşmenin engellenmesine neden olur.

3. Sözleşme sahibi özel anahtar kayboldu, bu da ayrıcalıklı fonksiyonların çağrılamamasına ve önemli sistem durumunun güncellenememesine neden oldu.

Aşağıda, DoS saldırı açıklarını ve bunların çözüm yollarını analiz etmek için birkaç somut örnek verilecektir.

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

Aşağıda bir "temettü" akıllı sözleşmesi bulunmaktadır, hizmet reddi saldırısı riski vardır:

pas #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] pub struct Sözleşme { pub kayıtlı: Vec, pub hesaplar: SırasızHarita<accountid, bakiye="">, }

impl Sözleşme { pub fn register_account(&mut self) { if 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(), 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!("Hesaba {} dağıtmaya çalışın", &cur_account);
        
        ext_ft_token::ft_transfer(
            cur_account.clone(),
            miktar,
            &FTTOKEN,
            0,
            TEKÇAĞRI İÇİN GAZ
        );
    }
}

}

Sorun, registered dizisinin boyutunun bir sınırı olmaması ve kötü niyetli kullanıcılar tarafından çok büyük hale getirilmesi, bu nedenle distribute_token fonksiyonu çalıştırıldığında Gas tüketiminin sınırı aşmasıdır.

Önerilen çözüm:

1. registered dizisinin boyutunu sınırlayın.

2. "Çekim" modunu benimseyin, kullanıcıların ödülleri kendilerinin çekmesine izin verin, sözleşmenin aktif olarak dağıtması yerine.

2. Akıllı sözleşmelerin durumu bağımlılığı nedeniyle sözleşme engellenmesi

Aşağıda bir "tender" akıllı sözleşme örneği bulunmaktadır:

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

impl Sözleşme { 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::önceden ö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,
        kendisi.en yüksek teklif
    );
    PromiseOrValue::Value(0)
}

#(
pub fn account_resolve)&mut self, sender_id: AccountId, amount: u128[private] {
    match env::promise_result(0) {
        PromiseResult::NotReady => unreachable!(),
        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::Failed => {
            ext_ft_token::ft_transfer)
                sender_id.clone)(,
                miktar,
                &FTTOKEN,
                0,
                GAS_FOR_SINGLE_CALL * 2,
            (;
            log!)"Şimdi Geri Dön");
        }
    };
}

}

Sorun, sözleşme durum güncellemelerinin dış sözleşme çağrılarına bağımlı olmasıdır. Eğer önceki en yüksek teklif verenin hesabı kapatılmışsa, sonraki teklif verenler durumu güncelleyemez.

Önerilen çözüm:

Dış çağrıların başarısız olabileceği durumları dikkate alarak, makul bir hata işleme mekanizması uygulayın. Örneğin, geri alınamaz tokenleri sözleşmede geçici olarak saklayın ve daha sonra kullanıcılara aktif olarak çekme izni verin.

3. Sahip özel anahtar kayboldu

Birçok sözleşme yalnızca sahip tarafından yürütülebilen ayrıcalıklı işlevler içerir. Eğer sahip özel anahtarı kaybolursa, bu işlevler çağrılmaz hale gelir ve sözleşmenin düzgün çalışmamasına neden olabilir.

Önerilen çözüm:

1. Birden fazla sözleşme sahibini ortak yönetim için ayarlayın.

2. Tek bir sahibi kontrol etmek yerine çoklu imza mekanizması kullanın.

3. Merkeziyetsiz bir sözleşme yönetim mekanizmasının gerçekleştirilmesi.

Yukarıdaki önlemlerle, akıllı sözleşmelerde hizmet reddi saldırısı riskini etkili bir şekilde azaltabilir, sözleşmenin güvenliğini ve güvenilirliğini artırabilirsiniz.

<accountid,balance><accountid,>