¿Puedes Cambiar el Comportamiento de un Proceso de Node.js en Ejecución desde el Exterior?

Hola a todos y bienvenidos a mi charla titulada ¿Puedes cambiar el comportamiento de un proceso Node.js en ejecución desde el exterior? La cosa es que es una charla muy extraña y habrá muchas cosas que no tienen sentido en ella. Así que por favor, quédense hasta el final. Todo quedará claro en algún momento y escribí esto sobrio, eso es una promesa que hago. Antes de comenzar, unas palabras sobre mí. Soy Vladimir Dutourkem, pueden llamarme Vlad. Soy colaborador de Node.js. He tenido permisos de escritura en el repositorio de Node.js durante más de tres años, pero en mi trabajo diario soy ingeniero de clientes en una startup llamada Screen. Nos dedicamos a la seguridad de aplicaciones. Básicamente, te ofrecemos una forma de asegurar tus servidores de producción sin cambiar tu código. Así que si tienes alguna aplicación web en funcionamiento en Internet, probablemente quieras ver lo que hacemos, y no te preocupes, tenemos un plan gratuito.

Entonces, ¿cuál es el plan de hoy? ¿Cuál es el plan de esta charla? Tomemos un servidor de `Hola, mundo` en Node.js. Requerimos HTTP y respondemos OK a cada solicitud. Hasta aquí todo bien. Pero no tiene registros. Bueno, sí, no tiene registros porque el desarrollador fue demasiado perezoso para agregarlos y el desarrollador en este caso soy yo. Hay una solución fácil para eso. Cambias el código y lo vuelves a implementar. Y eso es lo que haría la gente normal. Así que en la línea tres puedes ver que ahora hay registros que se han agregado al código fuente de la aplicación, lo cual es genial. Pero eso no es lo que haremos hoy. Porque somos un poco locos y tenemos experiencia en cosas, estamos cambiando el comportamiento del proceso en tiempo de ejecución e inyectando un registrador en el proceso Node.js en tiempo de ejecución. ¿Cómo hacerlo de forma remota? Y como soy valiente, comenzaré con una demostración en vivo y luego explicaré lo que sucedió en esta demostración. Abramos WebStorm, aquí tenemos nuestro servidor simple y vamos a iniciarlo. Vamos a la primera terminal, node server.js, y pueden ver que no pasé ninguna bandera al proceso, simplemente se inició. Así que si hago algunas solicitudes, curl HTTP local host 8080 slash, responde con OK y aquí no se registra nada. Ahora hagamos un poco de magia que explicaré más adelante, cqsl1 pid, revisamos los registros, se pasó en modo debug como pueden ver. Eso es lo primero que necesitaré explicar más adelante. Y ahora simplemente ejecutamos otro proceso, otro proceso Node.js llamado inyector, no cambió nada en el registro aquí, pero cuando hago solicitudes en este lado, bueno, tenemos registros en el servidor. Ahora registra cosas. Incluso puedo hacer que registre lo que sea.

Ahora, en la línea cuatro, lo que hacemos es evaluar un script arbitrario en el proceso remoto de Node.js. Bien, repasemos eso. Llamamos a un método llamado runtime.evaluate, que nos da la capacidad de ejecutar código JS arbitrario de forma remota. Pasamos un primer argumento que es una expresión. La expresión contiene código JavaScript que se ejecutará. En nuestro caso, ejecutamos lo que está en la línea cinco, require HTTP.server.prototype. Así que queremos que esta instrucción devuelva el prototipo de la clase HTTP.server. Pasamos un parámetro importante en la línea seis, que es include command line API. Eso le dice al depurador que queremos tener acceso a todo lo que es accesible en el nivel REPL. De lo contrario, el método require no estará disponible porque está disponible en Node.js en ciertos ámbitos. Así que es por eso que realmente, realmente, realmente necesitamos este argumento

Así de fácil es. Les mostraré esta función en la próxima diapositiva. En la línea 7, llamamos a la función de método. Este método es realmente poderoso. Primero, le pasas un ID de objeto, un puntero como parámetro, y llamará a la función declarada en la declaración de función con el valor de 'this' vinculado al ID de objeto, el objeto apuntado por el ID de objeto. Básicamente, dado que la instancia de servidor contiene un puntero a una instancia de HTTP.server, la función declarada en la línea nueve es llamada con 'this' siendo el valor del servidor.

De acuerdo, hasta ahora básicamente solo estamos llamando a un método en la instancia de HTTP server. Entonces, ¿qué es este método? ¿Qué se inyecta? Bueno, es solo una pequeña función que hace lo siguiente. Toma un emisor de eventos como parámetro, por lo que se espera que sea un emisor de eventos. Obtiene todos los escuchadores para el evento de solicitud, que es el evento disparado por HTTP.server cada vez que hay una nueva solicitud HTTP en Node. Luego, en la línea cinco, los elimina a todos. Por lo tanto, ya no hay escuchadores en el servidor HTTP en este punto. Y para todos ellos, los reemplaza por la función definida en la línea 11. Entonces, la función en la línea 11 toma los parámetros de solicitud y respuesta, registra request.method, request.URL, y luego llama al método original. Esos son todos los escuchadores que se eliminaron anteriormente. Entonces, lo que hacemos es tomar todos los escuchadores y uno por uno, los envolvemos con esta función que registra el método y la URL. Luego, en la línea 16, volvemos a colocar este escuchador en el mismo orden en que estaban en el emisor de eventos. Entonces, simplemente reemplazamos todos los escuchadores del evento de solicitud por una función que llama al escuchador original pero registra lo que está sucediendo. De acuerdo. Y así es como funciona. Así es como funcionó la demostración que hice. Luego hicimos un poco de limpieza. También hicimos para liberar los punteros al objeto. No lo puse en este código pero lo hicimos, hay métodos para eso. Pero también podemos simplemente deshabilitar todo rápidamente. Entonces, lo primero que hacemos es limpiar el método que agregamos en process haciendo delete process of batch listeners. Luego evaluamos require inspector.close que deshabilitará el depurador en el proceso. Y cerramos nuestra sesión con el depurador. Y eso es todo. Lo logramos, así es como inyectamos logs dinámicamente.

Y eso es genial. Bueno, eso es genial porque lo digo yo. Porque lo hice y no soy muy modesto. Entonces, ¿qué aprendimos hoy? Puedes habilitar el depurador de forma remota para Node.js. Eso es realmente útil. Si quieres aprender más sobre eso, ve al blog de Stream. Escribí un artículo sobre cómo esto es útil para depurar fugas de memoria en producción porque puedes habilitar el depurador en producción. Luego puedes ajustar todos los puertos entre el depurador y tu localhost y comenzar a recopilar volcados de memoria remotos en un proceso de producción en ejecución. Lo mismo ocurre con la CPU, que es el próximo artículo que escribiré en mi blog de Stream.

Entonces, realmente, realmente, es muy útil depurar cosas cuando es difícil cambiar el contenido del proceso pero aún tienes acceso SSH a donde se encuentra el proceso. Con el protocolo DevTool, puedes hacer lo que quieras. No necesitas limitarte a las herramientas de depuración. Puedes utilizar los protocolos DevTool para cambiar prácticamente todo dentro de un proceso de Node.js.

Esto, por supuesto, requiere acceso local a la máquina en la que se ejecuta el proceso. Por lo tanto, no agrega ninguna amenaza de seguridad porque ya tienes acceso administrativo a la máquina en la que se ejecuta el proceso. Y a veces las herramientas que necesitas no están expuestas en las herramientas principales, en la interfaz de Chrome o en tu IDE o en VS Code. Pero puedes construir las tuyas propias. Si necesitas un perfil de CPU muy preciso, puedes construir el tuyo propio. Si necesitas hacer algo especial, como lo hice en esta charla, puedes construir el tuyo propio. No fue una charla sobre inyección de código. Fue una charla para mostrarte lo increíbles y poderosas que son las herramientas de desarrollo y animarte a usarlas.

Muchas gracias por su atención. Han sido un público increíble. Compartiré las diapositivas en Twitter hoy. Probablemente la forma más fácil de mantenerse en contacto y obtener las diapositivas es seguirme en Twitter, en Paul Defeats. Y obviamente pueden contactarme directamente a través de mi dirección de correo electrónico profesional, vladatscreen.com. Una vez más, si tienen una aplicación en ejecución, y quieren verificar lo que hacemos, les brindaremos visibilidad sobre lo que sucede en el proceso y bloquearemos a los actores maliciosos por ustedes. Es una tecnología realmente emocionante. Muchas gracias y que tengan un excelente día.

Hola. Hola, hola. ¿Cómo estás hoy, Vladimir? Estoy bien. Fue intenso, pero ahora estoy emocionado por la sesión de preguntas y respuestas. Sí, hay muchas cosas sucediendo. Y de hecho, tenemos muchas personas interactuando en el chat, haciendo preguntas. Vi una buena pregunta de la conco. Preguntaron si hay una forma fácil de bloquear el modo de depuración en producción para prevenir ataques. No que yo sepa. En realidad, para utilizar lo que he descrito como un ataque, necesitas lo que se llama acceso local adyacente. Por lo tanto, necesitarás tener acceso a la máquina local para enviar la señal. En primer lugar, quieres evitar que las personas obtengan acceso SSH a tu máquina de producción. Y si ya tienen acceso SSH a tu producción máquina, pueden hacer cosas mucho más grandes que lo descrito en esta charla. Así que diría que lo primero que debes hacer es tener un buen firewall y asegurarte de que nadie tenga acceso a tus máquinas de producción. Los métodos mostrados aquí no están disponibles de forma remota porque la primera parte del método es enviar una señal del sistema local desde otro proceso al proceso de Node.

Interesante, interesante. Y Vlad, alguien más preguntó, ¿este método ya se utiliza para instrumentar aplicaciones en producción? Esa es una gran pregunta. Soy consciente de una empresa que hace depuración remota y en realidad su característica es que te brindan un depurador remoto a través de Internet en tu aplicación de producción. Además, este método también se utiliza si sigues los blogs de screen, como una publicación de blog donde explico cómo usar parte de este método para depurar fugas de memoria en producción en Heroku. Y sé que algunos proyectos han estado utilizando este método para hacer eso porque me enviaron mensajes para hacer seguimiento de eso. En cuanto a la instrumentación real en producción, bueno, fuera de la experiencia del desarrollador, no quieres que sea remota. Y hasta donde sé, ningún actor actualmente en el mercado utiliza el Protocolo de Depuración de Chrome para instrumentar aplicaciones. Esto podría cambiar en un futuro cercano porque todavía estoy explorando eso en profundidad porque esta charla es como experimentos de vanguardia.

Y hasta donde sé, nadie ha sido capacitado para seguir en esa dirección antes. Así que todavía estoy trabajando en eso y tal vez en seis meses. Sí. Estaremos atentos a eso. Suena realmente emocionante.

En el chat de Discord, Dan G pregunta, en primer lugar, dice que fue una gran charla y aplausos. Pregunta, ¿podemos ejecutar esto nosotros mismos? ¿Hay un artículo de blog que podamos seguir paso a paso en nuestro propio tiempo? Esa es una gran pregunta. Y en realidad, si vas a ScreenBlog, publiqué exactamente el mismo contenido que la charla de la conferencia en el blog hace un mes. Así que sí, solo ve a ScreenBlog y revisa el último artículo de Node.js. Tiene el mismo contenido a nivel global. Y acabo de compartir el repositorio de este en el canal de preguntas y respuestas en Discord.

Sí, genial. Sí, vi a algunas personas preguntando por el repositorio. Seguro que obtendrás algunas estrellas ahora mismo. Vladimir, también hay una pregunta, ¿esto tiene un impacto en el rendimiento? Esa es una buena pregunta. Y la respuesta es que no debería porque te conectas al proceso. Vas, parcheas lo que necesitas parchear en él. Y luego te alejas, te desconectas y dejas que la VM de JavaScript haga su trabajo. Y no estoy 100% seguro de que el estado del proceso no se vea afectado por haber sido depurado. Y eso es básicamente lo que quiero investigar en un futuro cercano para ver si es un método aceptable de instrumentación porque tal vez sea una solución para solucionar el problema relacionado con la instrumentación de Node.js cuando se utiliza el cargador ESM, cuando se utilizan importaciones ESM porque en este momento la interfaz del cargador puede que no sea la mejor manera exacta de hacerlo, por eso estoy explorando eso. Pero necesito calcular el impacto en el rendimiento y aún no tengo números. Así que si tienes un poco de tiempo para investigar eso, compártelo conmigo. Estaré encantado de tener tus números. En términos de rendimiento, la colaboración de la comunidad es la mejor manera de obtener mediciones precisas.

Eso es genial. Me encanta eso. Como colaborar con la ayuda de la comunidad, pero sabes, Vladimir hace el primer paso y todos ustedes se unen. También tenemos una pregunta. ZeroCool preguntó, esto fue gracioso porque lo preguntaron y luego creo que ellos mismos respondieron pero tengo curiosidad por ver qué dirás. ZeroCool pregunta, ¿esto tiene alguna implicación de seguridad? Y luego dijeron, supongo que no realmente porque para inyectar algo en mi proceso de Node alguien primero tendría que obtener acceso a mi servidor lo cual quiero evitar de todos modos, ¿verdad? Exactamente.

Esa es la belleza de este método: si alguien puede usarlo con fines maliciosos, significa que ya tienen suficiente acceso y de todos modos han violado gravemente la seguridad. Es como una cereza en un gran pastel de piratería, pero sigue siendo solo la cereza. Me encanta, me encanta.

¿Hay algo más que creas que no sé o que creas que ayudaría a las personas si van a comenzar a explorar esto por su cuenta? Sí, vi que las personas compartieron en Discord mi versión modificada de la interfaz de depuración remota de Chrome. En realidad, es un módulo muy bueno para comenzar a explorar la depuración remota de Node.js o de Chrome en general. Eso es prácticamente cómo funciona Pupyter en el fondo. Y en realidad estoy bastante seguro de que el 90% de las personas no lo necesitará. Y ese es mi principal punto de evangelización en cuanto a las técnicas de depuración: cuando las expongo, espero que nunca las necesites. Así que cuando di una charla el año pasado sobre cómo depurar fugas de memoria de forma remota, solo espero que nunca necesites saberlo. Y este es el siguiente nivel. Es cómo depurar cosas cuando las herramientas de depuración proporcionadas por Chrome no te brindan lo que necesitas y tienes que entender el protocolo. Y al igual que es importante que sepas que existe. Es importante que si quieres hackear con eso, lo hagas. Pero en la vida diaria de un desarrollador web habitual, esperemos que no tengas que hacer eso. Pero cuando tienes problemas importantes, es importante tener el primer punto de dirección y saber que es posible porque eso te ahorrará mucho tiempo. Te ahorrará la primera semana completa tratando de entender si lo que quieres hacer es factible. Sí, las herramientas requieren que te superes. Pero al menos tienes el primer indicador de hacia dónde ir. Y eso es prácticamente a donde voy con esta serie de charlas.

De acuerdo, de acuerdo. Sí, es una de esas cosas que esperas no tener que saber, pero siempre es bueno tenerlo en tu repertorio. Exactamente, así que trabajaré en el perfilado de la CPU después de eso en términos de una charla. Y una vez más, es algo que necesitas saber de alguna manera para hacerlo, pero esperemos que no necesites profundizar en eso. Cierto, cierto. Oye Vlad, antes de que te vayas, ¿qué opinas de los resultados de Slido? ¿Fue, qué fue? El 41% de las personas utilizan registros para saber si su seguridad fue atacada. Eso es interesante. No lo esperaba. Esperaba que el 80% de las personas dijera que usa registros, o tal vez el 20%. Esperaba un cambio importante. Así que creo que lo que muestra es que más de la mitad de las personas, el 60% de las personas, el 50% porque eliminé el 9% de `Tengo una herramienta de seguridad` no tienen idea de si su servidor ha sido atacado.

Así que tal vez necesites echar un vistazo a diferentes soluciones para proteger aplicaciones y monitorear aplicaciones en producción. Claro, claro. Tal vez necesiten volver a ver tu charla. Fue increíble. Fue increíble. Lo siento por eso Vlad, estaba escuchando las voces en mi oído. Yo también las tengo, no te preocupes.

Parece que se nos acabó el tiempo, pero estamos muy, muy, muy contentos de tenerte aquí. Y fue una charla increíble. Muchas gracias por todo tu tiempo. Muchas gracias por invitarme. Muchas gracias por invitarme.