DApps - Applications Décentralisées

Reading time: 6 minutes

{{#include ../../banners/hacktricks-training.md}}

Qu'est-ce qu'un DApp ?

Un DApp est une application décentralisée qui fonctionne sur un réseau pair-à-pair, plutôt que d'être hébergée sur un serveur centralisé. Les DApps sont généralement construits sur la technologie blockchain, ce qui devrait permettre la transparence, la sécurité et l'immuabilité des données.

Architecture des DApp Web3

Selon cet article, il existe 3 types différents d'architecture de DApp Web3 :

DApps "sans API"

Ces DApps sont construits sur une blockchain et ne dépendent d'aucune API ou backend centralisé. On pourrait penser que la blockchain est le véritable backend de l'application. Ils sont entièrement décentralisés et peuvent être accessibles directement via la blockchain.

Pour interagir avec la blockchain, le client utilise généralement un portefeuille. Le portefeuille signera les transactions et les enverra à la blockchain. Le client peut également utiliser un nœud pour lire des données de la blockchain.

DApps "avec API"

Ces DApps sont construits sur une blockchain mais dépendent également d'APIs centralisées généralement pour recueillir des informations. Ils sont principalement décentralisés car même s'ils dépendent d'une API centralisée, la fonctionnalité principale du DApp est toujours sur la blockchain. La communication du client avec la blockchain se fait généralement via un portefeuille.

Un bon exemple de ce type de DApp est une application de minting de NFT. Le serveur permet de télécharger les images mais le minting est effectué par le client via un portefeuille.

DApps "à grande échelle"

Ces DApps sont construits sur une blockchain mais dépendent également d'APIs centralisées et de serveurs backend. Ils pourraient être partiellement décentralisés car le client pourrait être en mesure d'effectuer des opérations sur la blockchain en utilisant un portefeuille. Cependant, généralement, le backend sera également capable d'effectuer des opérations sur la blockchain.

Un bon exemple de ce type de DApp est un pont inter-chaînes où un composant hors chaîne est nécessaire pour communiquer avec des contrats intelligents dans différentes blockchains pour effectuer le transfert d'actifs.

Vulnérabilités Web2

Les vulnérabilités Web2 affectent toujours ce type d'applications bien que leur impact puisse varier :

  • Les vulnérabilités côté client ont un impact accru car dans les DApps Web3, le client est généralement celui qui effectue les opérations sur la blockchain via un portefeuille. Cela signifie que des attaques comme XSS qui parviennent à exécuter du code JS côté client ou qui altèrent le contenu de la page peuvent avoir un impact plus important car elles peuvent interagir avec le portefeuille et convaincre l'utilisateur d'effectuer des opérations indésirables sur la blockchain.
  • Notez que généralement même dans ce type d'applications, le client peut toujours examiner les opérations avant de les signer avec le portefeuille. Cependant, si l'attaquant parvient à altérer le contenu de la page, il peut convaincre l'utilisateur de signer une transaction qui effectuera une opération indésirable sur la blockchain.
  • Les vulnérabilités côté serveur sont toujours présentes dans les DApps qui dépendent d'un serveur backend. L'impact de ces vulnérabilités dépendra de l'architecture du DApp. Cependant, elles pourraient encore être très problématiques car un attaquant pourrait trouver dans le backend des clés de l'entreprise pour accéder aux fonds des contrats intelligents, ou pourrait effectuer une prise de contrôle de compte qui pourrait leur permettre de voler des fonds ou des NFT aux utilisateurs.

Bien sûr, si le DApp n'utilise pas de backend ou si le backend utilisé n'offre que des données de chaîne publique ou des pages statiques, la surface d'attaque du DApp est réduite.

Surface d'attaque Web3

Même si en général un DApp a une surface d'attaque réduite car plusieurs vérifications de sécurité sont toujours effectuées sur la blockchain, il existe encore certains vecteurs d'attaque qui peuvent être exploités par un attaquant.

Il pourrait être possible de regrouper les vulnérabilités des DApps Web3 dans les catégories suivantes :

  • Transactions On-Chain mal gérées : API de transaction mal formatées ou non restreintes, absence de logique d'attente de réponse et de confirmation de bloc, exposition de données sensibles, et gestion incorrecte des transactions échouées, annulées ou de type interne qui permettent des injections de données malveillantes.

  • Attaques Backend pilotées par des contrats intelligents : stockage ou synchronisation de données sensibles entre contrats et bases de données sans validation, émissions d'événements non vérifiées ou adresses de contrats, et vulnérabilités exploitables des contrats qui peuvent empoisonner la logique du backend.

  • Opérations de crypto-actifs défectueuses : traitement incorrect de différents types de jetons (natifs vs. ERC-20), ignorance de la précision décimale, échecs de transferts ou transactions internes, et acceptation de jetons faux, déflationnistes, de rebase ou sujets à la glissade sans validation, permettant des injections de charges utiles via les métadonnées des jetons.

Quelques exemples de cet article :

Gas Gaspié : Forcer le backend à effectuer des transactions

Dans le scénario Crypto gaspillé en gaz via API non restreinte, l'attaquant peut forcer le backend à appeler des fonctions d'un contrat intelligent qui consommeront du gaz. L'attaquant, en envoyant simplement un numéro de compte ETH et sans limites, forcera le backend à appeler le contrat intelligent pour l'enregistrer, ce qui consommera du gaz.

DoS : Mauvais temps de gestion des transactions

Dans le scénario Mauvaise gestion du temps de transaction mène à un DoS, il est expliqué que parce que le backend maintiendra la requête HTTP ouverte jusqu'à ce qu'une transaction soit effectuée, un utilisateur peut facilement envoyer plusieurs requêtes HTTP au backend, ce qui consommera toutes les ressources du backend et mènera à un DoS.

Désynchronisation Backend<-->Blockchain - Condition de course

Dans le scénario Mauvaise gestion du temps de transaction mène à une condition de course, il est expliqué que dans un jeu, il était possible pour l'utilisateur d'envoyer une demande de retrait au backend qui enverra à l'utilisateur ses pièces, mais pendant que la transaction était encore en cours de traitement, l'utilisateur a pu utiliser ces pièces pour acheter des objets dans le jeu, les obtenant gratuitement.

Un autre exemple pourrait être de pouvoir utiliser les mêmes pièces pour acheter différents objets car le backend donne immédiatement l'objet à l'utilisateur sans attendre que la transaction soit confirmée et donc sans attendre que le solde de l'utilisateur dans la blockchain soit réduit.

Validation de l'adresse du contrat intelligent

Dans le scénario Le backend du pont manque de validation de l'adresse du contrat intelligent, il est expliqué comment le backend vérifiait l'adresse du contrat intelligent, il était donc possible pour un attaquant de déployer un faux contrat intelligent, d'y mettre des fonds, d'envoyer la transaction au backend et le backend pensera que l'utilisateur a envoyé des fonds au véritable contrat intelligent et donnera à l'utilisateur les jetons.

Mauvaise gestion des classes d'actifs

Dans le scénario Mauvaise gestion des classes d'actifs, il est expliqué que le backend confondait un NFT de scam à une adresse avec 1 MATIC, permettant ainsi à l'attaquant d'envoyer des centaines de NFT de scam à l'adresse et d'obtenir 1 MATIC de la plateforme pour chacun d'eux.

Références

{{#include ../../banners/hacktricks-training.md}}