Yarn es microseguro

Hace unas semanas, Facebook anunció el lanzamiento de código abierto de Yarn: un nuevo cliente para el registro de npm. Aunque algunas personas expresaron su preocupación, parece ser un buen ejemplo de desarrollo de código abierto. Facebook, Google, Exponent y Tilde enfrentaban desafíos similares al usar el cliente predeterminado de npm. En lugar de que cada uno intentara resolverlos por su cuenta, colaboraron e iteraron sobre npm. El resultado es un cliente alternativo que ofrece mejoras notables sin perder la potencia del registro de npm subyacente.

Yarn se promociona como “ultrarrápido”, “súper confiable” y “mega seguro”. Si bien es cierto que suele ser mucho más rápido y que el nuevo archivo de bloqueo garantiza una mayor coherencia al instalar tu aplicación, las afirmaciones sobre su seguridad son un poco exageradas.

Qué hace Yarn por la seguridad

Cuando Yarn dice que es “mega seguro”, se refiere al uso de sumas de verificación para comprobar que el paquete que solicitas sea el mismo que recibes, sin modificaciones.

Verificación de sumas de comprobación

Puedes verlo en acción si abres el archivo yarn.lock de uno de tus proyectos. Este es un fragmento:

moment:
  version "2.15.2"
  resolved "https://registry.yarnpkg.com/moment/-/moment-2.15.2.tgz#1bfdedf6a6e345f322fe956d5df5bd08a8ce84dc"

El fragmento anterior muestra que solicitamos el paquete moment y que el paquete se resolvió en la siguiente URL:

https://registry.yarnpkg.com/moment/-/moment-2.15.2.tgz#1bfdedf6a6e345f322fe956d5df5bd08a8ce84dc

Lo que más interesa aquí es la sección que aparece después del hash:

1bfdedf6a6e345f322fe956d5df5bd08a8ce84dc

Esta es la suma de comprobación del archivo, calculada mediante el algoritmo de hash seguro 1 (SHA-1). Si descargas el paquete desde la URL en tu equipo, puedes verificar la suma de comprobación en la línea de comandos con el comando sha1sum en Linux o con shasum en Mac OSX.

# On Linux
sha1sum moment-2.15.2.tgz

# On Mac OSX
shasum moment-2.15.2.tgz

Esos comandos muestran el hash SHA-1, que coincide con el hash del archivo de políticas. Supongamos que solicitas ese paquete, pero que de alguna manera es distinto de lo que indica la suma de comprobación del archivo yarn.lock. Por ejemplo, agregué una línea al archivo README.md, volví a crear el archivo .tgz y luego ejecuté shasum de nuevo. El nuevo hash fue:

9a6c63c40298234627114c821529a8e42a073f98

Este nuevo hash no coincide con el que esperabas, así que puedes darte cuenta de que algo cambió: lo que solicitaste no coincide con lo que recibiste. Ese algo podría ser inofensivo; tal vez ocurrió un error durante la transmisión y el archivo se dañó de alguna manera. También podría ser algo más malicioso: quizá alguien obtuvo el paquete y lo manipuló. La suma de comprobación te avisa que algo salió mal para que puedas investigar más.

¿Cómo pueden manipular un paquete los atacantes?

Aunque garantizar la integridad de los datos es sin duda una buena característica, vale la pena preguntarse cómo podría manipular un paquete un atacante.

Una forma es modificar el paquete en su origen, es decir, en el registro que lo aloja. La mayoría de las personas descarga paquetes de npmjs.com, que, hasta donde sé, no ha tenido casos de atacantes que modifiquen código directamente en el registro.

La otra posibilidad es modificar el paquete durante la descarga, mientras está en tránsito. De nuevo, la mayoría de los paquetes se descargan del registro público de npm, que usa HTTPS. Aunque es posible modificar paquetes en tránsito a través de HTTPS, no es nada sencillo.

Las sumas de comprobación son más útiles cuando alojas tu propio repositorio. Aunque las soluciones de Artifactory y Nexus están bien protegidas, si creas la tuya propia, podría haber puntos débiles que permitan manipular paquetes directamente en el registro. Y aunque te recomendamos (con mucho énfasis) que no lo hagas, hemos visto registros locales servidos por HTTP. En esos casos, es mucho más fácil modificar el paquete, por lo que las sumas de comprobación cobran mucha más importancia.

Si usas el registro público de npm o alojas el tuyo mediante HTTPS con una solución comercial, la manipulación contra la que protegen las sumas de comprobación deja de ser un problema tan importante. Es una característica de seguridad, pero menor.

yarn.lock para fijar versiones

Además, el archivo yarn.lock puede complicar tus planes de seguridad. Al igual que npm shrinkwrap, el objetivo del archivo yarn.lock es fijar versiones específicas de tus dependencias. La ventaja de usar un archivo de bloqueo es que, si instalo un proyecto de Yarn en mi equipo y mañana instalo la misma aplicación en un entorno de producción, sé que ambas instalaciones usarán exactamente las mismas dependencias, aunque se haya publicado una versión nueva.

Es excelente para mantener la coherencia, pero los archivos de bloqueo tienden a impedir que se actualicen los paquetes que usas. A diferencia de usar rangos semver, la única forma de actualizar a una nueva versión de una dependencia es editar o volver a crear el archivo de bloqueo para permitirlo. Ahora les corresponde a los desarrolladores estar atentos a las actualizaciones que puedan incluir correcciones para vulnerabilidades críticas, aún más que con los enfoques basados en semver, como los que se usan en package.json.

Eso no significa que no debas usar archivos de bloqueo. Úsalos si la coherencia es importante para tu aplicación; solo asegúrate de contar con los procesos adecuados para revisar y actualizar activamente los paquetes vulnerables.

El eslabón de seguridad que falta

Las sumas de comprobación ofrecen una capa de seguridad, pero no garantizan que el paquete original que intentas obtener sea seguro. En el mundo del desarrollo de código abierto, ese es un problema mucho mayor. Aunque la mayoría de quienes mantienen proyectos de código abierto tienen buenas intenciones, rara vez escriben estos paquetes considerando la seguridad como un requisito fundamental. Cuando incorporamos estos paquetes a nuestros propios proyectos, lo hacemos a ciegas: sin comprender bien todas las dependencias que traen consigo ni los problemas de seguridad que podrían ocultarse en ellas.

Por ejemplo, el paquete moment que vimos antes contiene una vulnerabilidad de denegación de servicio mediante expresiones regulares para la que existe un parche. Instalar el paquete con Yarn no te lo hará saber. Analizar las dependencias para detectar vulnerabilidades conocidas es un problema de seguridad distinto y más importante que el que Yarn resuelve.

¿Cómo lograr una seguridad realmente extraordinaria?

Por suerte, como Yarn se basa en npm, funciona bastante bien dentro de su ecosistema. Yarn todavía tiene algunos detalles por resolver, pero, una vez solucionados, las herramientas de seguridad existentes deberían funcionar con cambios mínimos.

Por ejemplo, para abordar las vulnerabilidades conocidas en paquetes de npm, actualmente recomendamos ejecutar snyk protect como parte del paso post-install en tus aplicaciones Node.js. Si ejecutas yarn install, ese paso también se activa, por lo que snyk protect sigue ejecutándose y analiza tus dependencias para detectar vulnerabilidades conocidas.

Nos parece que Yarn es realmente genial y, a juzgar por la atención que ha recibido, muchas personas parecen estar de acuerdo. Por lo general, es más rápido, y los nuevos archivos de bloqueo serán útiles para muchas organizaciones que buscan mayor coherencia en sus instalaciones.

Pero, aunque es excelente que Yarn intente incorporar la seguridad desde el principio, se muestran un poco demasiado confiados al decir que es “mega seguro”. El problema no son las sumas de comprobación, sino el marketing. Las sumas de comprobación ayudan a garantizar que se mantenga la integridad de tus datos, pero ese es un problema relativamente menor en el ecosistema de Node.js. Mucho más importante es asegurarse de que esas dependencias sean seguras desde el principio.