Es un mundo salvaje ahí fuera: ¿Qué está pasando realmente dentro de tu carpeta node_modules?

Rate this content
Bookmark

¿Sabes qué está pasando realmente en tu carpeta node_modules? Los ataques a la cadena de suministro de software han explotado en los últimos 12 meses y solo están acelerando en 2022 y más allá. Analizaremos ejemplos de ataques recientes a la cadena de suministro y los pasos concretos que puedes tomar para proteger a tu equipo de esta amenaza emergente.


Puedes consultar las diapositivas de la charla de Feross aquí.

26 min
18 Feb, 2022

Video Summary and Transcription

La charla discute la importancia de la seguridad en la cadena de suministro en el ecosistema de código abierto, resaltando los riesgos de depender de código de código abierto sin una revisión adecuada del código. Explora la tendencia de los ataques a la cadena de suministro y la necesidad de un nuevo enfoque para detectar y bloquear dependencias maliciosas. La charla también presenta Socket, una herramienta que evalúa la seguridad de los paquetes y proporciona automatización y análisis para protegerse contra malware y ataques a la cadena de suministro. Enfatiza la necesidad de priorizar la seguridad en el desarrollo de software y ofrece ideas sobre posibles soluciones como realms y las banderas de línea de comandos de Deno.

Available in English

1. Introduction and Stories

Short description:

Hola y bienvenidos. Gracias por venir a mi charla. Es una jungla ahí afuera. Mi nombre es Firas y soy un mantenedor de código abierto. Comencé WebTorrent y StandardJS. He estado trabajando en código abierto desde 2014. En el pasado, fui voluntario en la junta directiva de Node.js y también enseño una clase sobre seguridad web en la Universidad de Stanford. Ahora soy el fundador de una startup llamada Socket, que ayuda a proteger el ecosistema de código abierto. Permítanme contarles una historia. El 13 de enero de 2012, un desarrollador llamado Faizal Salman publicó un nuevo proyecto en GitHub. Se llamaba UAParserJS y analizaba cadenas de agente de usuario. Durante los próximos 10 años, Faizal continuó desarrollando el paquete y eventualmente creció hasta alcanzar 7 millones de descargas por semana, siendo utilizado por casi 3 millones de repositorios de GitHub. Ahora, permítanme contarles una historia diferente. El 5 de octubre de 2021, un hacker ofrecía vender la contraseña de una cuenta de NPM que controlaba un paquete con más de 7 millones de descargas semanales. Dos semanas después, uaparser.js fue comprometido y se publicaron tres versiones maliciosas. Se agregó malware a estos paquetes que se ejecutaría inmediatamente cada vez que alguien instalara una de las versiones comprometidas. Ahora, veamos qué hace ese malware. Utiliza un script de preinstalación que se divide según el sistema operativo del objetivo. En Mac, no sucede nada, pero los usuarios de Windows y Linux no tienen tanta suerte.

Comencé WebTorrent y StandardJS. He estado trabajando en código abierto desde 2014. En el pasado, fui voluntario en la junta directiva de Node.js y también enseño una clase sobre seguridad web en la Universidad de Stanford. Ahora soy el fundador de una startup llamada Socket, que ayuda a proteger el ecosistema de código abierto. Antes de comenzar, permítanme contarles una historia. El 13 de enero de 2012, hace más de 10 años, un desarrollador llamado Faizal Salman publicó un nuevo proyecto en GitHub. Se llamaba UAParserJS y analizaba cadenas de agente de usuario. Ahora, mucha gente encontró este proyecto útil. Y así, durante los próximos 10 años, Faizal continuó desarrollando el paquete, con la ayuda de muchos colaboradores de código abierto. Publicó 54 versiones, a medida que el paquete crecía en popularidad. Eventualmente, creció hasta alcanzar 7 millones de descargas por semana. Siendo utilizado por casi 3 millones de repositorios de GitHub. Ahora, permítanme contarles una historia diferente. El 5 de octubre de 2021, en un conocido foro ruso de hacking, apareció esta publicación. Un hacker ofrecía vender la contraseña de una cuenta de NPM que controlaba un paquete con más de 7 millones de descargas semanales. Su precio de venta era de $20,000 por esta contraseña. Ahora, aquí es donde las dos historias se cruzan. Dos semanas después, uaparser.js fue comprometido y se publicaron tres versiones maliciosas. Se agregó malware a estos paquetes que se ejecutaría inmediatamente cada vez que alguien instalara una de las versiones comprometidas. Entonces, ahora veamos qué hace ese malware. Este es el archivo package JSON de la versión comprometida. Y verán que utiliza un script de preinstalación. Esto significa que el comando se ejecutará automáticamente cada vez que se instale este paquete. Ahora veamos qué hace ese script. Lo primero que verán es que se divide según el sistema operativo del objetivo. En Mac, no sucede nada, lo cual es suerte para los usuarios de Mac, pero

2. Malicious Package Attack

Short description:

Y verán aquí que el símbolo del sistema se ha generado para cada una de estas plataformas usando child process.exe. Ahora, echemos un vistazo a lo que hace ese script pre-install.sh. Obtiene el país del usuario y procede a descargar un archivo ejecutable. Este programa es un minero de Monero utilizado para minar la criptomoneda Monero. En Windows, el script descarga un archivo DLL que roba contraseñas de más de 100 programas diferentes y del administrador de credenciales de Windows. Este paquete estuvo publicado durante aproximadamente cuatro horas, comprometiendo a aquellos que lo instalaron durante ese tiempo. Más de 700 paquetes han sido eliminados de NPM por razones de seguridad en los últimos 30 días. La tendencia de los ataques en el ecosistema abierto y la confianza entre los mantenedores se está acelerando. 2022 será el año de la seguridad de la cadena de suministro. El sistema de descargar código de Internet y ejecutarlo con permisos completos es arriesgado, pero es un milagro que haya funcionado en su mayoría durante tanto tiempo.

Los usuarios de Windows y Linux no tienen tanta suerte. Y verán aquí que el símbolo del sistema se ha generado para cada una de estas plataformas usando child process.exe. Ahora, echemos un vistazo a lo que hace ese script pre-install.sh. La primera línea obtiene el país del usuario y determina si es de Rusia, Ucrania, Bielorrusia o Kazajistán, y almacena esa información en una variable. Ahora, si el usuario es de alguno de esos países, entonces el script se cierra sin hacer nada más. Sin embargo, si provienes de cualquier otro país, el script procede a descargar un archivo ejecutable desde esta dirección IP, marca ese archivo como ejecutable y luego lo ejecuta. Y ahora, según estas banderas de línea de comando, pueden ver aquí que este programa es un minero de Monero, que se utilizará para minar la criptomoneda Monero para el atacante. Ahora, este es el script en Windows. Es muy similar. Comienza descargando ese mismo o un minero de Monero similar, pero también descarga un archivo DLL y lo ejecuta. Y luego aquí pueden ver que simplemente se inicia el minero de Monero y se registra el archivo DLL en Windows.

Ahora, ¿qué hace este archivo DLL adicional? Bueno, roba contraseñas de más de 100 programas diferentes en la máquina con Windows, así como todas las contraseñas en el administrador de credenciales de Windows. Así que, vaya, este es un malware realmente desagradable. Y, ya saben, cualquier persona que tuvo la mala suerte de ejecutar esto perdió todas sus contraseñas y tuvo que hacer un restablecimiento completo de sus cuentas en línea. No fue un buen momento. Entonces, esta es más o menos la secuela. Este paquete estuvo publicado durante aproximadamente cuatro horas. Y la comunidad de código abierto fue bastante diligente y lo informó, y el mantenedor también fue bastante diligente. Así que, cualquier persona que lo instaló durante la ventana de cuatro horas fue comprometida, pero se eliminó relativamente rápido. Cualquier compilación de software realizada en proyectos sin usar un archivo de bloqueo fue comprometida. Y cualquier persona que tuvo la mala suerte de actualizar a esta nueva versión del paquete o tal vez fusionó una solicitud de extracción de bot para actualizar a esta nueva versión durante este tiempo también habría sido comprometida. Así que, esto fue una gran noticia en el mundo de JavaScript, y supongo que ya habrán oído hablar de este ataque. Pero esto es solo la punta del iceberg. Hemos estado rastreando los paquetes que se eliminan de NPM por razones de seguridad, y hemos visto más de 700 paquetes eliminados por razones de seguridad en los últimos 30 días. Y creo que esta tendencia se está acelerando a medida que los atacantes aprovechan el ecosistema abierto y la confianza que los mantenedores tienen entre sí y las políticas de contribución liberal que todos hemos adoptado en la era moderna del código abierto. Así que creo que 2022 será el año de la seguridad de la cadena de suministro, ya que la conciencia de este problema está surgiendo ahora. Entonces, una pregunta que podrían hacer es, ¿por qué está sucediendo esto ahora? Quiero empezar señalando que lo que estamos tratando de hacer aquí es algo un poco loco. Estamos tratando de descargar código de Internet, escrito por personas desconocidas que no hemos leído, y lo ejecutamos con permisos completos en nuestras computadoras portátiles y servidores, donde guardamos nuestros datos más importantes. Así que esto es lo que hacemos todos los días cuando usamos npm install. Y solo tengo que decir rápidamente que personalmente creo que es un milagro que el sistema funcione. Y que haya continuado

3. Open Source and Security Risks

Short description:

El 90% del código de tu aplicación proviene de código abierto, lo que nos permite construir aplicaciones web poderosas rápidamente. Sin embargo, la abundancia de dependencias transitivas y la falta de revisión de código crean riesgos de seguridad. La carpeta de módulos de Node es una gran colección de paquetes y la visualización de Webpack muestra la complejidad. Las personas rara vez leen el código que ejecutan y npm no facilita la revisión de paquetes. Al confiar en la ley de Linus, confiamos en que otros encuentren problemas de seguridad, pero esto puede llevar a que el malware pase desapercibido durante meses. Estos hallazgos resaltan la importancia de la seguridad de la cadena de suministro en el ecosistema de código abierto.

El hecho de que esto haya funcionado en su mayoría durante tanto tiempo es un testimonio, creo, de lo buenos que son la mayoría de las personas. Pero, desafortunadamente, no todos son buenos. Así que profundicemos en por qué esto está sucediendo ahora. La primera razón es que el 90% del código de tu aplicación proviene de código abierto. Por lo tanto, realmente estamos parados sobre los hombros de gigantes. Y el código abierto es la razón por la cual podemos lanzar una aplicación en horas y días en lugar de semanas o meses. Y es la razón por la cual no necesitamos ser expertos en criptografía o en zonas horarias o en el DOM virtual para construir una aplicación web moderna y poderosa. También es la razón por la cual la carpeta de módulos de Node es uno de los objetos más pesados del universo. Otra razón es que tenemos muchas, muchas dependencias transitivas. La forma en que escribimos software ha cambiado. Usamos dependencias mucho más liberalmente. Por lo tanto, instalar incluso una sola dependencia a menudo conduce a muchas, muchas dependencias transitivas que también se instalan. Un artículo de 2019 en la conferencia Usenix descubrió que instalar un paquete promedio implica una confianza implícita en 79 paquetes de terceros y 39 mantenedores, creando una superficie de ataque sorprendentemente grande. Y aquí tenemos una visualización que mi equipo en Socket creó que muestra cómo se ve Webpack. Si exploras la carpeta de módulos de Node y realmente ves lo que hay dentro, cada cuadro gris representa un paquete y cada cuadro morado representa un archivo o archivos dentro de un paquete. A medida que quitas cada capa del árbol de dependencias, encontrarás más paquetes dentro del paquete de nivel superior hasta llegar al fondo. Esto es simplemente una cantidad insana de archivos y muchos módulos volando por aquí. La siguiente razón es que nadie realmente lee el código. Algunas personas lo hacen, pero en general, las personas no miran el código que están ejecutando en sus máquinas. Una gran razón es que npm realmente no facilita esto. Si vas a la página del paquete UAParser.js y haces clic en la pestaña de exploración, verás que ni siquiera puedes ver los archivos de este paquete, por lo que las personas tienen que recurrir a hacer clic en el enlace de GitHub y verificar en GitHub y esperar que el código en GitHub coincida con el código en npm, lo cual no es necesariamente cierto. Pero está bien. Podemos confiar en la ley de Linus de que, dado suficientes ojos, todos los errores son superficiales. Entonces, si hay un problema de seguridad o malware en un paquete, podemos confiar en que otros lo encuentren, ¿verdad? Pero si todos hacen eso, ¿quién encuentra el malware? Y tal vez esta sea la razón por la cual, en promedio, un paquete malicioso está disponible durante 209 días antes de que se informe públicamente. Esto proviene de un artículo de investigación de Ohm et al. Entonces, esos son 209 días durante los cuales el comando incorrecto de npm puede terminar extremadamente mal. Y personalmente, encuentro este número muy impactante. Un artículo de 2021 en NDSS, una prestigiosa conferencia de seguridad, también encontró resultados similares, incluido que el 20% de estos malware persisten en los administradores de paquetes durante más de 400 días y tienen

4. Popular Tools and Supply-Chain Attacks

Short description:

Las herramientas populares dan una falsa sensación de seguridad al escanear solo vulnerabilidades conocidas, dejándote vulnerable. Es crucial distinguir entre vulnerabilidades y malware. Las vulnerabilidades pueden tener un impacto bajo y pueden enviarse temporalmente a producción. Sin embargo, el malware, introducido intencionalmente por atacantes, siempre conduce a consecuencias negativas. El desarrollo rápido aumenta el riesgo de ataques a la cadena de suministro. Necesitamos un nuevo enfoque para detectar y bloquear dependencias maliciosas. Comprender los mecanismos de los ataques a la cadena de suministro es esencial. Los vectores de ataque, como el typo squatting, engañan a los usuarios para que ejecuten código malicioso.

Más de 1,000 descargas. Y la cuarta razón es que las herramientas populares dan una falsa sensación de seguridad. Muchas herramientas populares escanean vulnerabilidades conocidas. Entonces, en 2022, creo que esto ya no es suficiente. No podemos simplemente escanear vulnerabilidades conocidas y detenernos ahí. Y sin embargo, eso es lo que hacen la mayoría de los productos populares de seguridad de la cadena de suministro, dejándote vulnerable.

La cuestión es que puede llevar semanas o meses descubrir, informar y detectar una CVE o vulnerabilidad conocida con herramientas. Y por lo tanto, simplemente no es lo suficientemente rápido. Así que vale la pena tomar un minuto aquí para distinguir rápidamente entre vulnerabilidades conocidas y malware porque son muy diferentes. Las vulnerabilidades son introducidas accidentalmente por los mantenedores, por los buenos, y tienen diferentes niveles de riesgo. Entonces, a veces está bien enviar intencionalmente una vulnerabilidad conocida a producción si tiene un impacto bajo. Incluso si tienes vulnerabilidades en producción, es posible que no se descubran o exploten antes de que actualices a una versión corregida, por lo que tienes tiempo para abordar este tipo de problemas, por lo general.

Por otro lado, el malware es bastante diferente. El malware es introducido intencionalmente en un paquete por un atacante, casi nunca por el mantenedor, y siempre terminará mal si envías malware a producción. No tienes unos días o semanas para mitigar el problema. Necesitas detectarlo realmente antes de instalarlo en tu computadora portátil o en un servidor de producción. Pero en la cultura actual de desarrollo rápido, una dependencia maliciosa puede actualizarse y fusionarse en muy poco tiempo. Y lamentablemente, esto conduce a un mayor riesgo de ataques a la cadena de suministro, porque cuanto más rápido actualices tus dependencias, menos ojos habrán tenido la oportunidad de revisar el código. Realmente creo que necesitamos un nuevo enfoque para detectar y bloquear dependencias maliciosas. Pero antes de entrar en eso, profundicemos un poco más en cómo funciona realmente un ataque a la cadena de suministro y sus mecanismos.

Descargamos cada paquete en NPM y pasamos unas semanas investigando. La descarga fue de 100 gigabytes de metadatos y 15 terabytes de paquetes tarballs. Mientras investigábamos estos metadatos y todos estos paquetes, notamos algunas tendencias en los tipos de ataques que vimos. Voy a repasar estos ataques. Estos son los que encontramos. Entonces, hay vectores de ataque, que es cómo el atacante te engaña y te hace ejecutar su código en primer lugar. Y luego, hay tácticas, que es lo que realmente hace el código de ataque o las técnicas que utiliza el atacante para ocultar su código. Así que hablemos de los vectores de ataque. El primer y más común vector de ataque es el typo squatting. El typo squatting es cuando un atacante publica un paquete que tiene un nombre muy similar a un paquete legítimo y popular. Entonces, puedes ver aquí que hay dos paquetes con nombres muy similares y uno de ellos es malware y el otro es el paquete real, pero supongo que sería difícil para ti saberlo sin abrir estos paquetes para ver qué hay dentro.

5. Malware Package and Dependency Confusion

Short description:

Abramos el paquete de malware y veamos qué está haciendo. Utiliza un script de instalación, que es una técnica común para el malware. El código está fuertemente ofuscado, pero definitivamente no es algo que quieras ejecutar. Otro vector de ataque es la confusión de dependencias, donde las herramientas internas instalan accidentalmente versiones públicas de paquetes. Encontramos muchos ataques de confusión de dependencias con código malicioso que afectan a varias organizaciones.

Entonces, abramos el paquete de malware y veamos qué está haciendo. Aquí puedes ver que está utilizando un script de instalación, que es una técnica muy común que utiliza el malware. Y si abres este script de instalación para ver el código, verás que el archivo está fuertemente ofuscado. Pero puedo decirte, incluso sin saber exactamente qué hace este código, puedes estar seguro de que no es algo que quieras ejecutar en tu máquina. El siguiente vector de ataque que vimos se llama confusión de dependencias. Esto está bastante relacionado con el typo squatting. La confusión de dependencias ocurre cuando una empresa publica paquetes en un registro interno de NPM y utiliza un nombre que aún no ha sido tomado en el registro público de NPM. Luego, un atacante puede registrar un paquete con el mismo nombre que la versión pública y confundir a las herramientas internas, de modo que las herramientas internas instalarán accidentalmente la versión pública. Por eso se llama ataque de confusión de dependencias. Al revisar los paquetes de NPM recientemente eliminados, pudimos encontrar un montón de posibles ataques de confusión de dependencias, y la mayoría de estos paquetes tenían código malicioso. Todos estos paquetes tienen nombres que parecen entrar en conflicto con los nombres de paquetes internos de la empresa. Aquí puedes ver una gran cantidad de organizaciones diferentes, incluyendo gobiernos, que se vieron afectados por esto. Y aquí hay algunos más, claramente dirigidos a estas empresas específicas.

6. Hijacked Packages and Attack Tactics

Short description:

Los paquetes secuestrados son un vector común que utilizan los criminales para infiltrarse en comunidades e infectar paquetes populares. Las tácticas de ataque incluyen malware en scripts de instalación y el uso privilegiado de API para robar secretos. Los scripts de instalación tienen usos legítimos, lo que dificulta desactivarlos. Un ejemplo de uso privilegiado de API es realizar solicitudes HTTP para exfiltrar datos, mientras que otra técnica utiliza DNS para la exfiltración.

Aquí en esta lista. Y finalmente, el tercer vector que vemos mucho son los paquetes secuestrados. Entonces, estos son los que generalmente se ven mucho en las noticias. Entonces, los criminales y ladrones encuentran formas de infiltrarse en nuestras comunidades e infectar paquetes populares. Una vez que infectan un paquete popular, una vez que lo controlan y pueden publicar en él, robarán credenciales o instalarán puertas traseras o abusarán de los recursos informáticos para la minería de criptomonedas. Y esto sucede por diversas razones. A veces es porque un mantenedor elige una contraseña débil o reutiliza una contraseña o tal vez el mantenedor tiene malware en su computadora portátil. Esto tampoco se ayuda por el hecho de que NPM no exige la autenticación de dos factores para todas las cuentas actualmente, aunque están comenzando a exigirlo para las cuentas más populares. Y finalmente, a veces los mantenedores simplemente son engañados y dan acceso a un actor malicioso. Esto se debe en parte al hecho de que los mantenedores están sobrecargados de trabajo y cuando alguien ofrece ayuda, a veces es difícil decir que no a la ayuda. Por lo tanto, esto también es un gran vector. Ahora hablemos de algunas tácticas de ataque. Entonces, ¿qué hace realmente este código de ataque? Como mencionamos, los scripts de instalación son un vector enorme. La mayoría del malware se encuentra en los scripts de instalación. Y esta es una cita de un artículo que mencionamos anteriormente. La mayoría de los paquetes maliciosos, en realidad el 56%, inician sus rutinas al momento de la instalación, lo cual puede deberse a un manejo deficiente de código arbitrario durante la instalación. En el gestor de paquetes npm, se permite que los paquetes simplemente digan: `oye, cuando se instale este paquete, queremos ejecutar algún código`. Y desafortunadamente, los scripts de instalación también tienen algunos usos legítimos. Por lo tanto, no podemos simplemente desactivarlos. No es un problema fácil de resolver. Echemos un vistazo a solo un ejemplo. Otro ejemplo de un script de instalación, nuevamente, lo verás aquí mismo en el archivo package.json, muy común. Lo siguiente es el uso privilegiado de API. Vemos paquetes que acceden a la red, acceden al sistema de archivos y acceden a variables de entorno. Esto es muy, muy común porque cuando un atacante ejecuta código, lo que quieren hacer es robar algunos secretos y necesitan la red para exfiltrar esos secretos. Este es un ejemplo típico de malware que hace eso. Puedes ver aquí que está haciendo una solicitud HTTP a una dirección IP y está enviando algunos datos. Los datos que está enviando son process.env, que contiene todas las variables de entorno en el entorno. Y aquí hay otro archivo que incluye, que es una técnica de exfiltración diferente que utiliza DNS en lugar de HTTP. La forma en que funciona es que crea un resolutor DNS y luego hace... Recopila las variables de entorno.

7. Obfuscated Code and Code Discrepancy

Short description:

El código ofuscado es difícil de entender a simple vista, pero existen herramientas que pueden ayudar a desofuscarlo. Los atacantes pueden publicar un código diferente en npm que en GitHub, lo que dificulta evaluar los paquetes basándose en el código de GitHub.

y luego realiza una búsqueda DNS con esas variables como subdominio. Por lo tanto, es simplemente otra forma de extraer los data del sistema. Y finalmente, tenemos el código ofuscado. Así que echamos un vistazo a un ejemplo de esto anteriormente. El código ofuscado como este es obviamente muy difícil de ver a simple vista lo que está haciendo, aunque existen herramientas para intentar desofuscar código como este. También existe otro tipo de ofuscación, que es cuando los atacantes pueden publicar un código diferente en npm que en GitHub. Y, como mencioné anteriormente, cuando hacen eso, npm no facilita ver qué código está realmente en el paquete de npm. Por lo tanto, muchas personas que intentan evaluar un paquete se basarán en el código que está en GitHub y no hay garantía de que ese código sea el mismo.

8. Protecting Your App

Short description:

Hablemos de cómo puedes proteger tu aplicación. Trabajamos en un producto llamado Wormhole, con el objetivo de construir una forma segura y privada de enviar archivos. Implementamos medidas de seguridad, como considerar la seguridad desde el principio, pruebas, revisiones de código y una cuidadosa selección de dependencias.

Bien, ahora hablemos de cómo puedes proteger tu aplicación. Nos hicimos esta pregunta cuando estábamos trabajando en... Mi empresa estaba trabajando en un producto llamado Wormhole, que te permite compartir archivos con cifrado de extremo a extremo. Y nuestro objetivo era tratar de construir la forma más segura y privada de enviar archivos. Así que hicimos todas las cosas habituales de security que se nos ocurrieron. Pensamos en la security desde el principio del proceso de design. Escribimos pruebas, aplicamos revisiones de código y fuimos bastante cuidadosos con las dependencias que elegimos usar. Pero, sabes, aún sentíamos que podíamos hacerlo mejor. Y así comenzamos a pensar con mucho cuidado en este problema y en lo que podríamos hacer para mejorarlo.

9. Choosing Dependencies and Assessing Security

Short description:

Elige mejores dependencias y asume la responsabilidad del código que envías a producción. La popular licencia MIT destaca la necesidad de un cambio de mentalidad en cómo vemos el código abierto. Confiar en heurísticas para elegir dependencias significa que es posible que no conozcamos su verdadero comportamiento. Socket proporciona una herramienta para evaluar la seguridad de los paquetes, resaltando los scripts de instalación y el código binario/nativo. También se ofrecen puntuaciones de calidad. Por ejemplo, el paquete Angular Calendar tiene dependencias invasivas.

Lo primero que recomiendo es que intentes elegir mejores dependencias. Sabes, si envías código a producción, eres en última instancia responsable de él. Y, como industria, creo que necesitamos un cambio de mentalidad aquí porque la gente asume que puede simplemente instalar cosas de Internet y que será seguro. Y eso no siempre es cierto. Y si estás enviando código a producción que incluye código de código abierto, entonces ese código es parte de tu aplicación. Y tú eres en última instancia responsable del comportamiento de ese código. Y, sabes, la licencia de código abierto más popular, la licencia MIT, en realidad dice esto literalmente en la licencia, dice que el código de código abierto se proporciona tal cual, sin garantía de ningún tipo y en ningún caso el autor será responsable de cualquier reclamo, daño o responsabilidad. Y aunque esto es legalmente cierto, la mayoría de las personas no piensan en su código abierto de esta manera. Y creo que realmente necesitamos un cambio de mentalidad. Lo otro es que muy pocos de nosotros realmente leemos el código que enviamos a producción. Por lo tanto, confiamos en otras heurísticas para ayudarnos a elegir dependencias. Tal vez, miramos si el código hace el trabajo, si tiene una licencia de código abierto, si tiene buena documentación, si tiene muchas descargas y estrellas en GitHub, si tiene commits recientes, si tiene tipos y si tiene pruebas. Y realmente no profundizamos en el código más allá de esto. Lo que significa que no estamos conscientes de lo que el código puede estar haciendo. Por eso construimos una herramienta en Socket para ayudar con este problema. Así que puedes obtener rápidamente una idea de la security de un paquete. Y así es como se ve. Puedes ir a Socket y buscar paquetes para averiguar qué comportamiento tiene el paquete. Y en este ejemplo aquí, puedes ver que este paquete contiene scripts de instalación. Y eso se destaca de manera muy prominente en la página. Y este paquete también contiene código binario o nativo, lo que significa que no es fácil auditar el código. No es legible para humanos. Y ambos problemas se mencionan. Y en este caso, no necesariamente se trata de un ataque a la cadena de suministro en ningún sentido. Pero es bueno que esto se destaque de manera muy prominente para que puedas tomar una decisión informada si quieres usar este paquete o no. También puedes ver que tenemos puntuaciones de calidad muy útiles que aparecen en la parte superior de la página. Ahora, veamos otro ejemplo. Este paquete aquí, Angular Calendar, es bastante útil. Es un componente de calendario que aparece en la página y muestra un pequeño calendario. Pero si investigas sus dependencias, descubrirás que algunas de ellas son bastante invasivas.

10. Gestión de Dependencias y Seguridad

Short description:

Una de sus dependencias contiene scripts de instalación, ejecuta scripts de shell y accede al sistema de archivos y a la red. Investiga los paquetes en Socket antes de usarlos para tomar una decisión informada. Actualizar las dependencias requiere encontrar el equilibrio adecuado entre vulnerabilidades conocidas y ataques a la cadena de suministro. Auditar cada dependencia es una opción para aplicaciones críticas en seguridad, pero conlleva compromisos y desafíos.

cosas. Aquí, verás que una de sus dependencias contiene scripts de instalación. También ejecuta scripts de shell y accede al sistema de archivos y a la red. Probablemente esto no es algo que esperarías que hiciera un componente web. Por lo tanto, puede valer la pena investigar un poco más para averiguar qué está sucediendo aquí antes de usar este paquete. Otra cosa interesante que hacemos es que podemos resaltar cuando los paquetes hacen estas cosas y ponerlo directamente en línea en el código. Así que en este paquete aquí, lo abrí para ver los archivos. Y pude ver aquí que el módulo está accediendo a la red, así como a variables de entorno. Y puedo ver las líneas exactas donde el paquete está haciendo cada una de estas cosas. Y así es un poco más fácil tener una idea de lo que un paquete está haciendo antes de ejecutarlo. Si quieres investigar los paquetes en Socket antes de usarlos, esta es la URL que puedes usar. Y te recomiendo que eches un vistazo a algunos paquetes allí y uses esa información para tomar una decisión informada antes de seleccionar un paquete. Bien, otra cosa que puedes hacer es pensar en actualizar tus dependencias en el momento adecuado. ¿Qué quiero decir con esto? Hay una pregunta sobre, como, qué tan rápido debes actualizar tus dependencias. Y esta es en realidad una pregunta con la que también luchamos en nuestro equipo. Si, ya sabes, puedes pensarlo como si debemos actualizar lentamente, o debemos actualizar muy, muy rápido y de manera agresiva. Si actualizas demasiado lentamente, estás expuesto a vulnerabilidades conocidas. Y estás ejecutando código que es antiguo y que puede tener problemas, puede tener algunos errores que se han solucionado en la versión más reciente. Y así que hay algunas desventajas de actualizar demasiado lentamente. Por otro lado, si actualizas demasiado rápido, te expones a ataques a la cadena de suministro, porque ahora estás ejecutando código que puede haber sido publicado, ya sabes, literalmente ayer o en los últimos días, lo que significa que no has tenido tantos ojos capaces de revisar el código. Y así, ya sabes, si piensas en security, debes equilibrar, ya sabes, este compromiso, y realmente no hay una solución perfecta aquí. Es solo un problema difícil.

Otra idea es auditar cada dependencia. Así que, ya sabes, si estás construyendo una aplicación verdaderamente crítica en seguridad, como lo estábamos haciendo con Wormhole, entonces, ya sabes, una opción es leer literalmente cada línea de código de tus dependencias. Así que si, de nuevo, lo ponemos en un eje que va desde una auditoría completa en un extremo, leyendo cada línea de código, hasta YOLOing en el otro extremo, y, ya sabes, con YOLOing, me refiero a ¿hacer nada? ¿Con qué detalle debes auditar tus dependencias? Y lo que ves aquí es que estamos en la misma situación. Tenemos compromisos y realmente no hay buenas soluciones. Así que hacer una auditoría completa es algo que solo las empresas más grandes y ricas parecen hacer en la práctica. Es mucho trabajo. Por lo general, necesitas tener un equipo de security que revise cada uno de estos paquetes, y también tenemos que aprobarlos uno por uno y agregarlos a una lista de permitidos, lo cual es realmente lento. Y esto es costoso simplemente debido al tiempo y el esfuerzo que requiere. Por otro lado, no hacer nada y simplemente instalar lo que quieras sin siquiera mirar el código, tiene sus desventajas. Significa que eres vulnerable a ataques a la cadena

11. Automatización y Aplicación de GitHub

Short description:

Es arriesgado. Y la mayoría de los equipos optan por no hacer nada. Utilizamos la automatización para evaluar las dependencias y auditar manualmente los paquetes más sospechosos. La información de seguridad se muestra directamente en las solicitudes de extracción, lo que permite a los desarrolladores resolver problemas de seguridad antes de la implementación. Nuestra aplicación de GitHub realiza un informe completo de salud sobre las nuevas dependencias y deja comentarios sobre cualquier problema detectado. Mejora el proceso de revisión y solo plantea problemas que merecen atención. Prueba nuestra aplicación gratuita de GitHub en Socket.dev para bloquear typosquats, malware, código oculto, uso privilegiado de API y detectar actualizaciones sospechosas.

de suministro. Es arriesgado. Y una violación o mala security prensa puede ser costosa, especialmente a medida que los reguladores comienzan a tomar medidas enérgicas contra este problema. Y así, este es otro difícil compromiso. ¿Qué haces? Y la mayoría de los equipos, creo, optan por no hacer nada, pero creo que esto es solo un problema difícil. Entonces, una cosa que intentamos hacer cuando estábamos construyendo Wormhole es tratar de encontrar un punto intermedio. ¿Hay alguna manera de usar la automatización para hacer algo en el medio? Y así, lo que queremos hacer y lo que hemos hecho, es utilizar la automatización para evaluar automáticamente todas nuestras dependencias. De esta manera, podríamos utilizar el análisis estático para examinar los paquetes y buscar malware, código oculto, typos, ataques de squatting, y cosas por el estilo. Y de esta manera, solo podríamos auditar manualmente los paquetes más sospechosos. De esta manera, podríamos utilizar nuestros limitados recursos de equipo para examinar el código de los paquetes más sospechosos. Y esa es la forma más impactante en la que podríamos utilizar nuestro tiempo. Y así, esto me parece mucho mejor que un enfoque de todo o nada donde auditas todo o simplemente esperas lo mejor y no miras nada. Y luego, lo otro que queríamos hacer es asegurarnos de que la información de security se muestre directamente en las solicitudes de extracción para que los desarrolladores de nuestro equipo tengan la capacidad de resolver los problemas de security que vean antes de implementar en producción. Entonces, ¿cómo se ve esto en realidad? Esta es el bot que hemos creado. Se implementa como una aplicación de GitHub que puedes instalar en tu repositorio de GitHub. Y cada vez que ve que el archivo package.json o el archivo yarn.lock ha sido modificado, echará un vistazo a la nueva dependencia que se ha agregado y ejecutará un informe completo de salud sobre esa dependencia. Y si se encuentran problemas, dejará un comentario con el problema que se haya detectado. De esta manera, el desarrollador que revisa la solicitud de extracción puede ver y prestar atención a este posible problema. En esta captura de pantalla, puedes ver que instalé accidentalmente el paquete browser list en lugar de browserlist, lo cual es en realidad un error muy fácil de cometer. Y por esa razón, el paquete typo tiene alrededor de 700,000 descargas al año. Así que esto es realmente, realmente útil. Esto es el tipo de cosas que mejora tu proceso de revisión. Y tiene un costo muy bajo, ya que solo plantea problemas que realmente valen la pena tu atención. Y se ejecuta automáticamente. Entonces, si quieres probar esta aplicación, en realidad la hemos publicado para que cualquiera la use. Es gratuita. Puedes instalar nuestra aplicación de GitHub yendo a Socket.dev. Y te recomiendo que la pruebes y me digas qué opinas. Tiene muchas características geniales. En realidad, puede bloquear typosquats, como te mostré antes, pero también puede bloquear malware, detectar código oculto, detectar el uso privilegiado de API, como el uso del sistema de archivos o la red, procesos secundarios,

12. Análisis de Paquetes y Retroalimentación

Short description:

Tenemos 70 detecciones en cinco categorías diferentes: riesgo de la cadena de suministro, calidad, mantenimiento, vulnerabilidades conocidas y licencia. Nuestras reglas de análisis estático se centran en problemas accionables que los usuarios del paquete deben conocer. Prueba Socket.dev para explorar estos problemas y proporcionar retroalimentación. Nuestro objetivo es mejorar la seguridad de la cadena de suministro en 2022 y protegerla mejor que nunca. Comparte tus comentarios conmigo por correo electrónico o Twitter. También estamos contratando en Socket si estás interesado en asegurar la cadena de suministro de software.

etc. Y también puede detectar actualizaciones sospechosas. Estas son actualizaciones que cambian significativamente el comportamiento del paquete. Así que tenemos muchas cosas que buscamos en los paquetes. En realidad, tenemos 70 detecciones en cinco categorías diferentes. Tenemos riesgo de la cadena de suministro, calidad, mantenimiento, vulnerabilidades conocidas y licencia. Y escribimos, básicamente, estas son todas reglas de análisis estático que escribimos. Puedes pensar en esto como un linter de alguna manera. Así que está mirando el código del paquete y buscando estos diferentes problemas. Intentamos enfocar todas las reglas en problemas que son algo que tú, como usuario del paquete, realmente quieres saber, y no cosas que requieren mucho conocimiento de los detalles internos del paquete. Entonces, las cosas que encuentra deben ser accionables para ti como desarrollador que elige usar este paquete. Y eso es lo que intentamos hacer en el desarrollo de nuestras reglas aquí. Así que sí, si quieres probar esto, si quieres explorar nuestro sitio web y ver estos diferentes problemas, puedes probarlo en socket.dev. Y lo hemos hecho gratuito para siempre para el código abierto, y si tienes un repositorio privado, es gratuito mientras estamos en beta, y realmente quiero que la gente nos dé una oportunidad y comparta sus comentarios con nosotros, porque este problema de seguridad de la cadena de suministro es grande y cada vez más grande. Y realmente quiero que la comunidad comparta sus comentarios conmigo sobre esto. Y creo que juntos podemos hacer un buen trabajo mejorando la seguridad de la cadena de suministro en 2022 y hacer que 2022 no sea el año en que la cadena de suministro sea destruida, sino el año en que esté protegida mejor que nunca. Así que por favor comparte tus comentarios conmigo. Aquí está mi correo electrónico y mi Twitter, y también estamos contratando en Socket si estás interesado en trabajar en este proyecto y ayudar a asegurar la cadena de suministro de software. Gracias por tu tiempo. Hola, gracias por unirte a nosotros. Me alegra estar aquí, y no quise asustarte. Hay mucho por hacer, hay muchas soluciones, así que no deberías asustarte demasiado. Creo que podemos resolver el problema, con suerte. Con suerte, bueno, la mayoría de las personas están muy preocupadas y quieren hacer más. Bueno, eso es bueno. Me siento feliz de que las personas quieran hacer más, pero deberían hacer más. Bueno, pueden hacerlo con Socket.dev. ¿Qué opinas de esto? ¿Esta desviación, 70% y luego 27% moderado, y 3%, en absoluto? En realidad, me sorprende gratamente que tengamos tantos desarrolladores preocupados por el problema. Ahora, no sé cuánto influyó mi charla en su votación mientras la veían. Probablemente estaba ayudando a aumentar este número con todos los ejemplos que mencioné de malware y ataques a la cadena de suministro que han ocurrido en NPM. Pero creo que es alentador que la gente quiera hacer más y que realmente haya algunas cosas que puedan hacer para ayudar con eso, incluyendo instalar Socket o probar nuestras herramientas.

13. Diferenciando Socket de otras herramientas de seguridad

Short description:

Existen múltiples escáneres de seguridad, pero lo que distingue a Socket es su capacidad para analizar el código real de un paquete y determinar sus capacidades. Socket va más allá de la simple detección de vulnerabilidades y protege contra malware y ataques a la cadena de suministro. Este enfoque garantiza que los usuarios estén conscientes de los posibles riesgos antes de instalar un paquete.

Sí. Entonces, la primera pregunta es de mí mismo. Hay múltiples escáneres de seguridad. Sé que de memoria, tenemos StackHawk y Sneak. ¿Y qué hace que su producto sea diferente? Sí. Creo que lo principal a tener en cuenta al evaluar herramientas como esta es si te protegerán no solo de vulnerabilidades, sino también de malware y ataques a la cadena de suministro. Es casi como un estándar. Diría que hay herramientas para escanear vulnerabilidades. Eso es lo que hace el comando NPM audit. Eso es lo que hace Dependabot. Hay muchas cosas disponibles que hacen este tipo de escaneo básico de vulnerabilidades. La verdadera amenaza que hemos visto en el último año proviene de este nuevo tipo de ataque, los ataques a la cadena de suministro que generalmente implican que un paquete sea secuestrado y se agregue código malicioso. Y hay un período en el que, antes de que se descubra, cualquier persona que instale ese paquete secuestrado tendrá su computadora comprometida. Y si tienes mala suerte, esto no se descubre durante un par de semanas y llega a producción. Y esto ha sucedido en muchos casos en el pasado. Por lo tanto, creo que la forma en que queremos distinguir a Socket de todo lo demás que hay es qué puedes hacer realmente para escanear un paquete, no mirando una database para ver si un investigador de seguridad encontró un problema con esto y escribió un informe al respecto hace un par de semanas, la pregunta es realmente, ¿qué hará este paquete? ¿Cuáles son sus capacidades? ¿Va a comunicarse con la red y leer archivos? Vamos a analizar el código real del paquete antes de instalarlo para responder esas preguntas por ti. Y eso es realmente la diferencia. Y ahí es donde creo que debemos ir con todas las herramientas en este espacio desecurity.

14. Desafíos con los enfoques existentes

Short description:

Un mantenedor que agrega malware o código malicioso a su propio paquete plantea un desafío significativo para los enfoques existentes como la firma de código y las bases de datos de vulnerabilidades. El incidente destaca la necesidad de analizar el código real para comprender su comportamiento. Leer todo el código en las dependencias lleva tiempo, por lo que los escáneres de seguridad pueden ser útiles.

Y un poco relacionado. Entonces no recuerdo el nombre del paquete, pero había un paquete muy popular, y hace uno o dos meses, el autor lo eliminó de GitHub y dijo, free Aaron Swartz, algo así. ¿Recuerdas de qué estoy hablando? Sí, esto también se detectaría porque hay un cambio de código significativo, ¿verdad? Así que también se detectan esos problemas. Sí. No es suficiente, este es un ejemplo perfecto en realidad, donde muchas de las aproximaciones que otras empresas y otros equipos que intentan resolver este problema están tomando no habrían detectado realmente este problema porque aquí tienes un mantenedor que agrega malware o código malicioso a su propio paquete. Y confiar en cosas como la firma de código, por ejemplo, no habría hecho nada en este caso porque el mantenedor mismo tendría las claves para firmar su código. O si estás buscando en una database de vulnerabilidades, esto no estará en una database de vulnerabilidades. Y así, lo siento, estoy recibiendo una llamada telefónica en este momento. Sí. De todos modos, creo que ese incidente fue realmente ilustrativo de los desafíos con los otros enfoques y por qué realmente lo que quieres hacer es entrar en el código real y ver qué está haciendo. Sí. Solía trabajar en una empresa de tecnología médica. Y siempre era el escenario si hacías una actualización, entonces en realidad tendrías que leer todo el código que era nuevo. Y sí, así que traté de evitar cualquier dependencia porque bueno, eso es demasiado trabajo leer todo lo que es nuevo en todas tus dependencias.

15. Realms and Deno's Command Line Flags

Short description:

Realms es una propuesta interesante que podría potencialmente aislar el código y aplicar restricciones de comportamiento en tiempo de ejecución para los paquetes. Los flags de línea de comando de Deno, aunque a nivel de proceso, ofrecen algunas ideas interesantes. Sin embargo, son menos efectivos para detener los ataques a la cadena de suministro.

Sí. Pero sí, tener escáneres de seguridad sería de gran ayuda. La primera pregunta es de ¿Realms abordará algunos de estos problemas? Así que creo que Realms es una propuesta interesante. Y creo que han estado haciendo un buen progreso a través del comité de estándares. Aunque no estoy siguiéndolo muy de cerca. Así que puede que no sea la mejor persona para responder a esta pregunta, pero mi entendimiento es que debería haber alguna forma de utilizar esta característica, esta característica de Realms, para aislar el código. Y sé que es realmente difícil hacer que un sandbox funcione de manera confiable, pero si esta característica funciona de la manera en que creo que lo hace y si hay un montón de asteriscos adjuntos a esta afirmación, eventualmente podríamos ser capaces de utilizar una característica como esta para ir más allá de simplemente analizar un paquete y decir, OK, esto va a comunicarse con la red o esto va a comunicarse con el sistema de archivos. Sino que en realidad, en tiempo de ejecución, ser capaces de decir que un paquete, este paquete declara que nunca necesita comunicarse con la red y de hecho vamos a hacer cumplir eso en tiempo de ejecución. Nos aseguraremos de que no realice comportamientos XYZ que no necesita. Y si de repente comienza a hacer eso, entonces podríamos bloquearlo. Creo que también es interesante ver cómo Deno maneja sus flags de línea de comando, donde para aquellos que han jugado un poco con Deno, tiene esta especie de idea de permitir fs, permitir net que se pueden pasar en la línea de comando y eso es bastante interesante. Aunque eso es principalmente para todo un proceso y no a nivel de paquete, lo que lo hace menos útil para detener los ataques a la cadena de suministro, porque generalmente tienes que permitir la red si quieres construir un servidor web. Y así no te brinda mucha protección si una de esas dependencias se ve comprometida. Pero

16. Securing Dependencies and Prioritizing Security

Short description:

Conseguir que los ingenieros se preocupen por asegurar las dependencias es un problema difícil. Siempre hay deuda técnica y una lista de tareas pendientes para lanzar nuevas funciones. Sin embargo, como artesanos, debemos sentir orgullo por el software que creamos y asegurarnos de que no comprometa los datos del usuario. Con las herramientas adecuadas, como Sockett, asegurar las dependencias puede ser más fácil e incluso agradable. La seguridad debe tener prioridad sobre otros aspectos del desarrollo, como configuraciones de línea de comandos sofisticadas y animaciones.

es un punto interesante para comenzar. Sí, está bien. Gracias. Tenemos un minuto más. Así que es de una colina al bosque. ¿Qué sugerirías para lograr que los ingenieros se preocupen por asegurar nuestras dependencias? Siento que porque nadie lee el código, etc., solo se preocuparán cuando algo ya salga mal. No, es un problema realmente difícil. Quiero decir, es realmente difícil porque, ya sabes, los ingenieros ya tienen mucho que hacer. Siempre hay deuda técnica que arreglar. Hay mucho trabajo pendiente y solo estamos tratando de lanzar funciones y hacer nuestro trabajo. Y agregar otra cosa a la lista de tareas de los desarrolladores es mucho pedir. Creo que un argumento que les haría a esos desarrolladores para convencerlos de que se preocupen es que, al final, somos artesanos y debemos ser, supongo, artesanos. Realmente debemos preocuparnos por el trabajo que creamos. Y debemos sentir orgullo por el software que creamos y que lanzamos a producción. Y parte de eso es asegurarse de que el código que lanzamos se comporte como se espera y no comprometa nuestros datos de usuario o comprometa a nuestros usuarios de ninguna manera. Así que realmente es parte de la responsabilidad de ser un ingeniero. Y con las herramientas adecuadas, y soy parcial pero creo que Sockett está haciendo un buen trabajo aquí, puedes hacer que no sea tan difícil y tan pesado para el desarrollador y convertirlo en algo divertido de hacer como parte del proceso de desarrollo.

Sí. Bueno, en realidad, security, si lo piensas bien, debería ser después tal vez de accessibility. No, tal vez incluso antes de accessibility. Es lo más importante. Es más importante que tus configuraciones sofisticadas de línea de comandos. Es más importante que tus animaciones de 60 FPS. Es lo más importante. Sí, eso también es una respuesta, creo. Bueno, se nos acabó el tiempo para preguntas y respuestas, pero Feroz estará en una sala de oradores en spatial chat. Así que puedes hacer clic en el enlace en la línea de tiempo a continuación. Feroz, muchas gracias por asustarnos y entretenernos. Ha sido un placer tenerte aquí. Sí, gracias Mateen. Aprecio las buenas preguntas y ha sido un honor estar aquí. Así que muchas gracias. Lo aprecio. Bien, adiós. Adiós.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.
JSNation 2023JSNation 2023
30 min
The State of Passwordless Auth on the Web
Can we get rid of passwords yet? They make for a poor user experience and users are notoriously bad with them. The advent of WebAuthn has brought a passwordless world closer, but where do we really stand?
In this talk we'll explore the current user experience of WebAuthn and the requirements a user has to fulfill for them to authenticate without a password. We'll also explore the fallbacks and safeguards we can use to make the password experience better and more secure. By the end of the session you'll have a vision for how authentication could look in the future and a blueprint for how to build the best auth experience today.
JSNation Live 2021JSNation Live 2021
19 min
Multithreaded Logging with Pino
Top Content
Almost every developer thinks that adding one more log line would not decrease the performance of their server... until logging becomes the biggest bottleneck for their systems! We created one of the fastest JSON loggers for Node.js: pino. One of our key decisions was to remove all "transport" to another process (or infrastructure): it reduced both CPU and memory consumption, removing any bottleneck from logging. However, this created friction and lowered the developer experience of using Pino and in-process transports is the most asked feature our user.In the upcoming version 7, we will solve this problem and increase throughput at the same time: we are introducing pino.transport() to start a worker thread that you can use to transfer your logs safely to other destinations, without sacrificing neither performance nor the developer experience.

Workshops on related topic

Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
React Summit 2023React Summit 2023
56 min
0 to Auth in an hour with ReactJS
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool. There are multiple alternatives that are much better than passwords to identify and authenticate your users - including SSO, SAML, OAuth, Magic Links, One-Time Passwords, and Authenticator Apps.
While addressing security aspects and avoiding common pitfalls, we will enhance a full-stack JS application (Node.js backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session securely for subsequent client requests, validating / refreshing sessions- Basic Authorization - extracting and validating claims from the session token JWT and handling authorization in backend flows
At the end of the workshop, we will also touch other approaches of authentication implementation with Descope - using frontend or backend SDKs.
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
WorkshopFree
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
Workshop
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible.
All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL.
In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours.
If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.