Attaque par déni de service dans les smart contracts Rust

L'attaque par déni de service ( DoS ) peut rendre les smart contracts inutilisables pendant une période, voire de manière permanente. Les principales raisons incluent :

1. La logique du contrat présente un défaut de complexité de calcul élevé, entraînant une consommation de Gas dépassant la limite.

2. Lors d'un appel entre contrats, l'exécution du contrat dépend de contrats externes peu fiables, ce qui entraîne un blocage.

3. Le propriétaire du contrat a perdu sa clé privée, il est impossible d'exécuter des fonctions de privilège pour mettre à jour des états importants.

Voici une analyse des vulnérabilités des attaques par déni de service à travers des exemples concrets.

1. Parcourir des structures de données volumineuses contrôlées par l'extérieur

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

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

pub fn register_account(&mut self) { si 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(&cur_account).expect("ERR_GET"); self.accounts.insert(\u0026cur_account, \u0026balance.checked_add(amount).expect("ERR_ADD")); log!("Try distribute to account {}", &cur_account); ext_ft_token::ft_transfer( cur_account.clone(), montant, &FTTOKEN, 0, GAS_FOR_SINGLE_CALL ); } }

Ici, la taille de self.registered n'est pas limitée, ce qui peut être manipulé par des utilisateurs malveillants et devenir trop grand, entraînant des frais de Gas dépassant la limite lors de l'exécution de distribute_token.

Solution : Il n'est pas recommandé de parcourir de grandes structures de données contrôlées par des tiers. Il est possible d'adopter un mode de retrait, permettant aux utilisateurs de récupérer eux-mêmes les "dividendes".

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

Considérer un contrat de "licitation" :

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 refund: bool }

PromiseOrValue { assert!(amount > self.highest_bid); if self.current_leader == DEFAULT_ACCOUNT { self.current_leader = sender_id; self.highest_bid = amount; } else { 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) }

Le retour des tokens au précédent enchérisseur le plus élevé est une condition préalable à la mise à jour de l'état. Si le compte de cet utilisateur a été désactivé, cela entraînera un blocage de l'ensemble du processus d'enchères.

Méthode de résolution : prendre en compte la possibilité d'échec des appels externes et augmenter la gestion des erreurs. Il est possible de mettre en attente les jetons non remboursables, puis de permettre aux utilisateurs de les extraire eux-mêmes par la suite.

3. Clé privée du propriétaire perdue

Certaines fonctions clés sont définies comme exécutables uniquement par le propriétaire. Si le propriétaire ne peut pas exercer ses fonctions, ( comme la perte de la clé privée ), cela entraînera le dysfonctionnement du contrat.

Solution : mettre en place plusieurs propriétaires pour une gouvernance partagée, ou adopter des demandes de multi-signature en remplacement du contrôle d'un unique propriétaire, afin d'atteindre une gouvernance décentralisée.

</accountid,balance></accountid,>