¡Ejecuto código de Internet!

Y hoy vamos a hablar de ejecutar el código de otra persona. Hablando de eso, si les diera una cadena de texto y les pidiera que la pongan en su aplicación y la ejecuten, ¿lo harían? ¿Pondrían mi código en producción sin revisarlo mucho? Bueno, supongo que la respuesta va a ser no. ¿Pero ayudaría si lo pusiera en un archivo tar.gz? ¿Sería más atractivo de esa manera? De alguna manera sí, porque eso es lo que son los paquetes de NPM. Y son geniales, todos los usan, pero en realidad son entradas no sanitizadas de Internet que ponemos en nuestras aplicaciones y ejecutamos. ¿De acuerdo? Así que sí, eso es lo que estamos haciendo, lo hacemos todo el tiempo. Instalo paquetes de NPM todo el tiempo. ¿Y si algunos de los paquetes ahí no son buenos? Y con eso no me refiero a paquetes malos. He publicado algunos paquetes malos y no pasó nada malo. Pero me refiero a paquetes maliciosos, paquetes peligrosos que quieren dañar tu aplicación, tus usuarios. ¿Qué hacemos al respecto? Bueno, hay herramientas para la seguridad de la cadena de suministro, ¿verdad? Entonces, una herramienta podría decir, hey, algunos investigadores descubrieron que este paquete no es bueno y lo informaron. Así que ese paquete que enviaste a producción hace unas semanas, ahora sabemos que no es bueno. Por favor, haz algo al respecto. ¿Es una gran situación para estar? No necesariamente. Ok, hay SocketDev. Puedes usar eso y obtener un ciclo de retroalimentación mucho mejor, porque SocketDev automatiza la búsqueda de cualidades sospechosas en los paquetes. Entonces, SocketDev, unas pocas horas después de que se publique el paquete, podrá decirte que posiblemente haya algo mal con él. Pero luego necesitas investigarlo. En Lavamote decidimos ser proactivos en lugar de reactivos, por lo que asumimos que una de las dependencias en el gráfico de dependencias ya es maliciosa cuando se ejecuta la aplicación. Entonces, ¿cómo funciona? Tengo una demostración, si esta fuera una charla más larga, pueden ver esa demostración, pero veamos la situación en la que instalas una herramienta de compilación para tu proyecto y luego alguien pone esto en el código de tu herramienta de compilación en algún lugar. Así que toma tu token de GitHub mientras se ejecuta en CI y lo envía a algún lugar. ¿Es genial? Probablemente no. Lo que hace LavaMode, LavaMode te permite generar una política para toda tu aplicación, en este caso un proceso de compilación, y luego ejecutarlo en función de esa política. La política se genera automáticamente, detecta casi todo lo que se necesita para que la aplicación se ejecute, luego procedes a ajustar la política al margen, qué cosas deberían estar permitidas y cuáles no. Si nuestro análisis no encuentra algo, no aparece en la política y por defecto no está permitido. En este caso, la política se genera con la solicitud HTTPS y Process.env presente. Lo que podemos hacer es eliminarlos o cambiarlos a false, lo que significa que no están permitidos, y ejecutar tu compilación con lavamode hará que aparezca uno de estos errores. Ya sea esta dependencia maliciosa que solicita el paquete HTTPS, que no está disponible, o que no puede leer env de process porque process no está definido. ¿Cómo es eso posible? Bueno, gracias a Hardened JavaScript. Estamos utilizando Hardened JavaScript detrás de escena para aislar cada dependencia dentro del mismo proceso.

No hay hilos, workers ni iframes involucrados. Todo esto sucede en un reino o contexto, y aún así podemos obtener un buen aislamiento. Hardened JavaScript es el constructor de compartimentos que crea un espacio donde puedes ejecutar código y decidir qué globales estarán disponibles e importar otras cosas.

Y luego está el lockdown que se asegura de que todo el entorno que lo rodea, como los prototipos globales de objeto, array y función, se coloque en un estado en el que sea imposible manipularlos maliciosamente. Así que, ya no hay contaminación de prototipos.

Y la buena noticia es que esto se está convirtiendo en parte del lenguaje. ¡Bueno, aún no! Hay una propuesta inicial para introducir compartimentos en TC39, y algunas de las personas que trabajan en ello son las responsables de brindarnos objetos libres de uso estricto o promesas. Así que, espero que esto se implemente. Va a llevar un tiempo, pero ya tenemos una implementación que funciona.

Y LavaMode no es solo para Node. No estamos en una conferencia específica de Node. También hay un bundler construido sobre la misma tecnología, las mismas ideas, utilizando la misma estructura de políticas. Y el bundler que tenemos funcionando para la producción de Manumaskian hoy en día se basa en Browserify, porque Browserify fue el más flexible de los bundlers. Y eso ha estado funcionando durante aproximadamente dos años, si recuerdo correctamente. Y ahora estamos trabajando en obtener un complemento de Webpack. Esto es un trabajo en progreso y es de código abierto. Así que si quieres ayudar, únete a nosotros. Hay muchos detalles sobre Webpack que todavía necesitamos resolver para tener una cobertura perfecta de todas las características de Webpack. Y hay muchas características de Webpack. Así que déjame mostrarte el Bundler ahora.

Esta es una aplicación, muy simple, donde puede importar cosas, MJS, TypeScript, paquetes antiguos, todo. Y hay un paquete llamado cookiemonster que hice. Y cookiemonster nos está dando una cita aleatoria. Y hay un entorno disponible. ¿Por qué te estoy mostrando esto? Porque cookiemonster no solo nos está dando citas. También está robando nuestras cookies. Así que aquí hay una solicitud de búsqueda que envía nuestro nombre de host y cookie al servidor de cookiemonster.

Esta aplicación se está construyendo con webpack. No hay nada especial en esta configuración. Es súper simple. Y luego este complemento. El nombre en clave de nuestro complemento LavaMode es Scoretrap. Todavía es un trabajo en progreso. ¿Recuerdas? Y aquí tengo ejemplos de dos compilaciones. Ejecutemos primero la compilación sin Scoretrap. Así que si actualizo esta página, voy a recibir un mensaje enviado a mi servidor. Este es un mensaje emergente de mi servidor. Tiene el nombre de chocolate chip en las cookies. Esta es la búsqueda que ocurrió y esta es la aplicación funcionando. Obtenemos la cita de Cookie Monster, pero ¿a qué precio? Aquí, esta es una compilación donde nuestro complemento estaba habilitado. Si ejecuto esto, obtengo undefined en su lugar. Lo que sucedió aquí es que tengo alguna salida de diagnóstico. Hemos estado analizando las políticas para la aplicación, leftpad y Cookie Monster. Entonces, la aplicación tiene acceso a todo. Cookie Monster todavía nos da citas. Pero no tiene acceso a location y document, porque no le dimos ese acceso. Esto está implementado por ahora aquí en el tiempo de ejecución. Temporalmente agregué estas políticas codificadas en duro aquí. La política para el tiempo de ejecución de webpack aún no se ha implementado, pero Cookie Monster solo obtiene fetch, leftpad no obtiene nada y luego la aplicación obtiene prácticamente todo. Y esa es la política establecida en este momento.

De acuerdo, volviendo a esto, si quieres saber más, hay muchas presentaciones sobre Lavamote y Hardened JavaScript en mi sitio web. Y hay un enlace a Mark Miller hablando sobre su invención de SEST y Hardened JavaScript y un montón de principios detrás de ello. Por último, pero no menos importante, ofrezco ayuda para implementar Lavamote en tu proyecto. Así que si tienes un proyecto serio que necesitas proteger, podemos instalar y ejecutar al menos algunas de las herramientas de Lavamote para tu proyecto fácilmente. Avísame si quieres probarlo. Estamos buscando comentarios sobre dónde están las incompatibilidades, porque hay una pequeña parte del ecosistema de NPM que podría causar problemas bajo Lavamote, y específicamente bajo lockdown, donde no puedes modificar el prototipo de objeto, etc. Así que, por favor, ponte en contacto si quieres involucrarte con nuestro código abierto o instalar Lavamote. ¡Y bueno, mantente seguro! www.npm.org