La carrera por WEB3 ha comenzado. Los capitalistas de riesgo, las nuevas empresas de criptomonedas, los ingenieros y los visionarios están desarrollando WEB3 (o Web 3.0) con tecnología blockchain. Surgió una nueva frontera, más democrática, descentralizada, independiente e ideal para la recuperación de datos.

Pero, ¿es todo tan perfecto en cuanto a descentralización y seguridad de las infraestructuras? No, y numerosos casos de ataques man-in-the-middle son prueba de ello.

Pero para solucionar el tema de la seguridad, recordemos qué es WEB3. El concepto central de WEB3 es resolver los problemas de seguridad causados ​​por la centralización y brindar a las personas autoridad sobre sus datos e identificación. Entonces, ¿a qué nivel de tecnología ocurren estos desafortunados incidentes de brechas de seguridad en su infraestructura de cadena de bloques? Averigüémoslo.

Para centrarse en los aspectos internos de WEB3, las tecnologías como EVM, Solidity y JavaScript aún juegan un papel importante. Sin embargo, usamos proveedores de nodos y proveedores de API WEB3 cuando hablamos de las funciones de back-end.

Proveedores de nodos son empresas que le permiten utilizar sus servicios en lugar de ejecutar sus nodos. Esto es muy conveniente porque en lugar de configurar su nodo y experimentar todo el estrés y los gastos que conlleva, puede enviar sus solicitudes de transacciones dApp a través de Internet al proveedor del nodo. Si está interesado en el desarrollo de contratos inteligentes, puede usar uno o dos proveedores de nodos (para redundancia).

Hay muchos Proveedores de API WEB3; sin embargoen muchos casos, estas empresas trabajan con nodos entre bastidores. Con estas herramientas aplicadas, puede obtener cualquier dato precompilado y precalculado en la cadena.

Además, es sencillo establecer una comunicación e interacción fiables entre diferentes aplicaciones a través de estas API de WEB3. Además, las API de calidad mantienen la codificación consistente y estable. Por lo tanto, confiamos más en las API de WEB3 confiables cuando creamos aplicaciones.

💡 Diferencia entre proveedores de nodos y proveedores de API WEB3: El proveedor WEB3 permite que su aplicación se comunique con un nodo de cadena de bloques mediante el envío de solicitudes JSON-RPC a un servidor. Los proveedores de servicios de nodos ejecutan clientes de nodos distribuidos detrás de escena y les permiten escribir y leer desde una cadena de bloques usando una clave API.

¿Cuál es la amenaza de seguridad para los desarrolladores de dApps?

Los nodos siguen siendo tecnologías relativamente primitivas, pero siguen siendo valiosas. Por ejemplo, un nodo WEB3 no puede decirle qué han depositado los usuarios en sus cuentas. Además de simplemente proporcionar información de blockchain sin procesar, los nodos no pueden procesar múltiples contratos inteligentes. Además, los nodos tienen capacidades limitadas y solo pueden procesar una cadena. Afortunadamente, hay API disponibles para ayudarlo a sortear esta limitación.

Las API definen y estandarizan las interacciones de las aplicaciones, lo que le permite utilizar datos de blockchain sin procesar. Esta es la razón por la que las API de WEB3 son útiles para el desarrollo de dApp. Las API de WEB3 son un componente clave en el desarrollo de dApps; además de ofrecer una interfaz simple, permiten que una pieza de software interactúe con otras aplicaciones. Debido a que las API confiables permiten una codificación consistente en un entorno estable, los desarrolladores de dApp no ​​necesitan reinventar la rueda.

Además, al usar estas API de proveedores WEB3, puede vincular fácilmente a los nodos. Por lo tanto, no tiene que preocuparse por conectarse a los nodos cuando usa estas API. Al interactuar con estos proveedores, también puede recibir todo tipo de valiosos datos en cadena precalculados y precompilados.

Pero tales servicios no cierran del todo las solicitudes de los desarrolladores en los planes de seguridad y, en la mayoría de los casos, hay que pagar por adelantado por su uso.

El hecho es que cada vez hay más casos de dApps pirateados mediante el ataque man-in-the-middle que mencionamos anteriormente.

Esto es cuando un atacante, utilizando vulnerabilidades en los servidores DNS (por ejemplo), cambió los servidores para atender el tráfico de puntos finales jsonrpc.

Se sabe que una víctima han perdido 16.5 WBTC (~$350,840). Y alrededor de 23 proyectos de criptomonedas ya han encontrado un ataque de DNS similar.

Una solución muy simple le permite protegerse de tales ataques de intermediarios. Y volveremos a esto.

Además, si tiene un equipo de desarrollo, puede seguir su propio camino e intentar construir su solución, pero necesita un equipo súper capacitado de personas con ideas afines para que funcione.

La dificultad de este proceso es que puedes sobrestimar significativamente tu fuerza. Una tarea que parece fácil plantea muchas preguntas, que se resuelven con muchos años de experiencia en el trabajo. Por lo tanto, si tiene mucho tiempo y recursos, debe aceptar este camino.

Violación de 3 principios principales de blockchain en WEB3

Así que tomemos un respiro ahora y veamos los desafíos de seguridad actuales en el mundo WEB3 desde una perspectiva de infraestructura.

Los principios fundamentales de blockchain son

  • descentralización
  • transparencia
  • falta de confianza

Pero, ¿funciona en la práctica? Echa un vistazo a la arquitectura dApp más popular.

Arquitectura dApp más popular

Podemos ver que los usuarios en el front-end están enviando solicitudes a proveedores de JSON-RPC (esto podría ser Infura, Alchemy, Quicknode, etc.).

Entonces, las solicitudes se enrutan a un entorno compartido donde no tenemos control sobre la transformación de datos en la puerta de enlace API, el motor de almacenamiento en caché, los nodos de blockchain o cualquier otra cosa.

Y aquí es donde surge el primer problema porque un entorno compartido significa que muchos usuarios, bots y piratas informáticos, en particular, trabajan en el mismo entorno. Esta es una verdadera caja negra para el desarrollador que atrae demasiado la atención de los atacantes.

Bueno, este enfoque contradice los 3 principios de WEB3 porque:

  1. Centraliza el acceso a la Blockchain, pasando todo por un entorno compartido;
  2. No es transparente: no podemos verificar las respuestas de dicha API;
  3. Por lo tanto, no puede llamarse verdadera desconfianza ya que los problemas de seguridad de dicha infraestructura se basan simplemente en la confianza. Compruébelo usted mismo en el siguiente diagrama.
Problemas de arquitectura de dApp

El segundo problema es que la versión de infraestructura descrita permite ataques man-in-the-middleque los delincuentes utilizan periódicamente.

Los siguientes servicios pueden ser atacados:

    • Registradores de dominio o DNS
    • Proveedores de JSON-RPC
    • Cualquier servicio agregado de terceros

Un clúster autohospedado de nodos de cadena de bloques es la única solución

¿Pero hay una solución? Sí: entorno local configurado.

En primer lugar, utiliza un clúster autohospedado de nodos de cadena de bloques. Todos los nodos se inicializan desde el génesis oficial y se sincronizan mediante p2p. Esto asegura la consistencia de los datos.

Los nodos deben actualizarse periódicamente con instantáneas reducidas para ejecutarse de la manera más eficiente posible. La solución ideal es crear automáticamente nuevos nodos a partir de la instantánea reducida al hacer zoom. Si inicializa el nodo desde cero, este enfoque le permite obtener un nuevo nodo en 30 minutos en lugar de varios días.

Otro punto crítico es la actualización automática del software blockchain después de su lanzamiento; esto también se puede hacer. Lo principal es crear una instantánea con la nueva versión (ya que a veces puede requerir algunas operaciones de datos, lo que puede llevar tiempo), y luego los nuevos nodos deberían comenzar automáticamente con la nueva instantánea y el software actualizado.

A continuación se muestra un diagrama de infraestructura que resuelve la mayoría de los problemas descritos.

solución de infraestructura dApp

También es importante monitorear el estado de sincronización y excluir aquellos nodos que están detrás del flujo ascendente. Esto se puede hacer, por ejemplo, con la ayuda de controles de salud.

Además del hecho de que el acceso puede estar limitado por la dirección IP, vale la pena mencionar que el viejo token JWT puede proteger contra el registro de dominio o los ataques de DNS. El token JWT se integra fácilmente en web3js y otras bibliotecas y debe implementarse en el lado de la puerta de enlace API en nuestro clúster de blockchain.

De esta manera, hacemos que el punto final de blockchain sea seguro y descentralizado.

Resumiendo

Web3 todavía está en sus primeras etapas. Pero la carrera por la descentralización ya ha comenzado. Y podrá ver que las aplicaciones más seguras probablemente sean las que utilizan los enfoques más innovadores y de código abierto.

Y por lo tanto, no debe ignorar los principios básicos de WEB3 porque entonces su dApp recién creada no brindará seguridad a otros participantes. La única opción disponible actualmente es un grupo autónomo de nodos de cadena de bloques distribuidos geográficamente.

Autor:

Daniel Yavorovich

Co-Fundador y CTO en RPCFast y disnix

Descargo de responsabilidad: Las opiniones de nuestros escritores son exclusivamente suyas y no reflejan la opinión de CryptoSlate. Ninguna de la información que lea en CryptoSlate debe tomarse como un consejo de inversión, ni CryptoSlate respalda ningún proyecto que pueda mencionarse o vincularse en este artículo. La compra y el comercio de criptomonedas debe considerarse una actividad de alto riesgo. Realice su propia diligencia debida antes de tomar cualquier medida relacionada con el contenido de este artículo. Finalmente, CryptoSlate no se hace responsable si pierde dinero comerciando con criptomonedas.

Share.
Leave A Reply