Rust akıllı sözleşmelerde DoS saldırı açığı analizi

DoS (Hizmet Reddi ) saldırıları, akıllı sözleşmelerin bir süreliğine veya kalıcı olarak normal bir şekilde kullanılamamasına neden olabilir. Ana nedenler şunlardır:

1. Sözleşme mantığında hatalar var. Örneğin, bazı public fonksiyonların implementasyonu hesaplama karmaşıklığını dikkate almadığı için Gas tüketimi sınırı aşıyor.

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 yürütülmesinin güvenilmez olması, bu sözleşmenin engellenmesine neden olabilir.

3. İnsan faktörleri, örneğin, sözleşme sahibinin özel anahtarını kaybetmesi, önemli sistem durumlarının zamanında güncellenememesine neden olur.

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

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

Aşağıda kayıtlı kullanıcılar için "kar payı" veren 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\u003caccountid, bakiye=""\u003e, }

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::predecessor_account_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(&cur_account, &balance.checked_add(amount).expect("ERR_ADD"));
    log!("Hesabı dağıtmaya çalış {}", &cur_account);
    
    ext_ft_token::ft_transfer(
        cur_account.clone(),
        miktar,
        &FTTOKEN,
        0,
        TEKÇAĞRI İÇİN GAZ
    );
}

}

Bu sözleşmenin durum verisi self.registered boyutu sınırsızdır ve kötü niyetli kullanıcılar tarafından çok büyük hale getirilmesi sağlanabilir. Bu da distribute_token'ın yürütülmesi sırasında Gas tüketiminin sınırı aşarak başarısız olmasına neden olur.

Önerilen çekim modu: Sözleşme tarafı önce muhasebe yapar, kullanıcı ödüllerini geri almak için withdraw fonksiyonunu kendisi kullanır. Sözleşme sadece tek bir kullanıcının ödül miktarını korumalıdır.

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\u003caccountid,balance\u003e, mevcut_lider: AccountId, 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::ön ödenmiş_gaz() - TEK_ARAÇ_IÇIN_GAZ * 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)

}

Bu sözleşmenin mantığı, yeni en yüksek teklifi güncellemek için önceki en yüksek teklif sahibinin token'ının geri iade edilmesine bağımlıdır. Eğer önceki hesabın kapatılmışsa, yeni teklif engellenecektir.

Çözüm: Dış çağrıların başarısız olabileceği durumları dikkate alarak hata işleme ekleyin. İade edilemeyen tokenleri geçici olarak saklayabilir, ardından kullanıcı kendi isteğiyle çekebilir.

3. Owner özel anahtar kaybı

Bazı sözleşme fonksiyonları yalnızca owner tarafından yürütülecek şekilde ayarlanmıştır ve kritik sistem değişkenlerini değiştirmek için kullanılır. Eğer owner görevini yerine getiremiyorsa (, örneğin özel anahtar kaybolursa ), bu işlevler kullanılamaz hale gelecek ve sözleşmenin çökmesine neden olabilir.

Çözüm yolu:

• Birden fazla sahibi ortak yönetim için ayarlayın
• Tek bir owner yetki kontrolü yerine çoklu imza çözümü benimsemek
• Merkeziyetsiz yönetim mekanizması gerçekleştirmek

Mantıklı yetki tasarımı ve yönetişim mekanizmaları, tek nokta arızası riskini etkili bir şekilde azaltabilir ve sözleşmelerin dayanıklılığını artırabilir.

</accountid,balance></accountid,>