smart contracts dans les attaques par déni de service
L'attaque par déni de service ( DoS ) peut entraîner l'incapacité des smart contracts à fonctionner normalement pendant un certain temps, voire de manière permanente. Les principales raisons incluent:
La logique du contrat présente des défauts. Par exemple, certaines fonctions publiques ne tiennent pas compte de la complexité de calcul, ce qui peut dépasser la limite de Gas et entraîner l'échec de la transaction.
Dans les scénarios d'appel inter-contrats, l'exécution des contrats dépend de l'état des contrats externes. L'exécution des contrats externes peu fiable peut bloquer l'exécution de ce contrat, par exemple, des fonds peuvent être verrouillés et ne peuvent pas être déposés ou retirés.
Facteurs humains, comme la perte de la clé privée par le propriétaire du contrat, entraînant l'impossibilité de mettre à jour l'état clé du système.
Voici une analyse des vulnérabilités des attaques par déni de service (DoS) avec des exemples spécifiques.
1. Parcourir une grande structure de données modifiable par des tiers
Voici un contrat simple utilisé pour "distribuer des dividendes" aux utilisateurs enregistrés :
L'état du contrat contient une liste d'utilisateurs enregistrés et une correspondance des soldes de compte. Les utilisateurs peuvent s'inscrire et initialiser via register_account().
L'administrateur distribue des dividendes aux utilisateurs via distribute_token(), en parcourant le tableau registered pour transférer un nombre spécifié de jetons à chaque utilisateur.
Le problème réside dans le fait que la taille de registered est illimitée et peut être manipulée de manière malveillante, ce qui entraîne une consommation de Gas trop élevée lors de l'itération, dépassant la limite.
Solutions recommandées :
Limiter la taille de la structure de données, s'assurer que même en atteignant la valeur maximale, cela ne dépasse pas la limite de Gas
Adoption du mode de retrait, d'abord comptabilisation, l'utilisateur récupère les récompenses par lui-même via withdraw
2. La dépendance à l'état entre les contrats entraîne un blocage
Considérons un scénario de contrat de "enchères" :
Enregistrer le meilleur enchérisseur actuel et le montant
Les utilisateurs peuvent s'inscrire pour participer aux enchères
Lorsque l'enchère est supérieure au prix maximum actuel, retourner le prix maximum précédent, mettre à jour l'état.
Le problème est que le remboursement dépend de l'état des contrats externes. Si le compte de l'enchérisseur le plus élevé a été annulé auparavant, le remboursement échouera, ce qui empêchera la mise à jour du prix le plus élevé et bloquera l'ensemble du processus d'enchères.
Méthode de résolution:
Considérer que les appels externes peuvent échouer et mettre en œuvre un traitement des erreurs raisonnable. Par exemple, stocker temporairement les fonds non remboursables, puis permettre à l'utilisateur de les retirer séparément.
3. Clé privée de l'administrateur perdue
Certaines fonctions clés ( telles que la pause/reprise des transactions ) ne peuvent être appelées que par l'administrateur. La perte de la clé privée de l'administrateur entraînera l'impossibilité d'utiliser ces fonctionnalités, et le contrat pourrait ne pas fonctionner correctement pendant une longue période.
Solution :
Adopter un mécanisme de multi-signature pour remplacer un administrateur unique, réaliser une gouvernance décentralisée et éviter les points de défaillance.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
18 J'aime
Récompense
18
7
Partager
Commentaire
0/400
NFTFreezer
· 07-16 03:27
Il était déjà prévu que le numéro allait être volé.
Voir l'originalRépondre0
BridgeJumper
· 07-15 12:26
Clé privée, pourquoi ne dis-tu pas que tu as perdu tes pantalons ?
Voir l'originalRépondre0
AirdropF5Bro
· 07-13 07:29
Le patron, signez d'abord beaucoup, stabilisez un peu.
Voir l'originalRépondre0
MetaEggplant
· 07-13 07:28
Le coût réel du test est un peu élevé.
Voir l'originalRépondre0
Ser_This_Is_A_Casino
· 07-13 07:26
Trop nul, je pensais que DOS ne pouvait gérer que le web.
Voir l'originalRépondre0
RiddleMaster
· 07-13 07:13
Clé privée perdue, envoyez-la directement !
Voir l'originalRépondre0
NFTBlackHole
· 07-13 07:13
Encore en train de faire des choses avec le portefeuille.
Analyse des risques d'attaque DoS sur les smart contracts et stratégies de prévention
smart contracts dans les attaques par déni de service
L'attaque par déni de service ( DoS ) peut entraîner l'incapacité des smart contracts à fonctionner normalement pendant un certain temps, voire de manière permanente. Les principales raisons incluent:
La logique du contrat présente des défauts. Par exemple, certaines fonctions publiques ne tiennent pas compte de la complexité de calcul, ce qui peut dépasser la limite de Gas et entraîner l'échec de la transaction.
Dans les scénarios d'appel inter-contrats, l'exécution des contrats dépend de l'état des contrats externes. L'exécution des contrats externes peu fiable peut bloquer l'exécution de ce contrat, par exemple, des fonds peuvent être verrouillés et ne peuvent pas être déposés ou retirés.
Facteurs humains, comme la perte de la clé privée par le propriétaire du contrat, entraînant l'impossibilité de mettre à jour l'état clé du système.
Voici une analyse des vulnérabilités des attaques par déni de service (DoS) avec des exemples spécifiques.
1. Parcourir une grande structure de données modifiable par des tiers
Voici un contrat simple utilisé pour "distribuer des dividendes" aux utilisateurs enregistrés :
L'état du contrat contient une liste d'utilisateurs enregistrés et une correspondance des soldes de compte. Les utilisateurs peuvent s'inscrire et initialiser via register_account().
L'administrateur distribue des dividendes aux utilisateurs via distribute_token(), en parcourant le tableau registered pour transférer un nombre spécifié de jetons à chaque utilisateur.
Le problème réside dans le fait que la taille de registered est illimitée et peut être manipulée de manière malveillante, ce qui entraîne une consommation de Gas trop élevée lors de l'itération, dépassant la limite.
Solutions recommandées :
2. La dépendance à l'état entre les contrats entraîne un blocage
Considérons un scénario de contrat de "enchères" :
Le problème est que le remboursement dépend de l'état des contrats externes. Si le compte de l'enchérisseur le plus élevé a été annulé auparavant, le remboursement échouera, ce qui empêchera la mise à jour du prix le plus élevé et bloquera l'ensemble du processus d'enchères.
Méthode de résolution: Considérer que les appels externes peuvent échouer et mettre en œuvre un traitement des erreurs raisonnable. Par exemple, stocker temporairement les fonds non remboursables, puis permettre à l'utilisateur de les retirer séparément.
3. Clé privée de l'administrateur perdue
Certaines fonctions clés ( telles que la pause/reprise des transactions ) ne peuvent être appelées que par l'administrateur. La perte de la clé privée de l'administrateur entraînera l'impossibilité d'utiliser ces fonctionnalités, et le contrat pourrait ne pas fonctionner correctement pendant une longue période.
Solution : Adopter un mécanisme de multi-signature pour remplacer un administrateur unique, réaliser une gouvernance décentralisée et éviter les points de défaillance.