Contaminación de Prototipos en JavaScript

Muchas gracias. Hablaremos sobre la producción de prototipos en JavaScript, pero antes de hacerlo, hablemos sobre algo muy importante, yo. Así que la biografía está un poco desactualizada y eso es culpa mía. Ya no trabajo en Datadog, desde hace dos semanas. Y estoy trabajando en una empresa llamada QueryTails, que ni siquiera es una empresa que necesite decirle al abogado que la incorpore. Y ni siquiera es una asociación porque básicamente soy yo mismo. Así que si quieres sentirte triste por mí, debes saber que me siento tan solo que hago mis reuniones de seguimiento con Chad GPT por la mañana. Y hablando del logotipo de las empresas, eso también lo diseñó otra IA. Así que básicamente soy yo estando desempleado en Twitter, dinero del desempleo francés, intentando

Entonces, la cadena de prototipos, básicamente, es un árbol. En el lado izquierdo, he definido un prototipo en mi proto. Lo uso para crear objetos. He definido una clase con un constructor, una clase de estilo antiguo. Le doy un prototipo directamente e incluso defino una clase con la palabra clave class. Básicamente, cuando creo objetos en el lado derecho con estos, compartirán o no compartirán prototipos. Bien, vamos un poco más profundo. El ítem tres tiene un prototipo, mi proto, porque en la línea ocho del código del lado derecho, establecemos objects.setPrototypeof en este objeto. Así que tenemos un método para poner arbitrariamente un prototipo en un objeto, pero el ítem uno y el ítem dos tienen el prototipo de la clase uno, porque los creamos con new y llamamos al constructor de la clase en la parte inferior del lado izquierdo. Pero como esta clase extiende la clase de estilo antiguo, bueno, el prototipo de la clase de estilo antiguo definido en las líneas ocho a trece del lado izquierdo todavía está en la cadena. Así que si quiero verificar el método bar en el ítem uno o el ítem dos, no estará disponible en cl.prototype pero sí estará disponible en old style class.prototype. ¿Está claro? Espero que sí. Por favor, no me arrojen cosas. Gracias.

Entonces, ¿cómo accedemos al prototipo de un objeto? Sí. Pero las personas que me dicen que está claro, saben todo sobre prototipos. Entonces, ¿cómo accedemos al prototipo de un objeto? Tenemos múltiples formas. Así que vamos a tener una clase llamada mi clase porque soy muy original en la forma en que nombro mis clases y crear dos elementos, mi elemento y mi elemento dos. Si verificamos si show prop, que es un método de la clase, está disponible en este objeto, no lo están, porque has on property en la línea 13 nos dice que no está disponible en el objeto directamente. Pero si hacemos object get prototype of my item, esto devolverá el prototipo de la clase. Y esto tiene la propiedad propia show prop, eso es lo que estamos en la línea 14. También podemos acceder a un prototipo con guión bajo, guión bajo, proto guión bajo, guión bajo. Así que si hacemos my item, guión bajo, guión bajo, proto, guión bajo, guión bajo, eso tiene la propiedad show prop, devolverá true. Y si hacemos console.log my item.constructor.prototype tiene la propiedad show prop, también devolverá true. Y lo que vale la pena destacar es que hay una única instancia de este prototipo en el montón de memoria, lo que significa que my item punto guión bajo, guión bajo proto guión bajo, guión bajo, es exactamente lo mismo que my item two guión bajo, guión bajo, proto, guión bajo, guión bajo. Bastante seguro de que nadie ha dicho prototipos tantas veces en su vida en un corto período de tiempo.

Entonces, esta es la función de fusión que hemos visto en la línea cinco en la diapositiva anterior. Y esta función realiza una fusión recursiva, lo que significa que si quieres fusionar dos objetos, y tienen propiedades que pueden ser comunes en sus subobjetos, los verificará recursivamente. Pero debido a que __proto__ es una propiedad accesible en la mayoría de los objetos, la función dirá, Oh, tengo algo en proto para escribir en este objeto y este objeto tiene proto. Entonces tomará el valor del prototipo del objeto y comenzará a escribir cosas en eso. Entonces, lo que quiero decir es que a través de la función de fusión, debido a esta llamada recursiva en la línea 18, subimos por la cadena de prototipos y escribimos, oops. Y eso también funcionó en lodash, porque quiero asustar a todos. Quiero decir, en versiones antiguas de lodash, tienes otro constructor de carga, prototipo, isAdmin. Recuerdas que mostré que podemos acceder al prototipo de una función de un objeto yendo a través de constructor.prototype. Bueno, hacemos exactamente lo mismo. Tenemos un objeto B, B.isAdmin es undefined. Usamos lodash.merge en un objeto que no tiene nada que ver con B y la carga como segundo argumento. Y luego B.isAdmin es true. Y, oh, lo siento. Y lodash es increíblemente popular, esta diapositiva no es para el código de JavaScript, es para el código de seguridad. Todos saben que lodash es increíblemente popular y genial.

Entonces, ¿cuál es el impacto de la contaminación de prototipos? Porque suena como una buena manera de meterse con el código de alguien, pero ¿puede ser malicioso? Desde 2018, ha habido más de 200 CVE, CVE significa vulnerabilidades públicas reveladas para que todos las conozcan y no todas las vulnerabilidades reciben un CVE. Así que eso probablemente es la punta del iceberg. Ha habido algunas ejecuciones de código remoto en Kibana y el servidor PaaS, y no, ya no trabajo en Datadog, así que puedo decir lo que pienso sobre Kibana sin preocuparme tanto.

Así que espero algunas diapositivas sobre eso y la Universidad KTH publicó un artículo muy interesante sobre este tema el verano pasado. El caso de Kibana CVE-2019-7609, básicamente es muy, muy divertido. Me encanta. Kibana utiliza procesos secundarios de Node.js para ciertas cosas. Por ejemplo, si quieres hacer algún cálculo en Kibana, generará un proceso secundario. Y cuando generas un proceso secundario desde Node.js, compartirá el entorno del proceso principal con el proceso secundario a través de un objeto JavaScript. ¿Ves hacia dónde va esto? Hay una variable de entorno en Node.js llamada Node.option que puedes usar para pasar argumentos de línea de comandos al binario de Node. En lugar de hacer Node --algo, puedes hacer Node.option, poner tu --algo en él, y cuando inicies Node, lo capturará. También está la opción -e o --evil en la línea de comandos de Node que te permite ejecutar código pasado como una cadena en la línea de comandos. El ejemplo aquí es Node -e console.log('hello') que realmente inicia un proceso de Node y ejecuta console.log('hello'). Vamos a contaminar este prototipo. Bueno, ¿por qué tengo, ah sí, me falta algo. Está bien. Me falta una diapositiva. Lo siento por eso. Básicamente hubo una contaminación de prototipos en Kibana y podías escribir Node.option en la cadena de prototipos. Sabes, contaminarías el prototipo y cada objeto JavaScript en este montón. Cuando verificas si Node.option está definido, responderá con, oh sí, hay una ejecución de grabación de ejecución maliciosa con la cadena. Y eso es básicamente lo que le sucedió a Kibana. Así que si tenías acceso a un servidor de Kibana a una interfaz de usuario de Kibana, podías ejecutar código arbitrario en el servidor y luego generar otro proceso con tus argumentos compartidos en todo lo que quisieras. Así que lo arreglamos. La opción -e ya no está permitida en Node.option, pero hay un bypass y es público, pero no hablaré de eso. Y Kibana ha solucionado la contaminación de prototipos. El artículo original es muy interesante, muy accesible y también hay una charla, seguramente sobre ese tema, muy, muy interesante de ver.

Parse server. ¿Quién está familiarizado con Parse aquí? Fue muy, muy popular hace un tiempo. Básicamente es un proyecto backend para aplicaciones móviles que expone una API frente a un servidor MongoDB, siendo adquirido por Facebook, cerrado por Facebook, y ahora solo hay una versión de código abierto que solo a Google se le ocurre cerrar productos que la gente ama. Y básicamente es una API frente a MongoDB. Puedes almacenar objetos.

Puedes solicitar un objeto de MongoDB a través de una API. Antes de ser corregido, era vulnerable a la contaminación de prototipos, por supuesto. Y utiliza una biblioteca llamada bsonjs. Entonces, bson es un formato para almacenar objetos en MongoDB. Significa JSON binario o algo así. Pero, bson te permite almacenar funciones que se almacenarán en MongoDB y se pueden deserializar. Pero de forma predeterminada, no se deserializan. Porque deserializar una función que proviene de una base de datos básicamente significa, hagamos eval en esa cadena que proviene de la base de datos de la que no tengo idea, y no quieres eso como predeterminado. Pero si la opción eval function en el objeto utilizado como opción para la biblioteca bson es verdadera, bueno, evaluarás esas funciones arbitrarias. Y como Parse te permite escribir prácticamente cualquier cosa que desees en tu base de datos desde la red, porque es Parse, en realidad podrías ejecutar código arbitrario cuando se recupera el objeto, lo cual es, oh dios mío, eso se debe a que verifican el hack de desviación.

Cómo prevenir la contaminación de prototipos porque soy una persona responsable, no quiero que te sientas asustado y digas , sabes, usemos un lenguaje sin prototipos como Python. ¿Cómo prevenir? Bueno, filtremos, ya sabes, las funciones de fusión. Verás, por ejemplo, en la línea nueve aquí, línea nueve, nueve, tres, o en la línea cuatro aquí, que filtramos, underscore, underscore, proto, underscore, underscore. Y eso es lo que hemos estado corrigiendo en muchas bibliotecas. Lodash ha corregido más instancias de contaminación de prototipos que cualquier otra biblioteca que conozco, y todas han sido corregidas una por una. Si encuentras una nueva, siéntete libre de revelarla de manera responsable a su mantenedor, sin importar qué biblioteca sea.

A veces, sabrás que tu camino de código es crítico y quieres asegurarte de que estás usando una propiedad propia. Bueno, bueno, una propiedad propia puede ser manipulada con ataques de terceros, pero eso es algo diferente. Así que asegúrate de que si esperas que una propiedad exista en un objeto, te asegures de que exista en el objeto y no en su cadena de prototipos. Además, me gusta esto. Es lo que llamo construir un objeto defensivo. No sé si ese es el término académico, pero puedes usar Object.create y eso creará un nuevo objeto con sus argumentos como prototipo. Bueno, null es un objeto. Así que puedes hacer Object.createNull. Estos objetos no tendrán todos los métodos que esperas que tengan como propiedad propia, símbolos propios, descriptores de propiedad propia, pero este objeto estará a salvo de la contaminación de prototipos porque no tiene ningún prototipo.

Sanitización, asegúrate de que lo que ingresa a tu proceso desde el exterior sea seguro. Realiza validación de datos. Me encanta la biblioteca joy porque soy un niño feliz y gordo, pero hay muchas bibliotecas increíbles para realizar sanitización de datos. Úsalas. Son muy geniales. Y de todos modos, deberías usarlas si estás construyendo un servidor web con Node.js. Como se mencionó, eso también probablemente reducirá tu superficie de ataque a la inyección de secretos. Así que adelante.

Conclusiones. Oh dios mío, llego a tiempo. ¿Qué sigue? Monitorea los objetos entrantes. Node.js tiene una opción para deshabilitar proto, underscore, underscore, proto, underscore, underscore. Puede romper algún código. Así que ten en cuenta que puede romper algún código debido a Internet, pero puedes usarlo. Y para la sanitización y objetos sin prototipos. Oh, ¿recuerdas por qué te dije que deberías usar Python? Eso fue una broma en enero.

Alguien publicó un artículo. No hay pruebas de uso real en la naturaleza para ataques maliciosos, pero ha habido un artículo sobre la contaminación de clases diciendo que, básicamente, Python también es vulnerable a eso. Así que no hay un lugar seguro.

Algunos enlaces. Las diapositivas estarán en Twitter. Por favor, solicita las diapositivas en Twitter si las deseas. Mantengámonos en contacto. Puedes encontrar mi Twitter con esta URL corta.

Espero que hayas disfrutado esta presentación y que tengas preguntas que pueda responder. Muchas gracias por ser un grupo increíble. Abordaremos esta pregunta en su debido momento. Hubo muchas sugerencias sobre cómo mitigar los riesgos causados por la contaminación de prototipos. Si nuestra audiencia regresara a casa y fuera a sus bases de código en las que están trabajando actualmente y con las preocupaciones que pueden tener ahora, ¿cuál sería lo primero que les animarías a hacer? Tal vez sea una acción simple y fácil o comenzar un trabajo más significativo.

Esa es una muy buena pregunta. Creo que lo primero que debes hacer después de asistir a una conferencia sobre seguridad en Node en general, cuando regreses, es verificar de dónde provienen tus objetos, y eso es cierto para mitigar la contaminación de prototipos, pero también para todas las inyecciones en general. Cuando digo eso, me refiero a que en algún momento, si tienes una aplicación web, es posible que acepte objetos desde el exterior. Pueden ser las cadenas de consulta, pueden ser el cuerpo. En algún momento, hay una biblioteca en tu base de código que pasará una solicitud HTTP de texto y devolverá un objeto de JavaScript. Esa es probablemente la principal fuente de entradas maliciosas. Porque tu aplicación puede ser vulnerable a ataques de terceros desde tus módulos de NPM o desde las entradas que provienen de la red. Y a mí me gusta pensar en las cosas que provienen de la red, hablar con ZB Si estás interesado en el otro modelo de amenaza, la parte del modelo de amenaza. Así que verifica el objeto que ingresa a tu aplicación y verifica qué estás haciendo con ellos. ¿Los estás sanitizando? ¿Conoces su estructura? ¿Hay un error en tu código cuando no se parecen a lo que esperas? Eso significa métodos que, propiedades que esperas del objeto, pero también, ¿estás seguro de que el objeto no tiene propiedades que no esperas? Por lo tanto, los objetos que ingresan a tu aplicación deben tener una apariencia conocida. Y eso será la primera forma de saber que nadie está inyectando algún tipo de guion bajo, guion bajo, proto o elementos de constructor en tus objetos. Genial.

Muchas gracias. Entonces, algunas preguntas de la audiencia, ¿hay alguna forma fácil, creo que mencionaste esto, pero haré la pregunta explícitamente de todos modos. ¿Hay alguna forma fácil de verificar si mi servicio es vulnerable a este ataque, alguien que usa muchos módulos de terceros de NPM? Sneak Audit, NPM Audit, ya conocerás los métodos vulnerables, si se conocen. Verifica si estás utilizando métodos de fusión en tu propio código, pero sí, básicamente asegurarte de que no tienes vulnerabilidades conocidas en tu base de código es el primer paso. Idealmente, los marcos de trabajo deberían poder manejar este tipo de cosas por nosotros.

¿Existen equivalentes a Express o Fastify que prevengan la contaminación de prototipos? Hasta donde sé ahora, no estoy al tanto de la documentación de Fastify o la documentación de Express, estoy al tanto porque no ha cambiado en cinco o seis años, pero no creo que existan. Ese es un buen punto, supongo que Matteo dirá que se aceptan solicitudes de extracción, así que siéntete libre de hacer una solicitud de extracción para Fastify.

La siguiente pregunta es algo que mencionaste en tu charla, pero ha recibido varios pulgares arriba. Así que quiero hacerla de todos modos. ¿Qué es el argumento "-e" en las opciones de nodo? Bueno, "-e" es una abreviatura de "-eval" y básicamente te brinda la oportunidad de pasar una cadena como argumento en lugar de un archivo y ejecutar esta cadena como si fuera un archivo JavaScript. Entonces, en lugar de hacer "node index.js", haces "node -e" y colocas una cadena con todo tu código JavaScript y eso lo ejecutará. Genial. Gracias.

¿Object.assign también crea prototipos contaminados? Esa es una buena pregunta. Quiero decir que no, pero no estoy seguro. Esa es tu tarea para esta noche. No creo, pero lo estoy verificando. No pensé que vinieras a ningún congreso por esa tarea. ¿Existen otras formas de hacer RCE con la contaminación de prototipos sin opciones de nodo como en el ejemplo de Cabana? Bueno, hubo el ejemplo de bison con una función que se serializaba. Así que supongo que sí, de alguna manera, eso realmente depende de la aplicación que estés atacando. ¿Esta aplicación tiene evaluación de cadenas en algún momento, ya sea a través de variables de entorno, eval, con VM o transcodificación? En ese caso, sí, pero depende mucho de la lógica empresarial. Gracias. Tengo algunas más, ¿quieres seguir adelante? En base a tu charla, ¿deberíamos usar mapas en lugar de objetos para evitar estos problemas? Quiero decir, sí. Sí. Quiero decir, solo asegúrate de que, si eres muy cauteloso al respecto, debes asegurarte de que no haya contaminación intrínseca, lo que significa que alguien anula los métodos basados en mapas, no pueden hacerlo hasta donde sé con la contaminación de prototipos, pero pueden hacerlo con un tercero malintencionado. El código de Node.js es realmente defensivo contra eso, así que puedes verificarlo. Pero sí, los mapas probablemente sean una de las cosas más inteligentes que puedes hacer en tu aplicación web, en lo que a mí respecta, me encantan los mapas. Si has asistido a la charla de James sobre almacenamiento asíncrono, la primera versión que propuse del almacenamiento asíncrono te obligaba a usar un mapa como almacenamiento, como amante de los mapas, diría que sí, pero estoy sesgado. Solo un poco. ¿Y si fusiono un objeto con el operador de propagación nativo en lugar de la antigua versión, una versión antigua de lodash? Creo que estás a salvo de la contaminación de prototipos, pero es como el objeto asignado de datos, nunca lo he intentado, así que no puedo afirmarlo con certeza. Creo que con muchas de estas preguntas, probablemente se trata de probar todas las soluciones y ver cuál es el resultado, ¿verdad? Además, espero que si estas formas fueran vulnerables a la contaminación de prototipos, lo sabríamos ampliamente como comunidad, por eso tiendo a pensar que estamos seguros, pero como persona de seguridad, no quiero asumir las cosas. Y tampoco quieres asumir. ¿Existen o podrían existir reglas de ES lint que detecten estos problemas? Buena pregunta. Podría haber una necesidad. Es difícil porque requiere un poco de seguimiento de contaminación.

Podría haber al menos una regla de semgrep que verifique que estás fusionando objetos basados en objetos entrantes. Entonces, semgrep, para aquellos que no están familiarizados, es una herramienta de análisis estático de código. Es de código abierto. Está escrito en Okeanos, construido en la costa oeste, es realmente genial y está diseñado para encontrar vulnerabilidades. Pero es un poco inteligente. Es más poderoso que la mayoría de las herramientas de linting porque tiene algún tipo de motor de ejecución simbólica y puede ejecutar parte de tu código en una máquina virtual, es decir, ejecuta parte de tu código y decide si es vulnerable. No estoy seguro acerca del linter, pero estoy bastante seguro acerca de semgrep. Genial. Asombroso. La última pregunta que tenemos en esta lista. ¿Qué pasa si fusionamos constructor.prototype en lugar de usar underscore proto underscore? ¿Pasaría a través del filtro underscore underscore proto underscore underscore y funcionaría? ¿Puedes repetir eso? No estoy seguro. ¿Qué pasa si fusionamos constructor.prototype en lugar de usar underscore proto? Depende de la vulnerabilidad. Si entiendo correctamente la pregunta, así es como se ha solucionado en lodash. Depende de cómo funcionan realmente estas funciones de fusión y queremos poder fusionar prototipos para construir mixins de todos modos, así que no queremos evitar eso por completo. Sí, genial. Muchas gracias. Gracias a todos, wow, pasamos de solo hacer algunas preguntas a una enorme lista de preguntas y eso es increíble. En nombre de toda nuestra audiencia, gracias nuevamente por una charla realmente provocadora y táctica sobre cómo mitigar los riesgos en la contaminación de prototipos. Así que muchas gracias por tenerme y gracias por ser una audiencia increíble. Hagamos un gran aplauso grupal. ¡Un diez!