1. Introducción a cambiar el comportamiento de un proceso Node.js
Hola a todos y bienvenidos a mi charla titulada ¿Puedes cambiar el comportamiento de un proceso Node.js en ejecución desde el exterior? Hoy exploraremos cómo cambiar remotamente el comportamiento de un proceso Node.js en tiempo de ejecución e inyectar un registrador. Comenzaré con una demostración en vivo para mostrar el proceso. Abramos WebStorm y comencemos nuestro servidor simple. Al ejecutar otro proceso Node.js llamado inyector, podemos ver registros en el servidor e incluso personalizar el registro.
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.
2. Cambiando el estado del proceso y depuración remota
Ahora registra la URL de la solicitud que hacemos. Y eso funcionaría para cualquier URL porque lo que hemos inyectado es en realidad console.log, rec.method, rec.url. Tenemos este proceso en ejecución. Es un servidor simple de hola mundo, como dije, y simplemente responde con 'ok'. Cambiamos su estado al modo de depuración usando la señal del sistema sigusr1, lo que habilita el depurador en el proceso. Iniciamos el depurador de forma remota, lo cual es realmente muy útil. Aprendamos a usar herramientas de nivel inferior y realizar la magia del código JavaScript. ¿Has oído hablar del protocolo de herramientas de desarrollo? Es lo que se utiliza tanto en los depuradores de Node.js como en los depuradores de Chrome, ya sean remotos o locales.
Quiero porque decidí registrar la URL. Ahora registra la URL de la solicitud que hacemos. Y eso funcionaría para cualquier URL porque lo que hemos inyectado es en realidad console.log, rec.method, rec.url. Bueno, ahora supongo que la pregunta legítima es ¿cómo sucede eso? ¿Cómo funcionó eso? Y eso es lo que pasaremos los próximos 15 minutos revisando juntos. Así que tenemos este proceso en ejecución. Es un servidor simple de hola mundo, como dije, y simplemente responde con 'ok'. Entonces, lo primero que tenemos que hacer es cambiar su estado al modo
debug, para que podamos conectarnos con un depurador. Hay esta cosa genial en
Node.js que si envías la señal del sistema sigusr1, habilita el depurador en el proceso. Y luego puedes conectarte a él a través de un depurador en un circuito web. Así que el único cambio que hago en el código ahora es hacer que registre el PID del proceso. Eso no es necesario. Podríamos usar el comando PS o el comando top para encontrarlo, pero en este caso, soy un poco vago. Quiero decir, ya era demasiado vago para escribir registros, así que también soy demasiado vago para encontrar el PID de un proceso en ejecución, así que simplemente lo registramos. Luego, cuando hacemos el kill-usr1 y el PID, cambia el estado del proceso. Entonces, el comando kill en sistemas Unix no solo se utiliza para matar procesos, sino que también se puede utilizar para enviar señales de mensaje. En nuestro caso, enviamos la señal sigusr1 y pasamos el PID del proceso objetivo como último argumento. Eso es lo que sucedió cuando comenzamos a registrar el proceso en ejecución y cuando hicimos este comando en otra
terminal, registramos DebuggerListName en el websocket y luego la URL. Esto también se puede hacer programáticamente desde otro proceso de
Node.js utilizando, como te imaginarás, process.kill. Process.kill tiene una sintaxis donde acepta una señal y un PID y envía una señal a otro proceso. Así que, ta-da, en realidad iniciamos el depurador de forma remota, lo cual es realmente muy útil, pero lo explicaré más adelante. Así que, si vamos a chrome __inspect, en realidad vemos que el objetivo está disponible para ser depurado. Esa es la forma en que puedes verificar cuántas pestañas de
nodejs y chrome están disponibles para
debug local o remotamente yendo a chrome //inspect en chromium o chrome. Bien. Así que no vamos a usar eso. Podríamos ser personas normales y usar la herramienta de desarrollo de Chrome y solo jugar con cosas de
JavaScript. Por ejemplo, podríamos parchear el método en el emisor de eventos para identificar un emisor de eventos que envía el evento de solicitud y, en función de eso, parchearíamos este emisor porque identificamos una instancia de HTTP dot server y eso es totalmente factible con la consola de
JavaScript de las herramientas de desarrollo. Pero no hagamos eso. En realidad, aprendamos a usar herramientas de nivel inferior y realizar esa magia del código
JavaScript. Entonces, ¿has oído hablar del protocolo de herramientas de desarrollo? En realidad, es lo que se utiliza tanto en los depuradores de
Node.js como en los depuradores de Chrome, ya sean remotos o locales. Por ejemplo, cuando depuras Chrome en un teléfono Android, ese es el protocolo que utilizas. Cuando usas un Pupator
3. Usando el Protocolo de Chrome DevTool
Cuando se utilizan herramientas de depuración para Node.js, el protocolo subyacente es el Protocolo de Chrome DevTool. Este protocolo está bien documentado y se puede encontrar en chromedevtools.github.io. Ejecutaremos un script que utiliza el módulo de interfaz remota de Chrome para interactuar con el Protocolo de Chrome DevTool. Habilitamos el dominio de tiempo de ejecución y evaluamos un script arbitrario en el proceso remoto de Node.js utilizando el método runtime.evaluate.
Para tener un control de Chrome sin cabeza, ese es el protocolo que se utiliza. Y, por supuesto, cuando se utilizan herramientas de depuración para
Node.js, ese es el protocolo que se utiliza en el fondo. En realidad, está bastante bien documentado y puedes encontrar la documentación en chromedevtools.github.io. Es una lectura interesante, porque te enseña cómo funcionan las cosas en el fondo, pero ese es en realidad el objetivo de esta charla. Así que, usemos eso, porque suena increíble, y en realidad lo es. Así que, simplemente ejecutaremos este script y estoy bastante seguro de que en los pocos segundos que lo mostré, todos ustedes pueden saber qué hace. Eso fue una broma, esta imagen es demasiado pequeña. Volvamos a ella rápidamente. En la línea dos, requiero un módulo llamado chrome remote interface, que es en realidad el módulo que utilizaremos para interactuar con el Protocolo de Chrome DevTool. Pero una vez más, esta es una imagen demasiado pequeña para que la leamos. Ampliemos. En esta diapositiva, comenzamos en la línea uno utilizando el Protocolo de Chrome DevTool y conectamos un cliente al puerto 9229. Ese es el puerto predeterminado para la depuración de
Node.js y es donde, por defecto, se iniciará el proceso. Eso se puede configurar en el lado de
Node.js, pero en este caso, vamos con eso. En la línea tres, hacemos algo realmente importante. Habilitamos el dominio de tiempo de ejecución. Así que en el Protocolo de Chrome DevTool, hay varios dominios. Hay un dominio llamado tiempo de ejecución, hay un dominio llamado depurador, hay un dominio llamado CPU, hay un dominio llamado memoria y estoy seguro de que puedes adivinar qué hacen por su nombre. Antes de usar el método de un dominio, debes habilitarlo para decirle al motor V8 que vas a usar métodos de este dominio. Así que comenzamos haciendo eso.
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
4. Recuperando IDs de objetos y evaluando scripts
El proceso remoto de Node.js devuelve un ID de objeto, que es una dirección de memoria para el prototipo de la clase del servidor. Crea una nueva variable que apunta a él y nos proporciona una forma de recuperar esta variable. Al consultar objetos y pasar el resultado, obtenemos un puntero a un array donde cada elemento es una instancia de HTTP.SERVER. Podemos acceder a la única instancia de HTTP.SERVER en este proceso. Evaluamos otro script colocando la función en el módulo y pidiendo a Node que lo cargue en el proceso.
Para ser pasado. Lo que devuelve en realidad no es el objeto prototipo. Es un ID de objeto. Es un puntero. Es una cadena. Esa es una dirección de memoria para el prototipo de la clase del servidor. Lo que significa que sería imposible para este proceso remoto de
Node.js devolvernos un objeto
JavaScript real. Simplemente crea una nueva variable que apunta a él y nos proporciona una forma de recuperar esta variable. En esta charla, lo llamaré un puntero o un ID de objeto. Lo que hacemos en la línea 9 es consultar objetos. Ese es un método que consulta todos los objetos en el montón que tienen el prototipo pasado como parámetro. Así que en la línea 10, tenemos un campo prototyped object ID y pasamos el resultado de la llamada anterior. En la llamada anterior, tenemos un puntero al prototipo de la clase del servidor. En esta llamada, tomamos este puntero, se lo devolvemos a V8 y le decimos que nos dé todos los objetos que tengan esto como prototipo. Y obtenemos un resultado de eso, que en realidad es un puntero a un array, a una lista. Una vez más, tenemos un ID de objeto que apunta a una lista en la que cada elemento es en realidad una instancia de servidor, de HTTP.SERVER.
Así que en la línea 12, lo que hacemos es pedir la lista de propiedades de esta lista. Tendrá propiedades como length, includes, pero también tendrá propiedades llamadas 0, 1, 2, 3 que son en realidad los elementos de esta array, de esta lista. Ahora, porque sabemos que en este código, solo hay una instancia de HTTP.SERVER, sabemos que estará en el primer elemento de la lista en la parte cero. Sin embargo, si agregamos más que eso, podríamos inspeccionar para encontrar el que queremos. Así que ponemos la instancia de SERVIDOR que contiene el ID de objeto de nuestra instancia de HTTPSERVER. Y eso ya es bastante genial. Tenemos acceso a la única instancia de HTTP.SERVER en este proceso.
De acuerdo. Ahora evaluemos otro script. Eso es lo que tenemos en la línea 3. Procesamos los escuchadores de parches es igual a requerir para inyectar los escuchadores de parches de JS. Básicamente, fui demasiado perezoso para escribir toda la función allí. Así que lo puse en el módulo y le pedí a Node que lo cargara. Puse eso en el proceso porque en nuestra próxima llamada no hay forma de acceder a require, pero hay acceso a process porque process está disponible en todas partes en
JavaScript en un proceso de
Node.js. Así que lo que hacemos es simplemente poner una función global que usaremos en nuestra próxima llamada.
5. Inyectando Logs en el Proceso de Node.js
Así de fácil es. Llamamos a la función de método en la línea 7, pasándole un ID de objeto como parámetro. Este método es poderoso ya que llama a la función declarada en la declaración de función con el valor de 'this' vinculado al ID de objeto. La función reemplaza los escuchadores del evento de solicitud con una pequeña función que registra el método y la URL de cada solicitud. Luego volvemos a colocar los escuchadores modificados en el emisor de eventos. Finalmente, limpiamos el método agregado y deshabilitamos el depurador.
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.
6. Depurador Remoto para Node.js
Puedes habilitar el depurador de forma remota para Node.js, lo cual es realmente útil para depurar fugas de memoria en producción. Visita el blog de Stream para obtener más información sobre este tema.
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.
7. El Poder de las Herramientas de Desarrollo
Con el protocolo DevTool, puedes hacer lo que quieras y cambiar prácticamente todo dentro de un proceso de Node.js. Esto requiere acceso local a la máquina en la que se ejecuta el proceso. Puedes construir tus propias herramientas si las existentes no cumplen con tus necesidades. La charla enfatiza el poder de las herramientas de desarrollo y fomenta su uso.
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.
Q&A y Instrumentación en Producción
Gracias por su atención. Síganme en Twitter en Paul Defeats para obtener las diapositivas. Contáctenme en vladatscreen.com. Proporcionamos visibilidad en el proceso y bloqueamos a los actores maliciosos. No hay una forma fácil de bloquear el modo de depuración en producción. El método requiere acceso local a la máquina. La depuración remota es utilizada por algunas empresas y para depurar fugas de memoria en Heroku. El Protocolo de Depuración de Chrome no se utiliza ampliamente para la instrumentación en producción.
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.
Running and Security Implications
Nadie ha sido capacitado para seguir en esa dirección antes. Todavía estoy trabajando en ello y tal vez en seis meses. En el chat de Discord, Dan G pregunta si pueden ejecutar esto ellos mismos y si hay un artículo de blog paso a paso. Publiqué el mismo contenido que la charla de la conferencia en ScreenBlog hace un mes. También está la cuestión del impacto en el rendimiento, que no debería ser significativo ya que te conectas al proceso, lo parcheas y te desconectas. Sin embargo, se necesita investigar más el impacto en el estado del proceso y el rendimiento de la instrumentación de Node.js con el cargador ESM. Se fomenta la medición del rendimiento mediante la colaboración de la comunidad. ZeroCool pregunta sobre las implicaciones de seguridad, pero la inyección requiere acceso al servidor, lo cual debería evitarse.
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.
Debugging Techniques and Slido Results
El método puede ser utilizado con fines maliciosos, pero requiere un acceso significativo e indica una violación importante. Es importante tener conocimiento de técnicas de depuración, incluso si esperas no tener que usarlas nunca. Comprender el protocolo y tener las herramientas para mejorar pueden ahorrar tiempo y proporcionar un punto de partida para resolver problemas importantes. La próxima charla tratará sobre el perfilado de la CPU. Los resultados de Slido fueron inesperados, con solo un 41% de las personas utilizando registros para detectar ataques de seguridad. Esto resalta la importancia de tener conciencia y monitoreo en su lugar.
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.
Closing Remarks and Gratitude
Tal vez necesites echar un vistazo a diferentes soluciones para proteger y monitorear aplicaciones en producción. Se nos acabó el tiempo, pero fue una charla increíble. Gracias por tu tiempo.
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.
Node Congress 2023
Comments