5 Formas en las que podrías haber hackeado Node.js

Rate this content
Bookmark

Todos los lenguajes son o fueron vulnerables a algún tipo de amenaza. Soy parte del equipo de seguridad de Node.js y durante el año 2022, hemos realizado muchas versiones de seguridad y algunas de ellas fueron realmente difíciles de pensar.


¿Sabías que puedes ganar dinero encontrando vulnerabilidades críticas en Node.js? En esta charla, te mostraré 5 formas en las que podrías haber hackeado Node.js y cómo el equipo de Node.js lidia con las vulnerabilidades.

22 min
05 Jun, 2023

Video Summary and Transcription

El equipo de seguridad de Node.js es responsable de abordar las vulnerabilidades y recibe informes a través de HackerOne. La charla discute varias técnicas de hacking, incluyendo inyecciones DLL y ataques de reenvío DNS. También destaca las vulnerabilidades de seguridad de Node.js como el contrabando de solicitudes HTTP y la validación de certificados. Se enfatiza la importancia de utilizar el túnel HTTP proxy y el modelo de permisos experimental en Node.js 20. NearForm, una empresa especializada en Node.js, ofrece servicios para escalar y mejorar la seguridad.

Available in English

1. Introducción al equipo de seguridad de Node.js

Short description:

Hola a todos. Mi nombre es Rafael Gonzaga. Soy un ingeniero de personal en Neo4m. Soy miembro de algunas organizaciones de código abierto y soy líder del grupo de trabajo de seguridad de Node.js DSC. Recientemente, comencé a codificar en vivo en Twitch. En primer lugar, todas las CV mencionadas aquí fueron abordadas. Asegúrese de estar utilizando una versión segura de Node.js. El equipo de seguridad de Node.js está compuesto por el equipo de selección de Node.js y el grupo de trabajo de seguridad. ¿Encontraste una posible vulnerabilidad de seguridad? Por favor, no abras un problema público. El proceso de envío de vulnerabilidades de Node.js es bastante sencillo. Encuentras una posible vulnerabilidad y vas a HackerOne. El equipo de Node.js recibe tu informe y lo evalúa según nuestro modelo de amenazas.

Mi nombre es Rafael Gonzaga. Soy un ingeniero de personal en Neo4m. Soy de Brasil. Soy miembro de algunas organizaciones de código abierto y soy miembro de DSC de Node.js, líder del grupo de trabajo de seguridad. Soy un lanzador de Node.js, así que si alguna de las compilaciones de Node.js te falla, probablemente fue culpa mía, ¿de acuerdo?

Recientemente, comencé a codificar en vivo en Twitch. Así que si te gusta este tipo de contenido, sígueme también allí. Estoy disponible en todas las redes sociales.

Entonces, en primer lugar, antes de mostrar las partes malas de Node.js, me gustaría dar un aviso legal diciendo que todos los lenguajes lo tienen e introduje un concepto de seguridad en el lenguaje de programación. Por ejemplo, en primer lugar, todas las CV mencionadas aquí fueron abordadas, ¿de acuerdo? Asegúrate de estar utilizando una versión segura de Node.js. Por ejemplo, escribí un paquete llamado IsMyNodeVulnerable. Si simplemente llamas a npx is my node vulnerable, podrás ver si estás utilizando una versión vulnerable de Node.js. Si lo estás, por favor, actualízalo, ¿de acuerdo?

Entonces, en primer lugar, presentaré el equipo de seguridad de Node.js. Básicamente, el equipo de seguridad de Node.js consta de dos grupos. El primero es el equipo de selección de Node.js. Está compuesto por el Comité Técnico de Dirección de Node.js, contribuyentes específicos de Node.js con experiencia en seguridad, el equipo de lanzamiento de Node.js y el equipo de compilación, ¿de acuerdo? Y el segundo grupo es el grupo de trabajo de seguridad. Es un grupo de trabajo de la comunidad. Trabajamos en varias iniciativas de seguridad y el modelo de permisos experimental es solo una de ellas. Así que puedes formar parte de él. Solo envíame un mensaje, envíame un mensaje, puedes ir al repositorio y podrás verlo, ¿de acuerdo?

Entonces vamos a lo que importa. ¿Encontraste una posible vulnerabilidad de seguridad? Por favor, no abras un problema público. Estarás revelando la vulnerabilidad y eso es crucial. Eso es muy malo para los mantenedores, porque necesitamos apurarnos. Necesitamos hacer muchas cosas en un corto período de tiempo y eventualmente es muy malo, en realidad. Por lo general, consulta el archivo security.md en el archivo Node.js, podrás verlo. Si vas a HackerOne, también podrás verlo. Entonces, el proceso de envío de vulnerabilidades de Node.js es bastante sencillo, ¿de acuerdo? Encuentras una posible vulnerabilidad y vas a HackerOne. HackerOne es una plataforma donde puedes enviar cualquier posible vulnerabilidad y la evaluamos. Y luego completas el formulario y el equipo de selección de Node.js recibe tu informe. Y lo evaluamos según nuestro modelo de amenazas.

2. Hacking Node.js: Inyecciones DLL

Short description:

Y si eso es aceptado, prepararemos una solución de seguridad y un lanzamiento de seguridad. Puedes ganar dinero a través de programas de reducción de errores. Presentaré cinco formas en las que podrías haber hackeado Node.js. La primera es la inyección de DLL, una técnica utilizada por los hackers para inyectar archivos de biblioteca de vínculos dinámicos maliciosos en un proceso en ejecución. Tomemos este ejemplo: estás en Windows, instalas un juego y se instala un paquete malicioso que contiene un archivo providers.dll. Este paquete requiere crypto y, cuando se inicializa, buscará providers.dll en el directorio de trabajo actual.

Y si eso es aceptado, prepararemos una solución de seguridad y un lanzamiento de seguridad. ¿De acuerdo? Así que, bueno, puedes ganar dinero a través de programas de reducción de errores. ¿De acuerdo?

Entonces, en esta charla, presentaré cinco formas en las que podrías haber hackeado Node.js. Sin embargo, es importante mencionar que todas las vulnerabilidades eran una amenaza. Así que no te preocupes.

La primera es la inyección de DLL, ¿de acuerdo? Hola, usuarios de Windows. La inyección de DLL es una técnica utilizada por los hackers para inyectar archivos de biblioteca de vínculos dinámicos maliciosos en un proceso en ejecución, modificando así su comportamiento o obteniendo acceso no autorizado a sus recursos.

Tomemos este ejemplo, ¿de acuerdo? Estás en Windows. Nuevamente, lo siento, usuarios de Windows. Luego, digamos que instalas cualquier tipo de juego. La mayoría de los juegos hoy en día necesitan abrir SSL. Así que tienes SSL abierto en tu máquina. Y luego estás siguiendo una publicación de blog, pero escribiste mal Fastify. Y luego instalas Fastify, ¿de acuerdo? Y luego este paquete, este es un paquete malicioso que contiene un archivo providers.dll. Y el contenido de este dll es básicamente lo más peligroso que puedes hacer en Windows, que es abrir la calculadora, ¿de acuerdo? Y luego, este paquete requiere crypto, en realidad, al principio. Cada vez que requieres crypto, el módulo HTTPS o TLS en Node.js, inicializará OpenSSL. Y cuando se inicializa, buscará providers.dll en el directorio de trabajo actual. Y por ejemplo, si el paquete, el paquete malicioso, contiene solo un script post-install que llama a las versiones de NPM que, en el fondo, requieren crypto, inicializará OpenSSL y cargará providers.dll y luego ocurre el ataque. Ahora piensa que ya no carga providers.dll en el directorio de trabajo actual.

3. DNS Rebinding Attack

Short description:

Hablemos sobre el ataque de DNS rebinding. DNS rebinding es una técnica utilizada para engañar a los usuarios y hacer que visiten un sitio web malicioso en lugar del deseado. Un atacante puede utilizar DNS rebinding para redirigir a los usuarios a una dirección IP inválida. Luego, el atacante puede aprovechar el servidor DNS, que no está protegido por SSL o TLS, para realizar un ataque de intermediario. Al mapear la solicitud a su dirección IP con un tiempo de vida corto, el atacante puede interceptar la solicitud de la página y cargar contenido malicioso. El tiempo de vida asegura que los mensajes no queden atrapados en un bucle y funciona como un temporizador para la entrega de mensajes.

Entonces, pasemos al segundo. Hablemos sobre el ataque de DNS rebinding. Cuando quieres visitar un sitio web como xample.com o jsnation.com, tu computadora necesita conocer la dirección IP de ese sitio web. El DNS es como una guía telefónica para Internet que ayuda a tu computadora a encontrar la dirección IP correcta en el DNS.

Imagina que alguien quiere engañarte para que visites un sitio web malicioso en lugar del que tenías la intención de visitar. Podrían utilizar algo llamado ataque de DNS rebinding para hacer esto. Supongamos que hay un usuario que utiliza node-inspect. Esto abrirá el depurador de Node.js. Luego, accedes a attacker.com y attacker.com te redirige a una dirección IP inválida. Node.js no estaba validando correctamente esa dirección IP. Luego, va al navegador y el navegador dice: `OK, esta no es una dirección IP real, preguntaré al servidor DNS`. El servidor DNS se dirige a un servidor DNS con una conexión comprometida, lo que significa que quiere el DNS o la dirección IP para el 10.0.2.555 en el puerto 9229. Y luego, podrías pensar: `Bueno, el atacante necesitaría acceder al servidor DNS y eso es difícil, en realidad no`. El DNS no está protegido por SSL o TLS. Entonces, si estás en la misma red, simplemente puede realizar un ataque de intermediario.

Entonces, bien. Supongamos que el atacante ahora tiene acceso al servidor DNS. Y luego, cuando solicitas la dirección IP de esa dirección IP inválida, mapea la solicitud a su dirección IP con un tiempo de vida corto. ¿De acuerdo? Y luego, la página intenta cargar un slash JSON. El tiempo de vida es básicamente un número especial que se utiliza para asegurarse de que los mensajes enviados a través de Internet no queden atrapados en un bucle o sigan yendo para siempre. Funciona como un temporizador que le indica a la computadora encargada de enviar el mensaje cuándo detenerse y tratar de entregarlo si lleva demasiado tiempo. ¿De acuerdo? Por ejemplo, solicito al servidor web la dirección IP de axample.com y recibo un tiempo de vida, un tiempo de vida de, no sé, 60 segundos. Y luego, si solicito la dirección IP de ese DNS en ese corto período de tiempo, antes de 60 segundos, recibo la misma IP. Si solicito la dirección IP después de los 60 segundos, realizará otra llamada DNS. ¿De acuerdo? Entonces, bien. Luego carga el SlashJSON bajo la IP de ataque y luego el tll expira. Y esta vez, requiere nuevamente al servidor DNS y el atacante lo envía al localhost.

4. Node.js Security Vulnerabilities

Short description:

Entonces, expondrá el SlashJSON bajo tu localhost a la IP del atacante, lo que significa que mostrará la URL del WebSocketDebugger, y luego el atacante obtendrá acceso a tu máquina. Bueno, puede ejecutar lo que quieras, o ella quiera, en tu instancia comprometida de Node.js. El tercero es el contrabando de solicitudes 80PS. Hagamos una analogía aquí. Imagina que estás en un restaurante y quieres pedir una hamburguesa. Pero ahora imagina que alguien más en la mesa quiere pedir una soda. Entonces, escriben una nota con el pedido de la soda y la esconden dentro de tu pedido de hamburguesa, como un mensaje secreto. Hagámoslo de manera técnica ahora. Supongamos que simplemente haces una solicitud y luego tienes una CDN. Y luego tienes una red privada debajo, digamos que tengo un microservicio llamado usuarios. Y para que esto suceda en la vulnerabilidad de Node.js, básicamente, la codificación de transferencia era un encabezado necesario para explotarlo. Imagina que hay un usuario malicioso que envía una solicitud con el siguiente contenido, publicar hoy slash. Y luego uno de los encabezados es el X punto y coma slash n. Esa es la nueva línea. Pero se envía un encabezado no válido usando solo LF, el slash n. Pero aún así está siendo procesado por Node.js, ¿de acuerdo? Entonces, ¿qué estaba sucediendo detrás de escena? Esta solicitud va a la CDN, la CDN la envía al servidor, el servidor la interpreta como dos solicitudes, un POST a la barra y un GET a las cosas de administración, aunque solo envié una solicitud.

Entonces, expondrá el SlashJSON bajo tu localhost a la IP del atacante, lo que significa que mostrará la URL del WebSocketDebugger, y luego el atacante obtendrá acceso a tu máquina. Bueno, puede ejecutar lo que quieras, o ella quiera, en tu instancia comprometida de Node.js. Entonces eso es muy malo. Es difícil de replicar, ¿de acuerdo? Pero sigue siendo un buen ataque. Después de resolver esto, recibimos otro informe de que, bueno, se solucionó el DNS rebinding, pero hay un caso especial en Apple, y luego lo solucionamos nuevamente. Sucede. Entonces sí. El tercero es el contrabando de solicitudes 80PS. Entonces hagamos una analogía aquí. Imagina que estás en un restaurante y quieres pedir una hamburguesa. Le das tu pedido al camarero, quien lo lleva a la cocina. Pero ahora imagina que alguien más en la mesa quiere pedir una soda. Y quieren hacerlo de manera astuta. Entonces tú no ves. Escriben una nota con el pedido de la soda y la esconden dentro de tu pedido de hamburguesa, como un mensaje secreto, ¿de acuerdo? Entonces el camarero toma tu pedido de hamburguesa y ve la nota para la soda escondida dentro. Pero debido a que la nota está escondida, el camarero no se da cuenta de que hay dos pedidos separados. Y luego el camarero te trae una hamburguesa y una soda, aunque solo pediste una hamburguesa, ¿de acuerdo? Hagámoslo. Hagámoslo de manera técnica ahora, ¿de acuerdo? Supongamos que simplemente haces una solicitud y luego tienes una CDN. Y luego tienes una red privada debajo, digamos que tengo un microservicio llamado usuarios, ¿de acuerdo? Y luego puedes tener, no sé, varios servidores. Tienes un equilibrador de carga, un proxy inverso. Realmente no importa. Y para que esto suceda en la vulnerabilidad de Node.js, básicamente, la codificación de transferencia era un encabezado necesario para explotarlo. Entonces, básicamente, la codificación de transferencia es un encabezado que sirve para decirle al servidor cómo interpretar los bytes en la solicitud del encabezado, ¿de acuerdo?, en el cuerpo del encabezado también. Entonces imagina que hay un usuario malicioso que envía una solicitud con el siguiente contenido, publicar hoy slash. Y luego uno de los encabezados es el X punto y coma slash n. Esa es la nueva línea. Esto estaba pasando por alto la validación de Node.js LLTP. Entonces, Node.js esperaba un CLLF, que es retorno de carro y avance de línea, para separar correctamente los encabezados. Pero se envía un encabezado no válido usando solo LF, el slash n.

5. Navigating Node.js Security Vulnerabilities

Short description:

Pero aún está siendo procesado por Node.js, ¿de acuerdo? Entonces, ¿qué estaba sucediendo detrás de escena? Esta solicitud va a la CDN, la CDN la envía al servidor, el servidor la interpreta como dos solicitudes, un POST a la barra y un GET a las cosas de administración, aunque solo envié una solicitud. Entonces, tal vez las cosas de administración no estaban expuestas a la red, a la web, aunque podría hacer esta solicitud. Entonces eso es terrible, ¿de acuerdo? El otro es intentar leer desde rutas arbitrarias. Supongamos que estás en un host basado en Linux con varios usuarios y uno de los usuarios es malicioso. Un usuario malicioso crea un archivo falso openSSL.cnf que contiene la configuración maliciosa. El atacante puede modificar el generador de claves, alterar la configuración predeterminada y más. Node.js en el inicio intentaba leer un archivo llamado openSSL.cnf en esa ubicación específica. El atacante podría descubrirlo utilizando herramientas de utilidad de Linux como strace. Hemos abordado este problema y creado una prueba para resolverlo. El último es la validación de certificación. Supongamos que realizas una solicitud GET al servidor con una dirección IP de cliente que es diferente, como un servidor PROC. Puedes usar una herramienta de proxy de intermediario como HTTP Toolkit Proxy para interceptar las solicitudes del depurador.

Pero aún está siendo procesado por Node.js, ¿de acuerdo? Entonces, ¿qué estaba sucediendo detrás de escena? Esta solicitud va a la CDN, la CDN la envía al servidor, el servidor la interpreta como dos solicitudes, un POST a la barra y un GET a las cosas de administración, aunque solo envié una solicitud.

Entonces, tal vez las cosas de administración no estaban expuestas a la red, a la web, aunque podría hacer esta solicitud. Entonces eso es terrible, ¿de acuerdo?

El otro es intentar leer desde rutas arbitrarias. Básicamente, supongamos que estás en un host basado en Linux con varios usuarios y uno de los usuarios es malicioso, ¿de acuerdo? Esto ocurre muy a menudo en las universidades, ¿de acuerdo? Supongamos que un usuario malicioso crea un archivo falso openSSL.cnf que contiene la configuración maliciosa. openSSL.cnf es solo un archivo que contiene la configuración de seguridad para openSSL, ¿de acuerdo? Entonces el atacante puede hacer muchas cosas, como modificar el generador de claves, alterar la configuración predeterminada, y más. Y luego el usuario malicioso crea este falso openSSL.cnf en esa ubicación específica, io.js build ws.out.release y así sucesivamente y va a ese archivo largo. Y luego Node.js en el inicio intentaba leer un archivo llamado openSSL.cnf en esa ubicación específica. Fue un error de nuestra parte. Entonces el atacante podría descubrirlo utilizando herramientas de utilidad de Linux como strace. Lo usó para rastrear las llamadas al sistema, ¿de acuerdo?, así que simplemente llamó a strace y luego pudo ver, OK, estas son las llamadas abiertas que hace este programa específico. Y luego creo este archivo porque intentará leer este archivo específico y luego puedo hackearlo. OK, hemos abordado esto, como dije, y he creado una prueba que aborda este problema. Entonces, si quieres ver el PR 46150, podrás ver cómo lo resolví.

Entonces, OK, una vez que Node.js lo carga, el atacante obtendrá acceso a ese openSSL con una configuración personalizada. Entonces el atacante ahora lo controla. OK, eso es malo. OK, es muy difícil de explicar, pero eso es malo.

El último, la validación de certificación. Personalmente, cometí este error y lo solucioné, pero fue difícil. Supongamos que haces una solicitud normal. Realizas una solicitud GET al servidor y la dirección IP del cliente es xsx porque es tu dirección IP. Pero luego quieres usar un servidor PROC. Es bastante común porque digamos que quieres interceptar una solicitud, normalmente un servidor PROC, un depurador PROC ATP, es bueno para hacer eso. Y luego la dirección IP del cliente es diferente, es la III, la del servidor PROC. Puedes usarlo para proxies de intermediario. Hay otra herramienta llamada HTTP Toolkit Proxy. Puedes interceptar las solicitudes del depurador. Eso es muy útil para los desarrolladores. Este es solo un ejemplo del proxy de intermediario. Y luego supongamos que estás en una entrevista y el entrevistador te pide que implementes un cliente de proxy HTTP, ¿de acuerdo? Y terminas con el siguiente ejemplo.

6. HTTP Proxy Tunneling and Permission Model

Short description:

Realizar solicitudes HTTP a través de un proxy sin cifrado TLS puede exponer tus datos a la interceptación de red. El túnel HTTP PROXY crea un túnel SSL seguro entre el proxy y el servidor, protegiendo tus datos. Utiliza una buena biblioteca de clientes HTTP como Onduchi. Node.js 20 introduce el modelo de permisos experimental, que permite un control detallado sobre el acceso a archivos. Un ejemplo demuestra cómo el modelo de permisos puede evitar el acceso no autorizado a archivos sensibles.

Tengo la solicitud HTTP GET y el nombre de host es básicamente la URL de PROC. Y la solicitud del servidor es el servidor en el que quiero realizar la solicitud bajo el cliente de PROC. Básicamente, en una solicitud de consulta, es así. El localhost es mi servidor de PROC. Sin embargo, no hagas eso. Hice eso para Undici, uno de los patrocinadores de Node.js. Y eso, cómo puedo decirlo, es dramático.

De acuerdo, déjame explicarte el problema. Cuando realizas ese tipo de enfoque, toda la conexión HTTP es, toda la conexión, todo el servidor, todos los datos que deseas enviar al servidor, se enviarán primero al servidor de PROC en otra conexión HTTP sin TLS. Entonces, cuando no hay TLS, significa que cualquier persona en tu red, en tu red local, podrá interceptar la red y leer todo el tráfico sin ningún cifrado, independientemente de si el servidor solicitado es HTTPS o no. Y eso es muy malo, porque en ese caso, por ejemplo, en ese caso de UNDG. Estaba usando el agente PROXY, ¿de acuerdo? Y cada vez que envías una solicitud a XSample.com utilizando la URL del PROXY como un HTTP de localhost, es como una dirección predeterminada para AmandaMiddleProx o HTTP2Kit, si alguien va a tu red y lo intercepta usando Wireshark, por ejemplo, como puedes ver en la línea azul, se muestra mi usuario y mi contraseña en la red, aunque XSample.com sea un servidor con cifrado TLS. Eso es malo. Por eso entra en juego el túnel HTTP PROXY. Básicamente, creas un túnel SSL de PROXY entre el PROXY y el servidor. Entonces, significa que el PROXY no podrá leer tus datos. Solo creará el túnel entre el servidor y el PROXY. Así que ese es el enfoque más seguro.

Sé que la mayoría de ustedes no se encontrarán con algo relacionado porque no creo que los entrevistadores les pidan que lo hagan. Así que asegúrate de utilizar una buena biblioteca de clientes HTTP. Onduchi es seguro ahora. Entonces, ¿qué aprendemos de todo esto? El objetivo eres tú en muchas ocasiones. Y Node.js 20 viene con una característica emocionante llamada modelo de permisos, guion, guion permiso experimental. Solo un ejemplo final. Supongamos que hay un desarrollador humilde tratando de resolver un problema. Va al tutorial, encuentra un paquete solucionador de problemas. El paquete solucionador de problemas se ve así. Estaba intentando leer el etc.passwd que básicamente es el archivo de contraseñas. Pero este desarrollador humilde decide ser cauteloso y utilizar el modelo de permisos experimental para permitir solo lectura en los archivos que desea. Y luego el desarrollador humilde se salva gracias al modelo de permisos, porque intentaba acceder al etc.passwd y se le denegó el acceso porque este permiso no se le otorgó explícitamente al proceso.

7. NearForm and Experimental Feature

Short description:

Esta es una buena característica, por favor úsala. Es experimental, así que puedes esperar algunos errores por ahora. No la uses en producción hasta que se estabilice, considerando que es una característica de seguridad. NearForm es una empresa de servicios profesionales con contribuciones principales a Node.js. Pueden ayudar a que tu negocio crezca bajo la infraestructura de Node.js, cubriendo seguridad, rendimiento y más.

Esta es una buena característica, por favor úsala. Es experimental, así que puedes esperar algunos errores por ahora. No la uses en producción hasta que se estabilice, considerando que es una característica de seguridad. Así que hay muchos otros indicadores como AllowRead, Write, Child Process, Worker y muchas otras cosas.

Y bueno, eso es todo de mi parte. Un poco sobre NearForm. NearForm es una empresa de servicios profesionales. Estamos distribuidos en todo el mundo. Tenemos contribuciones principales a Node.js. Soy miembro del equipo principal de Node.js, pero también tenemos otros dos miembros en el equipo principal de Node.js. Así que definitivamente podemos ayudar a que tu negocio crezca bajo la infraestructura de Node.js. Independientemente, seguridad, rendimiento, muchas cosas que cubrimos.

Y eso es todo de mi parte. Gracias chicos.

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
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Top Content
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
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.

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.