DApps - Applicazioni Decentralizzate

Reading time: 5 minutes

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

Che cos'è un DApp?

Un DApp è un'applicazione decentralizzata che funziona su una rete peer-to-peer, piuttosto che essere ospitata su un server centralizzato. I DApps sono tipicamente costruiti su tecnologia blockchain, che dovrebbe consentire trasparenza, sicurezza e immutabilità dei dati.

Architettura DApp Web3

Secondo questo post, ci sono 3 diversi tipi di architettura DApp Web3:

DApps "senza API"

Questi DApps sono costruiti sopra una blockchain e non si basano su API o backend centralizzati. Potresti pensare che la blockchain sia il vero backend dell'applicazione. Sono completamente decentralizzati e possono essere accessibili direttamente attraverso la blockchain.

Per interagire con la blockchain, il client di solito utilizzerà un wallet. Il wallet firmerà le transazioni e le invierà alla blockchain. Il client potrebbe anche utilizzare un node per leggere i dati dalla blockchain.

DApps "abilitati API"

Questi DApps sono costruiti sopra una blockchain ma si basano anche su API centralizzate solitamente per raccogliere informazioni. Sono per lo più decentralizzati perché anche se si basano su un'API centralizzata, la funzionalità principale del DApp è ancora sulla blockchain. La comunicazione del client con la blockchain avviene di solito tramite un wallet.

Un buon esempio di questo tipo di DApp è un applicazione di minting NFT. Il server consente di caricare le immagini, ma il minting è effettuato dal client tramite un wallet.

DApps "Full-Scale"

Questi DApps sono costruiti sopra una blockchain ma si basano anche su API centralizzate e server backend. Potrebbero essere parzialmente decentralizzati poiché il client potrebbe essere in grado di eseguire operazioni sulla blockchain utilizzando un wallet. Tuttavia, di solito il backend sarà anche in grado di eseguire operazioni sulla blockchain.

Un buon esempio per questo tipo di DApp è un ponte cross-chain dove è necessario un componente offchain per comunicare con entrambi i contratti intelligenti in diverse blockchain per eseguire il trasferimento di asset.

Vulnerabilità Web2

Le vulnerabilità Web2 influenzano ancora questo tipo di applicazioni anche se il loro impatto può variare:

  • Le vulnerabilità lato client hanno un impatto maggiore poiché nei DApps Web3 il client è solitamente colui che esegue le operazioni sulla blockchain tramite un wallet. Ciò significa che attacchi come XSS che riescono a eseguire codice JS sul lato client o che manomettano il contenuto della pagina possono avere un impatto maggiore poiché possono interagire con il wallet e convincere l'utente a eseguire operazioni indesiderate sulla blockchain.
  • Nota che di solito anche in questo tipo di applicazioni il client può ancora rivedere le operazioni prima di firmarle con il wallet. Tuttavia, se l'attaccante è in grado di manomettere il contenuto della pagina, può convincere l'utente a firmare una transazione che eseguirà un'operazione indesiderata sulla blockchain.
  • Le vulnerabilità lato server sono ancora presenti nei DApps che si basano su un server backend. L'impatto di queste vulnerabilità dipenderà dall'architettura del DApp. Tuttavia, potrebbero comunque essere molto problematiche poiché un attaccante potrebbe trovare nel backend chiavi dell'azienda per accedere ai fondi dei contratti intelligenti, o potrebbe eseguire un takeover dell'account che potrebbe consentirgli di rubare fondi o NFT dagli utenti.

Naturalmente, se il DApp non utilizza un backend o il backend utilizzato offre solo dati di catena pubblica o pagine statiche, la superficie di attacco del DApp è ridotta.

Superficie di attacco Web3

Anche se in generale un DApp ha una superficie di attacco ridotta poiché diversi controlli di sicurezza vengono sempre eseguiti sulla blockchain, ci sono ancora alcuni vettori di attacco che possono essere sfruttati da un attaccante.

Potrebbe essere possibile raggruppare le vulnerabilità dei DApps web3 nelle seguenti categorie:

  • Transazioni On-Chain mal gestite: API di transazione formattate in modo errato o senza restrizioni, mancanza di logica di attesa della risposta e conferma del blocco, esposizione di dati sensibili e gestione impropria di transazioni fallite, annullate o di tipo interno che consentono iniezioni di calldata malevole.

  • Attacchi Backend guidati da Smart Contract: memorizzazione o sincronizzazione di dati sensibili tra contratti e database senza convalida, emissioni di eventi non controllate o indirizzi di contratti, e vulnerabilità di contratto sfruttabili che possono avvelenare la logica del backend.

  • Operazioni di Crypto-Asset difettose: elaborazione errata di diversi tipi di token (nativo vs. ERC-20), ignorare la precisione decimale, trasferimenti falliti o transazioni interne, e accettare token falsi, deflazionari, di ribilanciamento o soggetti a slippage senza convalida, abilitando iniezioni di payload tramite metadati del token.

Alcuni esempi da questo post:

Spreco di Fondi: Forzare il backend a eseguire transazioni

Nello scenario Wasted Crypto in Gas via Unrestricted API, l'attaccante può forzare il backend a chiamare funzioni di un contratto intelligente che consumeranno gas. L'attaccante, inviando semplicemente un numero di conto ETH e senza limiti, costringerà il backend a chiamare il contratto intelligente per registrarlo, il che consumerà gas.

DoS: Scarsa gestione del tempo delle transazioni

Nello scenario Poor Transaction Time Handling Leads to DoS, si spiega che poiché il backend manterrà la richiesta HTTP aperta fino a quando non viene eseguita una transazione, un utente può facilmente inviare diverse richieste HTTP al backend, che consumeranno tutte le risorse del backend e porteranno a un DoS.

Desincronizzazione Backend<-->Blockchain - Condizione di gara

Nello scenario Poor Transaction Time Handling Leads to Race Condition, si spiega che in un gioco era possibile per l'utente inviare una richiesta di prelievo al backend che invierà all'utente le sue monete, ma mentre la transazione era ancora in fase di elaborazione, l'utente era in grado di utilizzare quelle monete per acquistare oggetti nel gioco, ottenendoli gratuitamente.

Un altro esempio potrebbe essere quello di poter utilizzare le stesse monete per acquistare diversi oggetti poiché il backend sta immediatamente dando l'oggetto all'utente senza attendere che la transazione venga confermata e quindi attendere che il saldo dell'utente nella blockchain venga ridotto.

Validazione dell'indirizzo del contratto intelligente

Nello scenario Bridge Backend Lacks Smart Contract Address Validation si spiega come il backend controllava l'indirizzo del contratto intelligente, quindi era possibile per un attaccante distribuire un contratto intelligente falso, mettere fondi su di esso, inviare la transazione al backend e il backend penserà che l'utente abbia inviato fondi al vero contratto intelligente e darà all'utente i token.

Mal gestione delle classi di asset

Nello scenario Mishandling of Asset Classes, si spiega che il backend ha confuso un NFT truffa in un indirizzo con 1 MATIC, consentendo quindi all'attaccante di inviare centinaia di NFT truffa all'indirizzo e ottenere 1 MATIC dalla piattaforma per ciascuno di essi.

Riferimenti

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