Аналіз вразливостей DoS-атак у смартконтрактах на Rust

DoS (Відмова в обслуговуванні)атака може призвести до того, що смартконтракти не зможуть нормально використовуватися протягом певного часу або навіть назавжди. Основні причини включають:

1. У логіці контракту є недоліки. Наприклад, деякі реалізації public-функцій не враховують обчислювальну складність, що призводить до перевищення обмеження витрат Gas.

2. Залежність від стану виконання зовнішніх смартконтрактів під час виклику між контрактами. Ненадійне виконання зовнішнього смартконтракту може призвести до блокування цього контракту.

3. Людські фактори, такі як втрата приватного ключа власником контракту, призводять до того, що важливий стан системи не може бути своєчасно оновлено.

Нижче через конкретні приклади аналізується вразливість атаки DoS.

1. Циклічний перегляд великих структур даних, які можуть бути змінені зовні

Наступний приклад простого контракту для "долі" зареєстрованих користувачів:

іржа #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] pub struct Contract { pub зареєстровані: Vec\u003caccountid\u003e, облікові записи pub: UnorderedMap<accountid, balance="">, }

pub fn register_account(&mut self) { якщо self.accounts.insert(&env::p redecessor_account_id(), &0).is_ some() { env::panic("Обліковий запис вже зареєстровано".to_string().as_bytes()); } else { self.registered.push(env::p redecessor_account_id()); } log!("Зареєстрований акаунт {}", env::predecessor_account_id()); }

pub fn distribute_token(&mut self, кількість: u128) { assert_eq!(env::p redecessor_account_id(), ДИСТРИБ'ЮТОР, "ERR_NOT_ALLOWED");

для cur_account в self.registered.iter() {
    let balance = self.accounts.get(&cur_account).expect("ERR_GET");
    self.accounts.insert019283746574839201&cur_account, &balance.checked_add(amount(.expect)"ERR_ADD" ();
    log!)"Спробуйте розподілити на рахунок {}", &cur_account(;
    
    ext_ft_token::ft_transfer)
        cur_account.clone((,
        сума,
        &FTTOKEN,
        0,
        GAS_FOR_SINGLE_CALL
    );
}

}

Дані стану цього контракту self.registered не мають обмежень за розміром, що дозволяє зловмисним користувачам маніпулювати ними, роблячи їх занадто великими. Це призводить до того, що під час виконання distribute_token витрати Gas перевищують ліміт і виклик закінчується невдачею.

Рекомендується використовувати режим виведення: сторона контракту спочатку веде облік, користувач самостійно отримує винагороду через функцію withdraw. Контракту потрібно підтримувати лише єдину суму винагороди для користувача.

! [])https://img-cdn.gateio.im/webp-social/moments-b7bbfcf4423b1cf19db56a3af95a7486.webp(

2. Залежність стану між контрактами призводить до блокування контракту

Розгляньте контракт "аукціон":

іржа #[near_bindgen] #[derive)BorshDeserialize, BorshSerialize(] pub struct Contract { pub зареєстровано: Vec, pub bid_price: UnorderedMap<accountid,balance>, pub current_leader: AccountId, highest_bid пабу: U128, Повернення коштів у пабі: bool }

pub fn bid)&mut self, sender_id: AccountId, amount: u128( -> PromiseOrValue { стверджувати!)amount > self.highest_bid(;

if self.current_leader == DEFAULT_ACCOUNT {
    self.current_leader = sender_id;
    self.highest_bid = кількість;
} else {
    ext_ft_token::account_exist)
        self.current_leader.clone((,
        &FTTOKEN,
        0,
        env::попередньо_оплачений_газ)( - GAS_FOR_SINGLE_CALL * 4,
    ).then)ext_self::account_resolve(
        sender_id,
        кількість,
        &env::current_account_id((,
        0,
        GAS_FOR_SINGLE_CALL * 3,
     ));
}

журналу!)
    "поточний_лідер: {} найвища_ставка: {}", 
    self.current_leader,
    self.highest_bid
(;

PromiseOrValue::Value)0(

}

Логіка цього смартконтракту залежить від повернення токенів попереднього найвищого ставленника, щоб оновити нову найвищу ставку. Якщо обліковий запис попереднього учасника скасовано, нова ставка буде заблокована.

Рішення: врахувати можливі випадки невдачі зовнішніх викликів, додати обробку помилок. Можна тимчасово зберігати токени, які не підлягають поверненню, а потім користувач самостійно їх витягує.

3. Втрата приватного ключа власника

Деякі функції контракту налаштовані так, що їх може виконувати лише owner, для зміни ключових системних змінних. Якщо owner не може виконувати свої функції ), наприклад, у випадку втрати приватного ключа (, ці функції не будуть доступні, що може призвести до зупинки контракту.

Рішення:

• Налаштувати кількох власників для спільного управління
• Використання багатопідписного рішення замість єдиного контролю прав власника
• Реалізація механізму децентралізованого управління

Розумне проектування прав доступу та механізмів управління можуть ефективно знизити ризик одноточкових відмов і підвищити надійність контрактів.

! [])https://img-cdn.gateio.im/webp-social/moments-7076cf1226a2276d1e4cd994d259841f.webp(</accountid,balance></accountid,>