5 consejos de auditoría de seguridad de MSQ Snap y Consensys Diligence

Consensys Diligence es una rama de auditoría dentro de Consensys Software Inc., reconocida por su incomparable experiencia en la realización de auditorías exhaustivas en un espectro que abarca Solidity, Cairo y una variedad de bibliotecas ZK. El equipo de Diligence lidera los estándares de auditoría y seguridad para MetaMask Snaps y trabaja estrechamente con el equipo de MetaMask para garantizar la seguridad de las funciones de la wallet. Además, el equipo de Diligence es pionero en el desarrollo de herramientas de seguridad y soluciones de fuzzing continuo de vanguardia, validadas en los entornos de producción más exigentes.

El proyecto MSQ fue lanzado recientemente en MetaMask Snaps Store. MSQ es un Snap que permite a los usuarios interactuar con la red Internet Computer, gestionar tokens basados en IC, autorizar de forma segura dentro de dapps basadas en IC y pagar por bienes y servicios digitales. En esencia, es una crypto wallet integrada con MetaMask, diseñada específicamente para Internet Computer con funciones distintivas de autorización y pagos.

Juntos, los equipos de Diligence y MSQ identificaron cinco áreas clave para abordar en este artículo: Documentación, Diseño de Software, Código, Cadena de Suministro y Correcciones. Se presenta una lista de prácticas empleadas por el equipo de MSQ durante el desarrollo, junto con comentarios del equipo de Diligence que explican los beneficios de seguridad de estas prácticas, convirtiéndolo en un recurso útil para cualquier persona que desarrolle un Snap para MetaMask Wallet o cualquier otro sistema crítico de seguridad sujeto a posibles auditorías. ¡Comencemos!

1. Crea documentación por capas

La documentación transforma los conceptos que tienes en mente en algo visible para los demás. La documentación por capas ayuda al lector a comprender estos conceptos de la manera que tú deseas, sumergiéndolo gradualmente en el contexto. Evidentemente, cuanto más clara sea la documentación, más amplia será la perspectiva que puede ofrecer sobre tu proyecto y mejor te entenderán los demás.

Definimos las capas de documentación en orden inverso al que un lector normalmente accedería a ellas, con cada capa ofreciendo un mayor nivel de abstracción. De esta manera, los lectores que comiencen con el panorama general irán profundizando progresivamente en los detalles.

1.1 Código

La fuente de información definitiva sobre tu software es el propio código, que sirve como capa fundamental de tu documentación. Si bien contiene toda la información necesaria, procesar dicha información resulta difícil. Cuanto más limpio sea el código, más fácil será extraer de él las abstracciones de alto nivel. Sin embargo, en sistemas reales, estas abstracciones quedan ocultas detrás de las complejas interacciones entre los componentes del sistema, semanas de deuda técnica y soluciones rápidas e improvisadas.

Por eso, ante todo, conviene proteger a quienes leen tu código de ser confundidos por las partes más complicadas del sistema. La mejor manera de lograrlo es reducir la carga cognitiva necesaria para leer el código. Algunas estrategias incluyen:

• Hacer que tu código sea navegable, permitiendo una fácil exploración en IDEs.

• Usar nombres descriptivos para clarificar el propósito y la funcionalidad de los elementos del código.

• Emplear lenguajes fuertemente tipados para definir formatos de datos claros.

El Snap de MSQ y los frontends de la dapp están desarrollados en TypeScript, lo que ha prevenido numerosos errores potenciales, en contraste con los problemas del JavaScript puro. De manera similar, nuestro backend utiliza Rust, conocido por su robusto sistema de tipos. Además, MSQ Snap exporta una serie de métodos que pueden ser ejecutados por una aplicación de terceros. Sin embargo, no usamos strings para identificar estos métodos; en su lugar, usamos constantes. Tenemos un objeto constante como este:

export const SNAP_METHODS = {
  protected: {
    identity: {
      login: "protected_identity_login",
      ...
    },
    icrc1: {      
	    ...
    },
    ...
  },
  public: {
    identity: {
      sign: "public_identity_sign",			
      ...
    },
    ...
  },
};
Copiar

En el código, este objeto constante puede usarse como guía para acceder al método correcto, y los lectores pueden entender mucho sobre dicho método a partir de su identificador en el objeto. Por ejemplo, el método SNAP_METHODS.protected.identity.login solo puede ser ejecutado por la dapp complementaria de MSQ y permite al usuario iniciar sesión. Este enfoque mejora la claridad del código y simplifica la refactorización, ya que los cambios en los nombres de los métodos se gestionan de forma centralizada en lugar de actualizarse en múltiples ubicaciones.

Para hacer coincidir los nombres de los métodos, usamos una expresión switch amplia con ramas como esta:

case SNAP_METHODS.protected.identity.login: {
  result = protected_handleIdentityLogin(req.params.body);
  break;
  }
Copiar

Como puedes ver, es muy difícil malinterpretar algo al leer esto: todo está nombrado con precisión, sin dejar lugar a la imaginación.

Comentario de Diligence El tiempo es un factor crítico. Mientras que los desarrolladores tienen semanas para comprender una base de código, los ingenieros de seguridad a menudo solo tienen días para identificar riesgos. Esta limitación pone de relieve la importancia de reducir la carga cognitiva en el código, una práctica que beneficia tanto la eficiencia del desarrollador como la seguridad.

Lo que podemos aprender del código de MSQ es que un código claro y navegable con nombres descriptivos y tipado fuerte (como TypeScript) reduce los malentendidos, una fuente común de vulnerabilidades.

Pero recuerda, ¡las anotaciones de tipo en TypeScript solo se verifican en tiempo de compilación! Para cualquier dato que se procese o analice en tiempo de ejecución (RPC, JSON, ...) se requieren verificaciones adicionales de tipos, formatos de datos y límites. Para este propósito, MSQ utiliza de forma elegante zod, una biblioteca de validación de esquemas con inferencia de tipos estáticos orientada a TypeScript, y recomendamos a los equipos que sigan ese enfoque.

MSQ encontró el equilibrio perfecto al hacer claras las intenciones del código mediante la cantidad adecuada de comentarios. Esta claridad ayuda a los investigadores de seguridad a comprender rápidamente el "hilo conductor" y los conceptos clave de la base de código. Al escribir código fácil de entender, los desarrolladores aumentan significativamente la efectividad de las revisiones de seguridad rápidas.

1.2 Comentarios en el código

Creemos que comentar no significa cubrir el 100% de tu código. Es fundamental anotar las partes que son complejas o están mal escritas. Áreas como expresiones regulares, criptografía y manipulaciones de strings se benefician especialmente de comentarios claros.

Por ejemplo, en MSQ tenemos una función que escapa posibles caracteres de control de Markdown en un string. Su cuerpo es una sola línea de código, pero incluye coincidencia de expresiones regulares, por lo que describimos su funcionalidad en un comentario:

/**
 * Escapes Markdown control characters, newline characters, and backticks in a string.
 * This function takes a string and returns a new string with all Markdown control characters, newline characters, and backticks escaped.
 * Escaping is done by prefixing each control character and backtick with a backslash (`\\`), and newline characters are replaced with `\\\\n`.
 *
 * Control characters include: `{`, `}`, `[`, `]`, `(`, `)`, `#`, `!`, `|`, `\\`, and `` ` ``.
 * Newline characters are replaced with a visible escape sequence (`\\\\n`) for demonstration or specific formatting needs.
 * Since all newlines are escaped, list creating characters `-`, `+` and `.` are allowed.
 * Text styling characters `*`, `_` are also allowed
 *
 * @param {string} text The string to be escaped.
 * @return {string} The escaped string, safe to be used in Markdown without triggering formatting, with newline characters visually represented and backticks escaped.
 */
export function escapeMarkdown(text: string) {
  return text.replace(/([{}\\[\\]()#!|\\\\`])|\\n/g, (match) => (match === "\\n" ? "\\\\n" : "\\\\" + match));
}
Copiar

Si no tienes inconveniente en usar IA en tu flujo de trabajo, ChatGPT es excelente para generar buenos comentarios para este tipo de funciones utilitarias rápidamente (solo verifica el resultado que proporciona).

Comentario de Diligence Como revisores de seguridad, usamos los comentarios de las funciones como mapas de ruta a través de código desconocido. Recuerda que solo disponemos de cierto tiempo para revisar el código, y cuando los comentarios no coinciden con la implementación, no solo es confuso, es una señal de alerta.

A menudo revelan que la función o su descripción se desvían de la especificación, lo que indica posibles vulnerabilidades. Puede que una función omita verificaciones prometidas o maneje datos de forma inesperada, lo que puede tener consecuencias graves.

Por eso, mantén tus comentarios concisos y precisos, de manera similar a como lo hace MSQ en su código. Los comentarios en línea no son solo notas; son balizas que nos guían a través de tu código, y las discrepancias son indicios de que algo podría estar mal.

1.3 Documentación a nivel de sistema

Después de asegurarte de que tu código y sus complejidades están bien documentados, el siguiente paso es describir la arquitectura del sistema. Esto implica detallar las interacciones entre componentes, y los protocolos, algoritmos y estructuras de datos que emplea tu software. Esta capa utiliza principalmente formatos legibles por humanos, como texto y diagramas, en lugar de código.

La documentación del sistema de MSQ incluye una descripción general de la arquitectura y una guía de integración. Estos documentos, repletos de descripciones textuales, ejemplos y diagramas, aclaran cómo interactúan las diferentes partes del sistema.

Los diagramas de secuencia son invaluables para visualizar las interacciones entre componentes. Recomendamos usar diagrams.net (draw.io), una herramienta gratuita que ha demostrado ser versátil en diversos proyectos.

Comentario de Diligence A diferencia de los comentarios en línea que detallan funciones, la documentación del sistema ofrece una vista panorámica que revela el panorama completo de una aplicación. Esta perspectiva es crucial para detectar problemas entre componentes o vulnerabilidades en los flujos de usuario que a menudo son invisibles a nivel de código.

Piensa en una revisión de seguridad como una partida de Command & Conquer. Comienzas con un mapa mayormente oculto. A medida que exploras, la documentación del sistema actúa como unidades de exploración, descubriendo la arquitectura completa: permisos, interacciones Snap-dApp, interacciones de usuario. Esta visión general en desarrollo permite a los revisores rastrear los recorridos del usuario, como seguir los movimientos de unidades en el juego, para identificar rutas que podrían eludir la seguridad.

Además, una documentación del sistema completa debe contener observaciones relevantes para la seguridad y, en el mejor de los casos, los resultados de un ejercicio de modelado de amenazas. Proporcionar una visión clara de los componentes principales, las interacciones, los riesgos, los actores y los flujos de usuario típicos. Esto ayuda a los revisores a centrarse en las áreas de alta prioridad y detectar desviaciones de la especificación.

Para los desarrolladores, una buena documentación del sistema no es solo papeleo; es un mapa compartido que guía las estrategias ofensivas y defensivas, transformando las revisiones de seguridad de sondeos a ciegas en operaciones estratégicas.

1.4 Documentación del panorama general

Esta capa incluye una amplia variedad de materiales, como artículos, landing pages, publicaciones de blog, videos de demostración y más.

Esta información trata principalmente sobre aspectos de negocio, pero responde en gran medida a la pregunta "¿Qué?", mientras que todas las capas anteriores respondían a la pregunta "¿Cómo?" con diferentes niveles de detalle.

Un recién llegado probablemente conocerá tu proyecto a través de este tipo de material, por lo que mantener esta capa lo más simple y visual posible es una buena idea. Además, este tipo de material suele ser el único que muestra el software en acción: cómo un usuario puede pasar del estado A al estado B usando tu software. Al verlo en acción, las personas se familiarizan con la idea principal de tu software, lo que les permite intuir cómo funciona internamente.

Por ejemplo, la pantalla principal de la landing page de MSQ dice con letras grandes: "USA INTERNET COMPUTER CON METAMASK". Tras leer esta sencilla frase, el lector probablemente pensará: "Ah, entonces esto es un Snap de wallet que puede almacenar tokens de la blockchain Internet Computer. Probablemente funciona igual que otros Snaps para otras blockchains, solo que usando tecnologías del ecosistema de desarrollo de IC", lo cual es una suposición 100% correcta.

Comentario de Diligence Nuestra experiencia con MSQ y numerosos otros proyectos blockchain ha demostrado de forma consistente que una documentación clara y de alto nivel no solo es beneficiosa, sino que es fundamental tanto para la adopción por parte de los usuarios como para la seguridad. Durante nuestra revisión del Snap de MSQ, nos sorprendió gratamente su enfoque de documentación por capas. Un video tutorial de su desarrollador nos puso al día rápidamente. Pudimos entender las funciones del Snap incluso antes de ver el código. Esta visión general de alto nivel mostraba la interfaz de usuario, con comentarios sobre los comportamientos esperados y los flujos de usuario típicos. Estas ayudas visuales son invaluables, ya que permiten a los expertos en seguridad comprender mucho más rápido los "caminos felices" codificados en la aplicación y buscar vulnerabilidades que a menudo se ocultan fuera de estos caminos. Esto, combinado con una demostración en vivo del Snap y el código, es típicamente el inicio ideal para una revisión de seguridad.

2 Restringe el diseño donde sea posible

Esta parte es probablemente la más importante para la seguridad de tu proyecto. Tu código puede estar 100% libre de errores y tu infraestructura puede estar protegida con medidas que valen millones de dólares. Pero todos esos esfuerzos no significarían nada si tu diseño contiene alguna falla fundamental que pueda ser explotada por actores maliciosos.

Si bien los ejemplos específicos varían según el caso de uso, ofrecemos varios consejos universales.

2.1 Desarrolla pautas de seguridad y síguelas

Al inicio de MSQ, establecimos principios de seguridad fundamentales que se alinean con nuestra visión:

• El equipo de MSQ no sabe nada: No recopilamos ninguna información sensible del usuario, incluidos materiales de claves, datos de sesiones de autorización o detalles de cuentas.

• El material criptográfico nunca abandona el Snap: La entropía protegida de MetaMask del usuario se procesa exclusivamente dentro del Snap, se genera bajo demanda y se descarta inmediatamente después de su uso.

• MSQ es determinista: Los usuarios pueden recuperar todos los fondos, identidades y pares de claves de forma determinista usando su frase semilla raíz sin necesidad de conocimiento adicional.

• MSQ prioriza la privacidad: Nuestros esfuerzos priorizan la privacidad del usuario por encima de todo.

Estos principios están adaptados a las necesidades específicas de MSQ. Sin embargo, el equipo de MetaMask también proporciona un conjunto de pautas de seguridad para los desarrolladores de Snaps, a las que MSQ se adhiere, disponibles aquí.

Por ejemplo, existe el principio de Permisos mínimos, que básicamente significa que cuantos menos permisos solicite tu Snap a un usuario, mejor será su seguridad. MSQ solo solicita 4 permisos:

• endowment:rpc

• snap_dialog

• snap_manageState

• snap_getEntropy

No necesitamos endowment: network access porque MSQ solo es responsable de firmar transacciones, no de entregarlas al IC; la dapp integradora es responsable de esto último.

Deberías hacer lo mismo en tu Snap: toma la guía predeterminada de MetaMask, amplíala con tus reglas específicas y síguelas.

Comentario de Diligence Les decimos a nuestros clientes: "La seguridad no es una función que se añade; es un principio alrededor del cual se diseña". El establecimiento de principios de seguridad fundamentales por parte de MSQ desde el inicio del proyecto es exactamente lo que buscamos. Con demasiada frecuencia, los proyectos tratan la seguridad como algo secundario, añadiendo medidas después de que la arquitectura principal ya está definida. Este enfoque de adaptación posterior inevitablemente deja fallas fundamentales que las correcciones a nivel de código no pueden resolver verdaderamente.

En Consensys Diligence, ofrecemos servicios de expertos en seguridad, herramientas y abogamos por los derechos de los usuarios finales. Esto incluye garantizar que el material de claves de los usuarios permanezca seguro dentro de los límites de confianza de la wallet, sin quedar expuesto involuntariamente fuera de esta zona. También nos enfocamos en preservar la privacidad del usuario, idealmente evitando que incluso los metadatos o la información de canales secundarios se filtren a terceros. Además, impulsamos que los Snaps soliciten solo los permisos mínimos necesarios para su funcionamiento: el principio de mínimo privilegio.

La postura proactiva de MSQ se alinea con estos principios. Al priorizar la seguridad desde el principio, están construyendo una base más sólida, inherentemente más resistente a las vulnerabilidades.

2.2 Protege al usuario a toda costa

Esto es más bien una meta-guía: es un principio que debería implementarse en cualquier software, desde juegos en línea hasta sistemas bancarios.

El ejemplo más notable de esto en MSQ es nuestro enfoque de gestión de identidades. Como quizás sepas, la mayoría de las wallets disponibles proporcionan al usuario un conjunto de identidades (direcciones, cuentas, etc.). A este conjunto puede acceder cualquier dapp, con el consentimiento del usuario. Por ejemplo, para firmar algunas transacciones.

Esto es muy útil para las integraciones entre dapps, porque cualquier dapp puede invocar métodos de contratos inteligentes de otras dapps en nombre del usuario y ampliar así las capacidades de cada una. Por ejemplo, una plataforma de pagos en criptomonedas puede llamar a los contratos inteligentes de Uniswap para intercambiar automáticamente los tokens del comprador de modo que coincidan con lo que el vendedor espera recibir como pago por un bien o servicio específico.

Pero esto es perjudicial para la seguridad, ya que los sitios web fraudulentos pueden engañar a las personas para que firmen transacciones maliciosas y vacíen sus wallets.

En contraste, MSQ adopta la técnica de alcance de identidad: cada dapp (cada origen de URL distinto) tiene su propio conjunto separado de identidades de usuario con las que puede interactuar, sin posibilidad de interactuar con las identidades del usuario de otras dapps. Esto no solo resuelve el problema de los sitios web fraudulentos, sino que también ayuda enormemente con la privacidad, ya que las dapps ya no pueden rastrear al usuario ni ver con qué contratos inteligentes (llamados canisters en IC) interactúa. Este método, inspirado en Internet Identity y la especificación WebAuthn, mitiga significativamente los riesgos de seguridad.

Por ejemplo, si una dapp conocida se ve comprometida, las wallets tradicionales serían vulnerables en todas las dapps. En contraste, el alcance de identidad de MSQ confina la amenaza a la dapp comprometida, evitando daños más amplios.

Sin embargo, este método limita la integración directa entre dapps, ya que los usuarios tienen identidades distintas en cada una. MSQ ofrece soluciones para escenarios específicos, como permitir el intercambio de identidades entre dapps con doble consentimiento, útil para situaciones como cambios de nombre de dominio.

Además, MSQ garantiza que los datos a los que puede acceder una dapp estén estrictamente vinculados a la identidad relevante, asegurando aún más la información del usuario y manteniendo la privacidad en diferentes aplicaciones.

Comentario de Diligence La compensación de la integración directa limitada entre dApps es una decisión reflexiva. En nuestras evaluaciones de riesgos, a menudo hablamos del "presupuesto de seguridad", reconociendo que la seguridad perfecta puede obstaculizar la funcionalidad. MSQ ha invertido este presupuesto sabiamente. Al restringir las interacciones entre dApps, han reducido drásticamente uno de los riesgos más graves (el abuso generalizado de identidades) mientras preservan las funciones principales de la wallet.

3 Escribe código sólido

Ya hablamos un poco sobre el código cuando discutimos la documentación. Aquí queremos enfatizar un par de otros aspectos del código, que están más relacionados con la técnica que con la legibilidad.

3.1 Tu código

"Sólido" aquí significa que el código se comporta de manera predecible, cubriendo todas las entradas esperadas e inesperadas. Por ejemplo, ¿cómo debería reaccionar tu Snap si recibe un string base64 cuando espera hex? ¿O si los métodos se llaman en una secuencia no prevista, o se invoca un método RPC indefinido?

Para abordar estas incertidumbres se requiere:

1. Manejo claro de errores: Asegúrate de que cada rama y caso en tu código esté verificado y manejado adecuadamente. En el Snap de MSQ, usamos las verificaciones exhaustivas de TypeScript en sentencias switch-case para detectar cualquier llamada a método inesperada, como se muestra a continuación:

default: {
  err(ErrorCode.INVALID_RPC_METHOD, request.method);
}
Copiar

Esta configuración captura los casos en que se usa un identificador de método RPC desconocido.

1. Saneamiento de entradas: Validar los datos de entrada contra los tipos y formatos esperados puede ser complejo, pero es esencial para la seguridad. Utilizamos la biblioteca zod en TypeScript para esto, extendiendo el sistema de tipos de TypeScript a verificaciones en tiempo de ejecución. Zod permite definiciones de esquemas detalladas, garantizando que solo se procesen datos válidos.

Por ejemplo, nuestro método SNAP_METHODS.protected.identity.login usa un esquema zod para validar las entradas de forma rigurosa:

export const ZIdentityLoginRequest = z.object({
  toOrigin: ZOrigin,
  withIdentityId: ZIdentityId,
  withLinkedOrigin: z.optional(ZOrigin),
});

export const ZOrigin = z.string().url();
export const ZIdentityId = z.number().int().nonnegative();
Copiar

Aquí, ZOrigin y ZIdentityId no son simples strings o números, sino subtipos específicamente validados, lo que garantiza que las entradas no solo sean correctas en tipo sino también contextualmente apropiadas.

Al definir los esquemas zod con la mayor precisión posible, puedes resolver preventivamente muchos problemas potenciales. Los auditores recomendaron aplicar una validación estricta en MSQ, que, al implementarse, identificó y rectificó varios riesgos de seguridad.

Comentario de Diligence No es la primera vez que escuchamos de nuestros clientes que implementar una validación más estricta basada en nuestras recomendaciones para un escenario de ataque particular reveló varios otros riesgos de seguridad. Esto refleja exactamente nuestra experiencia y por eso siempre abogamos por una validación estricta de entradas para reducir la superficie de ataque. En muchas revisiones de seguridad, comenzamos examinando la validación de entradas. Reforzarla a menudo expone problemas latentes, un efecto dominó donde corregir una vulnerabilidad revela otra. Es una señal clara de que el proyecto toma en serio nuestros comentarios, endureciendo su sistema de forma iterativa. Con una superficie de ataque reducida, se vuelve progresivamente más difícil para los atacantes explotar las debilidades con éxito.

3.2 Código de terceros

En MSQ, consideramos que es nuestro deber proporcionar a los desarrolladores de dapps una biblioteca intuitiva que facilite una interacción correcta y eficiente con nuestro Snap. Esto permite que no solo MSQ, sino también los desarrolladores de terceros, mantengan bases de código limpias y sólidas.

Dicha biblioteca es beneficiosa por varias razones:

• Simplifica la complejidad de la API: Abstraemos las complejidades del Snap en una API fácil de usar. Por ejemplo, la biblioteca cliente de MSQ usa CBOR para la codificación de datos, evitando las limitaciones de JSON-RPC y ahorrando a los desarrolladores la molestia de la codificación y decodificación manual de datos.

• Garantiza interacciones seguras y directas: Ciertas funcionalidades del Snap son exclusivas de nuestra dapp complementaria. Para facilitar esto, gestionamos los procesos de redirección y transferencia de datos, garantizando un flujo fluido a través de postMessage. Este manejo interno garantiza que los desarrolladores de terceros interactúen con nuestro Snap a través de una API clara y directa.

• Mejora la claridad semántica: Una API limpia es más que una herramienta; es un medio de comunicación que hace que el código sea más legible y comprensible, libre del desorden de los intrincados procesos de codificación/decodificación y capas operativas adicionales.

Al priorizar estos aspectos, MSQ busca crear un ecosistema donde tanto nuestro Snap como las dapps integradoras puedan operar de manera eficiente y segura.

Comentario de Diligence El enfoque de MSQ para la integración de código de terceros a través de su biblioteca demuestra un compromiso con la simplificación del desarrollo mientras se mantiene la seguridad. Si bien en su núcleo la seguridad debe aplicarse estrictamente en el contexto del Snap, una biblioteca orientada a la dapp puede proporcionar una forma conveniente de comunicarse con el Snap. Sin embargo, siempre debe tenerse en cuenta que el desarrollador de la dapp debe garantizar una interacción segura con el Snap y una codificación segura de los datos cuando se usa dentro del contexto de la dapp.

4 Protege tu cadena de suministro

El reciente backdoor de XZ enfatizó una vez más lo importante que es trabajar contra la introducción de código malicioso en alguna de tus dependencias. En MSQ usamos pnpm para gestionar dependencias, pero en realidad no importa qué gestor de paquetes prefieras. Hay dos cosas que hacemos en MSQ para protegernos contra estos vectores de ataque:

4.1 Vincula los paquetes a versiones específicas

Usar pnpm install --save <package-name> típicamente instala la última versión de un paquete, siguiendo la especificación semver, que permite actualizaciones automáticas a versiones más nuevas sin cambios disruptivos. Esto se indica con el símbolo de acento circunflejo (^) en package.json, que representa un rango de versiones aceptables:

Sin embargo, para prevenir riesgos de actualizaciones maliciosas, es más seguro bloquear las dependencias a versiones específicas:

1. Elimina el acento circunflejo (^) de tu package.json para fijar cada versión de dependencia. Elimina los archivos de bloqueo existentes y node_modules, luego ejecuta pnpm install para alinearte estrictamente con las versiones definidas.

2. Usa el flag --save-exact para instalaciones futuras (pnpm install --save-exact <package-name>) para evitar actualizaciones automáticas.

La confianza es un factor en esta decisión. Por ejemplo, en MSQ consideramos que los espacios de nombres de dependencias @metamask y @dfinity son seguros y permitimos actualizaciones dentro de su rango semver. Sin embargo, al hacerlo, ten cuidado con las posibles vulnerabilidades de las dependencias transitivas.

Comentario de Diligence Migrar proyectos a versiones exactas de dependencias ha prevenido innumerables problemas:

• Ha detenido las actualizaciones silenciosas que reintroducían vulnerabilidades ya parcheadas.

• Ha prevenido la "desviación de versiones" donde diferentes módulos ven comportamientos distintos de la biblioteca.

• Ha sido crucial en investigaciones post-incidente, permitiéndonos replicar el entorno exacto. Cada nueva actualización puede ser maliciosa, en cualquier espacio de nombres, cualquier paquete. Al revisar los paquetes utilizados y vincularse solo a versiones seguras conocidas, evitando actualizaciones accidentales, se reduce aún más la superficie de ataque para los ataques a la cadena de suministro. Confiar en ciertos proveedores está bien, siempre que las nuevas versiones se verifiquen manualmente para asegurarse de que no contienen código malicioso antes de su uso. Ten en cuenta que los paquetes especialmente conocidos utilizados por muchos proyectos son objetivos principales para los actores maliciosos y, como ha demostrado el pasado, cualquier biblioteca central de este tipo puede caer ante sofisticados ataques a la cadena de suministro (ver ataque backdoor de XZ).

4.2 Confirma los archivos de bloqueo en tu repositorio

Para garantizar la consistencia en tu equipo y mantener compilaciones reproducibles, confirma tus archivos de bloqueo en el sistema de control de versiones. En MSQ, utilizamos pnpm workspaces y turborepo, lo que requiere un único archivo de bloqueo raíz, pnpm-lock.yaml. Sin embargo, tu configuración podría requerir mantener múltiples archivos de bloqueo; todos deben estar bajo control de versiones para garantizar la consistencia del entorno.

Comentario de Diligence Esta práctica, aunque a veces se pasa por alto como una mera conveniencia de desarrollo, es en realidad un componente crítico para mantener una base de código segura y estable. Nuestros años auditando contratos inteligentes, componentes blockchain y ahora MetaMask Snaps han demostrado repetidamente que las compilaciones reproducibles no son solo algo deseable, sino un requisito fundamental de seguridad. Confirmar los archivos de bloqueo es una pieza del rompecabezas para reducir la superficie de ataque en los ataques a la cadena de suministro. Cuando npm install ya no es una lotería, las versiones concretas y los checksums dejan un rastro de auditoría en el repositorio, las compilaciones son más deterministas y los debates sobre "Funciona en mi máquina" desaparecen.

5 Corrige rápido y limpio

Si bien esto no está directamente relacionado con nuestro Snap, entender cómo abordar los hallazgos de una auditoría de manera eficiente es fundamental.

En cuanto el equipo de auditores reporte un hallazgo, debes comenzar a trabajar en una corrección. El tamaño y la complejidad de la corrección dependen claramente del hallazgo, pero hay un consejo para hacerla más pequeña y limpia: corrige la causa, no el síntoma, siempre que sea posible.

Por ejemplo, en MSQ, los auditores descubrieron que era posible inyectar caracteres de control de Markdown en nuestros mensajes de consentimiento de MetaMask. En lugar de corregir cada mensaje de consentimiento por separado, realizando múltiples cambios en diferentes partes del código, simplemente redefinimos los elementos text() y heading() (de @metamask/snaps-sdk), para que primero pasen su contenido por la función escapeMarkdown() y solo entonces lo rendericen. Esto nos permitió simplemente reemplazar las expresiones import en todos los archivos con mensajes de consentimiento con nuestros elementos personalizados, en lugar de corregir cada invocación de text() y heading() por separado, lo que resultó en una corrección mucho más limpia.

Una resolución efectiva no solo mejora el problema específico, sino que también protege preventivamente contra vulnerabilidades no detectadas.

Comentario de Diligence Con demasiada frecuencia, vemos que los proyectos adoptan un enfoque de "apagar incendios" ante la seguridad, parcheando cada problema individual a medida que aparece sin considerar la clase de vulnerabilidad subyacente. Al abordar la causa raíz de los problemas y no dudar en eliminar clases de vulnerabilidades de forma global, MSQ demuestra que entiende la seguridad no como una serie de parches, sino como una disciplina holística. Como expertos en seguridad, solo podemos recomendar a nuestros clientes que no se apresuren con las correcciones y dediquen suficiente tiempo para convertir un hallazgo de seguridad en un evento que tenga un efecto positivo en la seguridad del proyecto.

Conclusión

Con esto concluyen nuestras reflexiones sobre cómo navegar con éxito una auditoría de seguridad de MetaMask Snaps. Seguir estas pautas ayudó al equipo de MSQ a recibir un informe positivo del equipo de Diligence. Esperamos que compartir la experiencia de MSQ te ayude en tus preparativos para la auditoría de seguridad, garantizando un proceso exhaustivo y efectivo.

Consensys Diligence ha ayudado a una amplia gama de proyectos en el ecosistema blockchain a garantizar que sus protocolos estén listos para el lanzamiento y diseñados para proteger a los usuarios. Estaremos encantados de revisar tu Snap en busca de estas y otras vulnerabilidades en una auditoría personalizada. ¡Contáctanos y solicita un presupuesto!