DApps - Aplicaciones Descentralizadas

Reading time: 6 minutes

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

¿Qué es un DApp?

Un DApp es una aplicación descentralizada que se ejecuta en una red peer-to-peer, en lugar de estar alojada en un servidor centralizado. Los DApps se construyen típicamente sobre tecnología blockchain, lo que debería permitir la transparencia, seguridad e inmutabilidad de los datos.

Arquitectura de DApp Web3

Según este post, hay 3 tipos diferentes de arquitectura de DApps Web3:

DApps "sin API"

Estos DApps se construyen sobre una blockchain y no dependen de ninguna API o backend centralizado. Se podría pensar que la blockchain es el backend real de la aplicación. Son totalmente descentralizados y se pueden acceder directamente a través de la blockchain.

Para interactuar con la blockchain, el cliente generalmente usará una billetera. La billetera firmará las transacciones y las enviará a la blockchain. El cliente también podría usar un nodo para leer datos de la blockchain.

DApps "habilitadas para API"

Estos DApps se construyen sobre una blockchain pero también dependen de APIs centralizadas, generalmente para recopilar información. Son mayormente descentralizados porque, incluso si dependen de una API centralizada, la funcionalidad principal del DApp sigue estando en la blockchain. La comunicación del cliente con la blockchain generalmente se realiza a través de una billetera.

Un buen ejemplo de este tipo de DApp es una aplicación de acuñación de NFT. El servidor permite subir las imágenes, pero la acuñación la realiza el cliente a través de una billetera.

DApps "a gran escala"

Estos DApps se construyen sobre una blockchain pero también dependen de APIs centralizadas y servidores backend. Podrían ser parcialmente descentralizados, ya que el cliente podría realizar operaciones en la blockchain usando una billetera. Sin embargo, generalmente el backend también podrá realizar operaciones en la blockchain.

Un buen ejemplo de este tipo de DApp es un puente entre cadenas donde se necesita un componente fuera de la cadena para comunicarse con ambos contratos inteligentes en diferentes blockchains para realizar la transferencia de activos.

Vulnerabilidades de Web2

Las vulnerabilidades de Web2 aún afectan a este tipo de aplicaciones, aunque su impacto puede variar:

  • Las vulnerabilidades del lado del cliente tienen un impacto aumentado, ya que en los DApps Web3 el cliente suele ser quien realiza las operaciones en la blockchain a través de una billetera. Esto significa que ataques como XSS que logran ejecutar código JS en el lado del cliente o que manipulan el contenido de la página pueden tener un mayor impacto, ya que pueden interactuar con la billetera y convencer al usuario de realizar operaciones no deseadas en la blockchain.
  • Tenga en cuenta que, generalmente, incluso en este tipo de aplicaciones, el cliente aún puede revisar las operaciones antes de firmarlas con la billetera. Sin embargo, si el atacante puede manipular el contenido de la página, puede convencer al usuario de firmar una transacción que realizará una operación no deseada en la blockchain.
  • Las vulnerabilidades del lado del servidor aún están presentes en los DApps que dependen de un servidor backend. El impacto de estas vulnerabilidades dependerá de la arquitectura del DApp. Sin embargo, aún podrían ser muy problemáticas, ya que un atacante podría encontrar en el backend claves de la empresa para acceder a los fondos de los contratos inteligentes, o podría realizar un takeover de cuenta que podría permitirles robar fondos o NFTs de los usuarios.

Por supuesto, si el DApp no utiliza un backend o el backend utilizado solo ofrece datos de cadena pública o páginas estáticas, la superficie de ataque del DApp se reduce.

Superficie de ataque de Web3

Incluso si, en general, un DApp tiene una superficie de ataque reducida, ya que siempre se realizan varias verificaciones de seguridad en la blockchain, todavía hay algunos vectores de ataque que pueden ser explotados por un atacante.

Es posible agrupar las vulnerabilidades de los DApps web3 en las siguientes categorías:

  • Transacciones en cadena mal manejadas: APIs de transacción mal formateadas o sin restricciones, falta de lógica de espera de respuesta y confirmación de bloque, exposición de datos sensibles y manejo inadecuado de transacciones fallidas, revertidas o de tipo interno que permiten inyecciones de datos maliciosos.

  • Ataques impulsados por contratos inteligentes en el backend: almacenamiento o sincronización de datos sensibles entre contratos y bases de datos sin validación, emisiones de eventos no verificadas o direcciones de contratos, y vulnerabilidades de contratos explotables que pueden envenenar la lógica del backend.

  • Operaciones de criptoactivos defectuosas: procesamiento incorrecto de diferentes tipos de tokens (nativos vs. ERC-20), ignorar la precisión decimal, transferencias fallidas o transacciones internas, y aceptar tokens falsos, deflacionarios, de rebase o propensos a deslizamientos sin validación, habilitando inyecciones de carga útil a través de metadatos de tokens.

Algunos ejemplos de este post:

Desperdicio de fondos: Forzar al backend a realizar transacciones

En el escenario Cripto desperdiciada en gas a través de API sin restricciones, el atacante puede forzar al backend a llamar funciones de un contrato inteligente que consumirán gas. El atacante, solo enviando un número de cuenta ETH y sin límites, forzará al backend a llamar al contrato inteligente para registrarlo, lo que consumirá gas.

DoS: Mal manejo del tiempo de transacción

En el escenario El mal manejo del tiempo de transacción lleva a DoS, se explica que, debido a que el backend mantendrá la solicitud HTTP abierta hasta que se realice una transacción, un usuario puede enviar fácilmente varias solicitudes HTTP al backend, lo que consumirá todos los recursos del backend y llevará a un DoS.

Desincronización Backend<-->Blockchain - Condición de carrera

En el escenario El mal manejo del tiempo de transacción lleva a una condición de carrera, se explica que en un juego era posible que el usuario enviara una solicitud de retiro al backend, que enviará al usuario sus monedas, pero mientras la transacción aún se estaba procesando, el usuario pudo usar esas monedas para comprar artículos en el juego, obteniéndolos gratis.

Otro ejemplo podría ser poder usar las mismas monedas para comprar diferentes artículos, ya que el backend está dando inmediatamente el artículo al usuario sin esperar a que la transacción sea confirmada y, por lo tanto, sin esperar a que el saldo del usuario en la blockchain se reduzca.

Validación de dirección de contrato inteligente

En el escenario El backend del puente carece de validación de dirección de contrato inteligente, se explica cómo el backend estaba verificando la dirección del contrato inteligente, por lo que era posible que un atacante desplegara un contrato inteligente falso, pusiera fondos en él, enviara la transacción al backend y el backend pensaría que el usuario envió fondos al contrato inteligente real y le daría al usuario los tokens.

Manejo inadecuado de clases de activos

En el escenario Manejo inadecuado de clases de activos, se explica que el backend confundió un NFT de estafa en una dirección con 1 MATIC, permitiendo así que el atacante enviara cientos de NFTs de estafa a la dirección y obtuviera 1 MATIC de la plataforma por cada uno de ellos.

Referencias

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