Analyse approfondie des attaques par déni de service dans les smart contracts

attaque par déni de service ( DoS ) peut entraîner une utilisation temporaire ou permanente incorrecte des smart contracts. Les principales raisons incluent :

1. La logique des contrats présente des défauts. Par exemple, certaines fonctions publiques ne tiennent pas compte de la complexité des calculs, ce qui peut dépasser la limite de Gas et entraîner l'échec de la transaction.

2. Dans les appels inter-contrats, l'exécution du contrat dépend de l'état du contrat externe. L'exécution du contrat externe peu fiable peut bloquer l'exécution de ce contrat, par exemple lorsque les fonds des utilisateurs sont verrouillés et ne peuvent pas être déposés ou retirés.

3. Facteurs humains, comme la perte de la clé privée par le propriétaire du contrat, entraînant l'incapacité d'appeler certaines fonctions privilégiées et l'impossibilité de mettre à jour des états système importants.

Voici une analyse des vulnérabilités des attaques par déni de service (DoS) à l'aide d'exemples concrets :

1. Parcourir de grandes structures de données modifiables par des facteurs externes

Voici un contrat simple pour "distribuer des dividendes" aux utilisateurs :

rouille #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] pub struct Contract { pub registered: Vec\u003caccountid\u003e, pub accounts: UnorderedMap<accountid, balance="">, }

pub fn register_account(&mut self) { if self.accounts.insert(&env::predecessor_account_id(), &0).is_some() { env::panic("Le compte est déjà enregistré".to_string().as_bytes()); } else { self.registered.push(env::predecessor_account_id()); } log!("Compte enregistré {}", env::predecessor_account_id()); }

pub fn distribute_token(&mut self, amount: u128) { assert_eq!(env::predecessor_account_id(), DISTRIBUTEUR, "ERR_NOT_ALLOWED");

pour cur_account dans self.registered.iter() {
    let balance = self.accounts.get(\u0026cur_account).expect("ERR_GET");
    self.accounts.insert(\u0026cur_account, \u0026balance.checked_add(amount).expect("ERR_ADD"));
    log!("Essayer de distribuer au compte {}", &cur_account);
    ext_ft_token::ft_transfer(
        cur_account.clone(),
        montant,
        &FTTOKEN,
        0,
        GAS_FOR_SINGLE_CALL
    );
}

}

Les données d'état du contrat self.registered n'ont pas de taille limitée et peuvent être manipulées par des utilisateurs malveillants. Lorsque le nombre d'utilisateurs enregistrés est trop important, l'exécution de distribute_token peut dépasser la limite de Gas, entraînant l'échec de la transaction.

Il est recommandé de modifier le mode de retrait : ne pas distribuer activement les dividendes à tous les utilisateurs, mais plutôt de tenir des comptes et de mettre en place une fonction de retrait permettant aux utilisateurs de retirer eux-mêmes leurs récompenses.

2. La dépendance d'état entre contrats croisés entraîne un blocage

Considérons un scénario de contrat d'enchères :

rouille #[near_bindgen] #[derive(BorshDeserialize, BorshSerialize)] pub struct Contract { pub registered: Vec\u003caccountid\u003e, pub bid_price: UnorderedMap\u003caccountid,balance\u003e, pub current_leader: AccountId, pub highest_bid: u128, pub remboursement: bool }

PromiseOrValue { assert!(montant > self.highest_bid); si self.current_leader == DEFAULT_ACCOUNT { self.current_leader = sender_id; self.highest_bid = amount; } sinon { ext_ft_token::account_exist( self.current_leader.clone)(, &FTTOKEN, 0, env::prepaid_gas() - GAS_FOR_SINGLE_CALL * 4, (.then)ext_self::account_resolve) sender_id, montant, &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] { 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.highest_bid = amount; } PromiseResult::Failed => { ext_ft_token::ft_transfer) sender_id.clone)(, montant, &FTTOKEN, 0, GAS_FOR_SINGLE_CALL * 2, (; log!)"Return Back Now"); } }; }

Ce contrat exige que les jetons de l'enchérisseur précédent soient retournés pour mettre à jour la meilleure enchère. Si ce dernier annule son compte dans un contrat externe, cela entraînera l'incapacité du système à mettre à jour l'enchérisseur le plus élevé.

Il est conseillé d'ajouter un mécanisme de gestion des erreurs, comme le stockage des jetons non remboursables dans le compte lost_found du contrat, permettant ensuite aux utilisateurs de les retirer.

3. Perte de la clé privée du propriétaire

Certaines fonctions de contrat sont définies pour être exécutées uniquement par le propriétaire, afin de modifier des variables système critiques. Lorsque le propriétaire est dans l'incapacité d'exercer ses fonctions (, par exemple en cas de perte de clé privée ), cela peut entraîner le blocage des fonds ou la suspension des transactions.

Il est conseillé d'adopter un mécanisme de multi-signatures pour remplacer le contrôle des droits d'un seul propriétaire, afin de réaliser une gouvernance décentralisée.

En résumé, le développement de contrats doit tenir compte des divers risques potentiels d'attaque par déni de service (DoS) et prendre des mesures de prévention appropriées pour garantir le fonctionnement stable et à long terme des contrats.

</accountid,balance></accountid,>