Три основні вразливості DoS-атак смартконтрактів та стратегії їх запобігання

2025-07-20 22:36:57

Глибокий аналіз атаки на відмову в обслуговуванні в смартконтрактах

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

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

Нижче наведено аналіз вразливості атаки на відмову в обслуговуванні на конкретних прикладах:

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

Ось простий смартконтракт для "доля" користувачів:

іржавчина #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] публічна структура Контракт { 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, що призведе до збою транзакції.

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

! [])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( }

#) pub fn account_resolve[private]&mut self, sender_id: AccountId, amount: u128( { відповідність env::promise_result)0( { PromiseResult::NotReady => недосяжний!)(, PromiseResult::Успішний)_( => { 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.highest_bid = кількість; } PromiseResult::Failed => { ext_ft_token::ft_transfer) sender_id.clone((, кількість, &FTTOKEN, 0, GAS_FOR_SINGLE_CALL * 2, ); log!)"Повернутися зараз"(; } }; }

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

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

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

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

Рекомендується використовувати механізм мультипідпису замість одноосібного контролю прав власності, щоб реалізувати децентралізоване управління.

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

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

Переглянути оригінал

Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.

5 лайків

Нагородити
5
7
Поділіться

Прокоментувати

0/400

DeFiChef