DApps - Aplicações Descentralizadas

Reading time: 5 minutes

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

O que é um DApp?

Um DApp é uma aplicação descentralizada que opera em uma rede peer-to-peer, em vez de ser hospedada em um servidor centralizado. Os DApps são tipicamente construídos sobre tecnologia blockchain, o que deve permitir transparência, segurança e imutabilidade dos dados.

Arquitetura de DApp Web3

De acordo com este post, existem 3 tipos diferentes de arquitetura de DApps Web3:

DApps "Sem API"

Esses DApps são construídos sobre uma blockchain e não dependem de APIs ou backend centralizados. Você pode pensar que a blockchain é o verdadeiro backend da aplicação. Eles são totalmente descentralizados e podem ser acessados diretamente através da blockchain.

Para interagir com a blockchain, o cliente geralmente usará uma carteira. A carteira assinará as transações e as enviará para a blockchain. O cliente também pode usar um nó para ler dados da blockchain.

DApps "Habilitados para API"

Esses DApps são construídos sobre uma blockchain, mas também dependem de APIs centralizadas, geralmente para coletar informações. Eles são principalmente descentralizados porque, mesmo que dependam de uma API centralizada, a funcionalidade principal do DApp ainda está na blockchain. A comunicação do cliente com a blockchain geralmente é feita através de uma carteira.

Um bom exemplo desse tipo de DApp é um aplicativo de mintagem de NFT. O servidor permite o upload das imagens, mas a mintagem é feita pelo cliente através de uma carteira.

DApps "Em Larga Escala"

Esses DApps são construídos sobre uma blockchain, mas também dependem de APIs centralizadas e servidores backend. Eles podem ser parcialmente descentralizados, pois o cliente pode ser capaz de realizar operações na blockchain usando uma carteira. No entanto, geralmente o backend também será capaz de realizar operações na blockchain.

Um bom exemplo desse tipo de DApp é uma ponte cross-chain onde um componente offchain é necessário para comunicar-se com contratos inteligentes em diferentes blockchains para realizar a transferência de ativos.

Vulnerabilidades do Web2

As vulnerabilidades do Web2 ainda afetam esse tipo de aplicação, embora seu impacto possa variar:

  • As vulnerabilidades do lado do cliente têm um impacto aumentado, pois nos DApps Web3 o cliente geralmente é quem realiza as operações na blockchain através de uma carteira. Isso significa que ataques como XSS que conseguem executar código JS no lado do cliente ou que alteram o conteúdo da página podem ter um impacto maior, pois podem interagir com a carteira e convencer o usuário a realizar operações indesejadas na blockchain.
  • Note que geralmente, mesmo nesses tipos de aplicações, o cliente ainda pode revisar as operações antes de assiná-las com a carteira. No entanto, se o atacante conseguir alterar o conteúdo da página, pode convencer o usuário a assinar uma transação que realizará uma operação indesejada na blockchain.
  • As vulnerabilidades do lado do servidor ainda estão presentes nos DApps que dependem de um servidor backend. O impacto dessas vulnerabilidades dependerá da arquitetura do DApp. No entanto, elas ainda podem ser muito problemáticas, pois um atacante pode encontrar no backend chaves da empresa para acessar os fundos de contratos inteligentes ou pode realizar uma tomada de conta que pode permitir que eles roubem fundos ou NFTs dos usuários.

Claro, se o DApp não estiver usando um backend ou se o backend usado oferecer apenas dados de cadeia pública ou páginas estáticas, a superfície de ataque do DApp é reduzida.

Superfície de ataque do Web3

Mesmo que, em geral, um DApp tenha uma superfície de ataque reduzida, pois várias verificações de segurança são sempre feitas na blockchain, ainda existem alguns vetores de ataque que podem ser explorados por um atacante.

Pode ser possível agrupar as vulnerabilidades dos DApps web3 nas seguintes categorias:

  • Transações On-Chain Mal Gerenciadas: APIs de transação mal formatadas ou sem restrições, falta de lógica de espera de resposta e confirmação de bloco, exposição de dados sensíveis e manuseio inadequado de transações falhadas, revertidas ou tipadas internamente que permitem injeções de calldata maliciosas.

  • Ataques de Backend Impulsionados por Contratos Inteligentes: armazenar ou sincronizar dados sensíveis entre contratos e bancos de dados sem validação, emissões de eventos não verificadas ou endereços de contrato, e vulnerabilidades de contrato exploráveis que podem envenenar a lógica do backend.

  • Operações de Cripto-Ativos Defeituosas: processamento incorreto de diferentes tipos de tokens (nativo vs. ERC-20), ignorando precisão decimal, transferências falhadas ou transações internas, e aceitando tokens falsos, deflacionários, de rebase ou propensos a slippage sem validação, permitindo injeções de payload via metadados de token.

Alguns exemplos de este post:

Desperdício de Fundos: Forçando o backend a realizar transações

No cenário Wasted Crypto in Gas via Unrestricted API, o atacante pode forçar o backend a chamar funções de um contrato inteligente que consumirão gás. O atacante, apenas enviando um número de conta ETH e sem limites, forçará o backend a chamar o contrato inteligente para registrá-lo, o que consumirá gás.

DoS: Tempo de manuseio de transação ruim

No cenário Poor Transaction Time Handling Leads to DoS, é explicado que, como o backend manterá a solicitação HTTP aberta até que uma transação seja realizada, um usuário pode facilmente enviar várias solicitações HTTP para o backend, o que consumirá todos os recursos do backend e levará a um DoS.

Desincronização Backend<-->Blockchain - Condição de corrida

No cenário Poor Transaction Time Handling Leads to Race Condition, é explicado que em um jogo era possível para o usuário enviar uma solicitação de retirada para o backend, que enviaria ao usuário suas moedas, mas enquanto a transação ainda estava sendo processada, o usuário conseguiu usar essas moedas para comprar itens no jogo, obtendo-os de graça.

Outro exemplo poderia ser a capacidade de usar as mesmas moedas para comprar diferentes itens, já que o backend está imediatamente dando o item ao usuário sem esperar que a transação seja confirmada e, portanto, sem esperar que o saldo do usuário na blockchain seja reduzido.

Validação de Endereço de Contrato Inteligente

No cenário Bridge Backend Lacks Smart Contract Address Validation, é explicado como o backend estava verificando o endereço do contrato inteligente, então era possível para um atacante implantar um contrato inteligente falso, colocar fundos nele, enviar a transação para o backend e o backend pensaria que o usuário enviou fundos para o contrato inteligente real e daria ao usuário os tokens.

Manuseio inadequado de Classes de Ativos

No cenário Mishandling of Asset Classes, é explicado que o backend confundiu um NFT de golpe em um endereço com 1 MATIC, permitindo assim que o atacante enviasse centenas de NFTs de golpe para o endereço e recebesse 1 MATIC da plataforma por cada um deles.

Referências

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