¿Qué es una Vulnerabilidad y Qué No lo Es? Entendiendo los Modelos de Amenazas de Node.js y Express

Hola, soy Ulisses Gascon, y en esta charla vamos a hablar mucho sobre seguridad. Vamos a profundizar en la comprensión de qué es una vulnerabilidad y qué no lo es, mientras usas tus herramientas más queridas como Node.js o Express, ¿verdad?

Así que básicamente, quién soy. Soy ingeniero de software en NodeSource. También soy parte del equipo central de Yeoman, Node.js y Express, y estoy tratando de ayudar mucho en el ecosistema sobre seguridad. Estoy participando en muchos espacios de colaboración y grupos de trabajo, etcétera. Y la idea de hoy es discutir sobre qué es una vulnerabilidad y qué no lo es, y cómo puedes mejorar tu propia seguridad en general.

Entonces, básicamente, ¿qué es una vulnerabilidad? En términos muy simples, y si usamos la Wikipedia, entenderemos que una vulnerabilidad es básicamente un defecto, una mala configuración de seguridad o un punto débil en nuestro sistema. Así que básicamente, son defectos. La cuestión es que estos defectos pueden ser utilizados por terceros para explotar nuestros sistemas, ¿verdad? Y hacer que funcionen de maneras que no anticipamos. Eso es lo que consideramos un problema de seguridad. Y básicamente hoy vamos a descubrir muchos de estos defectos.

Lo primero es como, cuando enfrentamos cualquier tipo de desafío de seguridad, por ejemplo, aquí tenemos dos ejemplos que son en realidad código débil, digamos. Así que en el primer ejemplo, vemos claramente que hay una inyección SQL aquí, ¿verdad? No estamos haciendo ningún tipo de validación en este data.name, básicamente. Así que eso es algo que puede ser malo. Y en el segundo ejemplo, no vemos nada especialmente raro aparte de este gran límite que decimos en uno de los argumentos cuando hicimos la configuración para el body parser. Pero sí, básicamente estamos usando Express, nada súper raro y body parser, ¿verdad? Así que en el primer ejemplo, es muy claro para nosotros que tal vez a quién podemos culpar, básicamente podría ser el desarrollador.

Y en el segundo caso, no es muy claro, ¿verdad? Porque dependiendo de cómo estés manejando esto, tienes dos perspectivas aquí. Así que una es como, si tienes una inyección SQL, es cómo estás usando la herramienta y la estás usando incorrectamente. Así que en este caso, por ejemplo, es culpar al desarrollador, ¿verdad?, por cometer el error de incluir la inyección SQL. Pero en el otro caso, no es tan simple. Es mayormente nuestra vulnerabilidad, ¿verdad? Así que definimos cómo debería funcionar el framework, cómo deberían funcionar las bibliotecas en este caso. Y hay una mala configuración de la decisión que tomamos en el proyecto que hace que este punto débil sea posible de explotar, ¿verdad? Así que obtuvimos un CVE el año pasado y podemos ver claramente que esto puede terminar en una denegación de servicio porque hay algunas opciones para hacer, ya sabes, cargas útiles elaboradas que podrían, ya sabes, sobrecargar el servidor. Así que este es el tipo de escenarios con los que lidiamos.

Vamos a discutir mucho hoy sobre cuáles son las dos principales diferencias entre estos tipos de cosas y cómo podemos entender y esperar qué se considera una vulnerabilidad en los ojos del desarrollador y qué se considera una vulnerabilidad en los ojos de los mantenedores de las bibliotecas o el runtime que te encanta usar, ¿verdad? Así que básicamente, lo más importante hoy, la introducción de esta charla va a ser sobre los modelos de amenazas. Así que básicamente, ¿qué es un modelo de amenazas? Para nosotros, un modelo de amenazas es un documento simple. Quiero decir, el resultado final es un documento, pero principalmente es un enfoque estructurado para entender el riesgo de seguridad, posibles mitigaciones, tratamos de identificar a los atacantes y los actores y qué puede salir mal. Así que básicamente, es un ejercicio que hacemos como parte del proyecto y tratamos de responder a algunas de estas preguntas, ¿verdad? Como qué estamos tratando de proteger, ya sabes, qué puede salir mal? ¿Cuáles son los problemas que podríamos ver alrededor de esto? ¿Cuáles son las amenazas potenciales que estamos viendo aquí? Es algo que puede ser causado por un malentendido, puede ser un bot, puede ser, ya sabes, atacantes, puede ser lo que sea, ¿verdad? ¿Cuáles son los límites? Esa es una pregunta muy importante que deberíamos hacer cuando construimos una biblioteca, cuando construimos un runtime, ¿verdad? Como cuáles son las cosas que consideramos confiables o no confiables para que podamos entender eso. Y también discutimos mucho sobre las mitigaciones, ¿verdad? Qué, qué necesitamos hacer, quiero decir, cómo son los escenarios y qué pueden hacer los usuarios de nuestros propios entornos para mejorar la seguridad, ¿verdad?

Puedes encontrar estos modelos de amenazas, por ejemplo, en el caso de Node.js, dentro del documento security.mt, que es un documento fantástico. Si quieres entender un poco más sobre cómo Node.js toma la seguridad en serio y entender cuáles son los procesos y cómo puedes reportar vulnerabilidades, etc.

Y el modelo de amenazas, la mayoría de las veces es utilizado mucho por los investigadores para entender qué consideramos una vulnerabilidad o no. Y esto se basa mucho en lo que confiamos y en lo que no confiamos. Y lo mismo ocurre con Express, ¿verdad? Tenemos un modelo de amenazas específico que está incluido dentro del grupo de trabajo de seguridad de la organización Express. Y básicamente, si tomamos ambos modelos, ambos documentos juntos y tratamos de combinar algunas ideas, podemos entender que estas bibliotecas y el runtime básicamente están confiando en algunas cosas, ¿verdad?

Algunas de las cosas en las que confiamos son los desarrolladores que están escribiendo este código, ya sabes, las personas que han estado participando en esto, la infraestructura que estás usando para ejecutar esto, ¿verdad? Si estás ejecutando un servidor Node.js con Express, ya sabes, en una Raspberry Pi que es, ya sabes, un entorno que no está controlado, eso es algo en lo que, ya sabes, confiamos en la Raspberry Pi que se ejecuta, confiamos en el sistema que estás usando. También confiamos en el sistema operativo que tienes, ya sabes, si tienes algún tipo de vulnerabilidad del sistema operativo que puede ser explotada para obtener acceso al sistema, entonces no es algo que consideremos una vulnerabilidad porque expones un sistema en el que confiamos, ya sabes, y lo mismo ocurre con la validación de entrada. Sabes, asumimos que, ya sabes, los usuarios finales de las bibliotecas están haciendo las validaciones correctamente. Y también confiamos ciegamente en la mayoría de los archivos que cargamos cuando inicias la aplicación y demás, ¿verdad? Así que hay algunos factores que son importantes para nosotros y en los que confiamos ciegamente. Y hay otras cosas en las que no confiamos. No deberíamos confiar, ya sabes, en nada que venga de la red. No deberíamos confiar en nada que pueda ser entrada del usuario o datos externos, dependencias de terceros y demás.

Bien. Así que básicamente la idea aquí es que cuando vemos que no confiamos en este tipo de cosas, es como cuando construimos aplicaciones y te proporcionamos estas herramientas, no deberíamos simplemente confiar ciegamente en la entrada del usuario como lo hacemos con el sistema operativo. Pero esto significa que básicamente delegamos esta responsabilidad en ti como desarrollador. Así que deberías ser tú quien trabaje en los datos de la red y entienda qué está sucediendo allí. Deberías ser tú quien piense en la entrada del usuario y los datos externos y los archivos que cargas. Las, ya sabes, dependencias que instalaste como parte del proyecto, estas decisiones que tomaste, son algo de lo que eres completamente responsable. Y lo mismo ocurre con otras cantidades de cosas. Bien.

Así que la cantidad de cosas en las que confiamos ciegamente es muy baja y la cantidad de cosas en las que no confiamos es una lista enorme básicamente. Y se espera que asumas la responsabilidad de esto. Y si estás familiarizado, ya sabes, con cualquier tipo de servicios en la nube, la mayoría de las veces, especialmente si trabajas con Azure, si trabajas con Google, si trabajas con AWS y así sucesivamente, podrías estar familiarizado con este modelo de responsabilidad compartida. Bien. Así que terminas construyendo tu aplicación. Quieres exponer esta aplicación a Internet y necesitas un servidor que esté funcionando 24-7 y así sucesivamente con ciertas condiciones para estar lo más disponible posible. Bien. Especialmente si tienes un gran número de SLAs. Bien. Así que tienes muchas opciones, desde el modelo on-premise hasta PaaS, SaaS y así sucesivamente. Bien. Y si ejecutas on-premise, eres responsable de muchas cosas, ya sabes, desde el equipo de hardware, desde la seguridad física del equipo y así sucesivamente, desde ese nivel físico hasta la configuración de la aplicación. Y si estás delegando esto al proveedor, entonces eres menos responsable de este tipo de cosas. Bien. Así que, por ejemplo, si estás usando S3 como un servicio de AWS, no eres responsable de proporcionar los servidores, ya sabes, y la seguridad física para que nadie pueda acceder físicamente a esas computadoras, quiero decir, a esos servidores y hacer alguna manipulación en el hardware y así sucesivamente. Bien. Así es como funciona este modelo de responsabilidad compartida. Bien. Dependiendo de cómo estructures estas responsabilidades. Así que necesitas entender este modelo de amenazas de una manera muy similar. Como hay cosas de las que los frameworks y el runtime están tratando de ser responsables. Y hay cosas de las que te dejamos la responsabilidad de manejar.

Así que es importante tener esto muy claro. Desafortunadamente para nosotros, no es tan claro. Como que no puedes simplemente hacer una tabla y decir, como, esto es lo que las bibliotecas hacen y no hacen. Correcto. Necesitas tratar cada modelo de amenazas cuando esté disponible y entender cómo estas bibliotecas están interactuando y tomando, ya sabes, la seguridad y la perspectiva que están usando. De esa manera entiendes qué se espera, más o menos de ti para asumir la responsabilidad.

Correcto. Así que las mejores prácticas que necesitas tener en cuenta solo, ya sabes, algunos puntos clave de esto. Así que por favor siempre haz validación y sanitización de cualquier entrada que tengas. No importa si es una entrada de formulario, si es una entrada de URL, si es una entrada de archivo, quiero decir, cualquier tipo de entrada que, ya sabes, alguien pueda enviarte y pueda ser manipulada y elaborada y así sucesivamente, debe ser validada. Deberías entender muy bien cómo funciona la autenticación y, ya sabes, tener políticas y estrategias actualizadas y, ya sabes, usar el enfoque de seguridad correcto en esto. Necesitas usar, por ejemplo, encabezados de seguridad y tener una comprensión clara de los ataques web típicos que ves en el OWASP top 10 y así sucesivamente, eso es importante para ti también.

Necesitas, ya sabes, asumir plena responsabilidad de tus propias dependencias. Quiero decir, las dependencias son geniales. Hay como millones de paquetes ahora mismo en NPM que podemos usar para acelerar cómo no trabajamos, ¿verdad? Y no tenemos que reconstruir cada segundo, cada proyecto que hacemos. Pero es importante entender que esas bibliotecas tienen algunos mantenedores alrededor, ¿verdad? Y deberíamos poder entender cómo funciona la seguridad de estas bibliotecas, si están mantenidas o no mantenidas y así sucesivamente.

Quiero decir, ya hay herramientas que podemos usar, como Snyk y Socket y así sucesivamente. Pero es importante que incluyas esto, ya sabes, revisión y auditoría de este tipo de dependencias y tener esto, ya sabes, actualizado con el tiempo. Así que incluye esto en tu ciclo de vida de desarrollo.

Necesitas entender también que si, ya sabes, creas cualquier tipo de servicio que esté fuera y disponible en el internet, tienes que, ya sabes, poner algunos límites en el uso de recursos, ¿verdad? Puede ser como la típica API, aplicar límites en las APIs, llamadas, ya sabes, limitar las comunicaciones, restricciones de IP, ya sabes, tener políticas, este tipo de cosas. También necesitas entender cómo gestionar las cookies, ya sabes, la exposición de datos sensibles es algo muy común, especialmente cuando tenemos errores en el servidor.

Veo, desafortunadamente, recientemente, muchos escenarios donde la gente no manejó adecuadamente los errores en el servidor y terminas enviando esta información de vuelta como el contenido de la solicitud y así sucesivamente. Así que básicamente estás proporcionando incluso mucha más información de la necesaria a un posible atacante también. Así que eso es importante, necesitas manejar los errores adecuadamente. Y necesitas registrar este tipo de cosas también, ¿verdad? Necesitas tener un registro adecuado en su lugar para que puedas entender qué pasó con cada solicitud y qué está pasando en tu servidor en los servicios que tienes en línea. Así que más tarde, puedes hacer una salida adecuada y rastrear qué pasó y entender qué está pasando, ¿verdad? No solo para errores de configuración y libros y errores, sino también en términos de seguridad, entender cómo la gente está explotando tu sistema te ayudará a entender cómo asegurarlos básicamente. Y necesitas tener algún tipo de monitoreo de seguridad y así sucesivamente.

Quiero decir, estoy diciendo muchas cosas, ¿verdad? Así que terminas teniendo una gran lista. Así que la priorización es importante. Así que déjame mostrarte algunas vulnerabilidades del mundo real que podrían ser bastante comunes o que veo bastante comunes. Así que la contaminación de prototipos es una de las cosas más complicadas en mi experiencia. Veo esto mucho. Es algo muy común en JavaScript. Tenemos algunos mecanismos en Node.js y Express para prevenir este tipo de cosas. Pero no hacemos eso para las cargas útiles que te envían, ¿verdad? Así que necesitas tener claro que cuando alguien te envía como un JSON o así, puedes ver allí muchas cargas útiles maliciosas que pueden forzar este tipo de contaminación de prototipos. Así que es importante entender en esto cómo funciona profundamente y también hacer estas sanitizaciones.

Por ejemplo, se entiende que la gente piensa que Express te proporciona como un, ya sabes, encabezados de seguridad bastante completos en su lugar. Así que tienes muchas políticas y así sucesivamente en los encabezados y esto hace que tu aplicación sea mucho más segura. En realidad, Express no hace eso hoy. Pero hay bibliotecas que te ayudan con eso, como Helmet, ¿verdad? Así que es importante entender este tipo de cosas porque reducirá mucho la superficie de ataque en tus aplicaciones. Paquetes maliciosos de terceros. Esto es algo muy común.

Dependes de muchas cosas y las cosas de las que dependes dependen de más cosas y así sucesivamente. Así que básicamente tienes una gran cadena de juego completa. Y eso, desafortunadamente, te añadirá más trabajo porque necesitas tener un control real y comprensión de lo que está sucediendo allí y tener algunas estrategias para mitigar esto. Esto requiere también que entiendas cómo funcionan los CVEs, cómo, ya sabes, cuando necesitas un CVE que ha sido publicado recientemente en una de tus bibliotecas. Esto te está afectando. Necesitas migrar. Necesitas cambiar. Quiero decir, necesitas tomar decisiones y básicamente asumir la responsabilidad de esto. Y es un trabajo completo por sí solo.

Además, necesitas entender todo lo que la gente puede enviarte, por ejemplo, especialmente archivos y cosas así. Necesitas entender cuáles son los límites, ¿verdad? Así que como dijimos antes, de la misma manera que pones límites en la API, tienes que poner límites en la longitud de las cosas que pueden enviarte, especialmente en archivos y cosas así. Así que no te agotes en términos de falta de espacio, servicios, y así sucesivamente.

Así que básicamente, como conclusión, solo una primera conclusión, no todos los problemas de seguridad son vulnerabilidades, ¿verdad? Al final, estamos discutiendo sobre fallos en tu sistema que alguien podría, en un cierto punto, usar para explotar tu propio sistema. Esa es la cuestión, ¿verdad? Y hacer que el software funcione de una manera que no esperabas. Así es como, cuando alguien realmente explota tu sistema. Cuantas más debilidades tengas en tu sistema, mayor es la posibilidad de obtener la vulnerabilidad y eso lleva a incidentes de seguridad. Así que básicamente, si entiendes las vulnerabilidades y la superficie que tienes, te va a ayudar mucho. Los desarrolladores están desempeñando un papel clave aquí, como dijimos antes. Quiero decir, tenemos una cierta responsabilidad entre los creadores de bibliotecas y mantenedores, como yo, y todos los desarrolladores que están usando las cosas que construimos y creamos, ¿verdad? Así que necesitamos entender y tener una buena relación aquí. Y especialmente como desarrollador, necesitas entender dónde establezco mis límites como mantenedor. Así que entiendes dónde necesitas asumir más responsabilidad en las cosas que hacemos. Y lo mismo ocurre con los modelos de amenazas, ¿verdad? Si entiendes realmente bien cómo funcionan estos modelos de amenazas, te puede ayudar mucho. Además, estos modelos de amenazas no solo te ayudan a entender las bibliotecas. Puedes usar este tipo de modelos de amenazas para ayudarte a construir tus propios modelos de amenazas para tu propia superficie, tus propios proyectos, y así sucesivamente, y obtener una mejor comprensión de lo que está sucediendo. Porque la seguridad es un asunto enorme. Es un asunto enorme no solo por la importancia que tiene, también es por la superficie y la cantidad de tiempo que podría requerir de ti, ¿verdad? Así que se siente como una gran cosa por lograr. Y no es algo que puedas lograr en un día o simplemente invertir en, ya sabes, un trimestre dedicado a eso. Y desde ese momento, estás seguro y te olvidas de ello. Es algo que estará junto con tu aplicación, mientras estés ejecutando Internet y aún tengas una superficie que alguien pueda atacar, ¿verdad? Así que básicamente, necesitas entender y tomar todo en serio. Pero también necesitas, ya sabes, entender cómo estos flujos están allí y estarán allí. Así que necesitas tener algunas políticas en su lugar y algunas ideas de lo que está sucediendo. También incluí aquí algunos recursos. Así que básicamente, puedes, ya sabes, profundizar en esto y entender más cosas. También tienes algunos ejemplos sobre cómo, por ejemplo, podemos crear una puerta trasera muy simple en Express Middleware y cómo puedes heredar esto en tu aplicación. Cómo funcionan los CVs en términos de cómo se ejecutan los patrones, así como los modelos de amenazas que mencionamos antes. Bueno, muchas gracias por ver esta sesión. Realmente me gusta la idea de compartir este conocimiento con todos ustedes. Espero que hayan tenido la oportunidad de aprender algo nuevo hoy y estoy realmente abierto a tener muchas discusiones sobre seguridad en las redes sociales en cualquier momento. Así que muchas gracias por estar aquí y compartir este tiempo conmigo.