Encontrar, Hackear y solucionar las vulnerabilidades de NodeJS con Snyk

¿Es Phylicity o Toolkit? Hola, mi nombre es Matt Simon. Soy un Ingeniero de Soluciones en Snyk, por lo que trabajo con clientes de Snyk para mejorar la postura de seguridad utilizando Snyk como su herramienta elegida. En efecto, la sesión de hoy se centrará principalmente en el open source en general y en el uso de open source en JavaScript y NPM para mejorar tus aplicaciones y hacerlas más seguras al mismo tiempo. Esto será principalmente desde una perspectiva de seguridad.

Así que, sin más preámbulos, pasaré a la agenda. La primera parte del día se centrará en el open source, y luego vamos a arrancar una aplicación y también hackearla. Si estás interesado, puedes seguir y hackear la aplicación al mismo tiempo. Voy a arrancar rápidamente el repositorio. Creo que es Node.js.-goof. Lo encontraré rápidamente. Debería estar en mis recientes. Ahí está. Y lo enviaré. Si alguien está interesado, lo enviaré a través del chat de Zoom, y siéntete libre de arrancarlo al mismo tiempo. Y también puedes empezar a hackear mientras tanto. Para ejecutarlo, necesitas tener instalado MongoDB, o simplemente necesitas tener instalado Docker. Puedes hacer una u otra opción. Y voy a repasar... Hay algunos exploits de ejemplo aquí, y también hay algunos más exploits en esta carpeta con los que puedes empezar a jugar por tu cuenta. Solo me centraré en un par de ellos mientras tanto. Pero si tienes tiempo libre y estás interesado, siéntete libre de intentarlo. Así que, sin más preámbulos, continuaré con el resto. Después de hackear estos, tomaremos unos 50 minutos de descanso para relajarnos. Y luego vamos a hablar sobre qué puedes hacer para solucionar las vulnerabilidades que hemos explotado. Y luego haré una introducción básica a alto nivel de Snyk y cómo ayudamos a asegurar las cosas en tu entorno. Espero que todo tenga sentido. Por favor, siéntete libre de interrumpirme durante esta presentación. Quiero que sea interactivo. Y quiero que ustedes obtengan algo de esto en lugar de simplemente hablar en un monólogo. Así que, por favor, siéntete libre de interactuar conmigo. Escríbeme en el chat de Zoom o simplemente quita el silencio y saluda. Sí. Genial. Empezaré.

Entonces, para empezar, esto es solo una introducción básica al open source. Y obviamente, todos sabemos qué es el open source y el poder que tiene y por qué nos importa. La idea principal es que es increíble porque nos ayuda a desarrollar cosas de manera rápida y sencilla. Y también nos permite hacer las cosas de manera más estandarizada, porque podemos iterar sobre los procesos de los demás y descubrir de manera colaborativa cuál es la mejor práctica para hacer las cosas. Como ejemplo de eso, estuve buscando ayer o durante el fin de semana para comprar nuevas piezas de computadora. Y tenemos un sitio web en el Reino Unido llamado scan, que es scan.co.uk. Y esta es una plataforma para comprar piezas de computadora. Entonces, lo que me gustaría hacer como ejercicio es, incluso si no has visto este sitio web antes, si puedes quitar el silencio, solo grita qué partes de esta aplicación web están alojadas o son compatibles con el open source, solo para mencionar algunas funciones o mencionar diferentes formas en las que puedes saber automáticamente. Por ejemplo, al hacer clic en el ticket de ayuda, qué harían en realidad y cómo eso puede ser compatible con el open source. ¿Tiene sentido? Sí, claro. El carrito. Es algo que, ya sabes, todos los sitios web de comercio tienen, y es algo que está estandarizado en todos ellos. Sí, como mucho, Joe. Cuanto más miras, más te das cuenta de que, sí, definitivamente está impulsado por open source en cuanto a cosas como tu inicio de sesión, por ejemplo. Como tienes este pequeño botón de ayuda aquí abajo, que abrirá su propia ventana y widget y luego tendrá características de chatbot dentro de él. Y aunque el chatbot puede no ser gratuito, también puede estar impulsado por algún otro tipo de servicio.

Estos podrían ser anuncios externos. Por lo tanto, podrían ser del tipo en el que haces clic en ellos y te redirigen a otro sitio. Y el proceso de registrar eso y rastrear el aspecto monetario, como los clics y cuánto dinero se genera realmente, todo se hace mediante proyectos de código abierto.

En lugar de, ya sabes, si nos sentáramos y dijéramos, quiero design un nuevo sitio web desde cero. Y quiero que se vea así. No tendrías que empezar realmente desde cero. Comenzarías a implementar diferentes tipos de paquetes de código abierto para automatizar gran parte del trabajo que implica esto.

Entonces, lo que eso realmente significa en términos de realidad es que cuando realmente piensas en tu aplicación y cómo funciona, es como una gran parte de, data y capacidad y potencia bruta que esta aplicación tiene como una aplicación web. Pero en realidad, las cosas reales a las que estás contribuyendo y las formas en que estás manipulando las cosas son una parte muy pequeña de la imagen general de cómo fluye data en toda la aplicación.

Y es realmente útil poder hacer esto de la manera en que hemos explicado cómo puedes iniciar rápidamente algo o replicar rápidamente algo así, y transmitir esa función. Pero también significa que no tienes que ser dueño de todo el sitio en el sentido de que no tienes que ser responsable de cómo funciona el carrito y cómo funciona Elasticsearch. Si hay algún problema con eso, como... como errores o alguna vulnerabilidad de security, tú, como desarrollador que construyó ese sitio web, no eres el único responsable de todo porque es impulsado por la community.

Entonces, es algo donde, ya sabes, tienes la capacidad de obtener ayuda técnica de la comunidad y ese tipo de soporte en cuanto a solucionar problemas. Pero también puede resultar un poco aterrador, de lo cual hablaremos más adelante.

Esto es un poco sobre cómo puedes ver que NPM y el código abierto en general han despegado en los últimos años. Puedes ver que NPM en particular está ganando mucha popularidad en cuanto a la cantidad de nuevos paquetes que se crean en esa región cada año, donde en este momento, tienes alrededor de 1.8 millones de paquetes de código abierto que se están utilizando actualmente. Obviamente, también hay vulnerabilidades en ellos.

Lo que esta estadística muestra aquí es la cantidad de vulnerabilidades que se pueden encontrar en dependencias indirectas. Lo que quiero decir con eso es específicamente... Si tienes en cuenta que el 86% de todas las vulnerabilidades se encuentran en dependencias indirectas, si muestro esta diapositiva, debería quedar claro qué es una dependencia. En este caso, tengo un paquete llamado express, que llama a accepts, que llama a MIME, que llama a MIME DB.

Lo que esto es efectivamente, si puedes imaginarlo, digamos que soy un niño y mis padres están fuera de la ciudad durante el fin de semana, y estoy invitando a un amigo. Eso podría ser mi express en este caso. Confío en él. Lo conozco desde la infancia. Me siento cómodo dejándolo entrar a mi casa. Luego trae a un invitado. Y pienso, oh, está bien, confío en su juicio. Él respalda a este personaje, lo dejaré entrar. Luego, el invitado trae a otro invitado, y luego los invitados traen a otro invitado más. Entonces terminas con esta serie de incertidumbre creciente en cuanto a lo que realmente estás introduciendo en tu aplicación y en lo que no puedes ver realmente y tener confianza en sus estándares de security y sus prácticas en general.

Eso es básicamente lo que sucede cuando vemos, cuando analizamos todas las vulnerabilidades aquí, donde puedes confiar en la dependencia principal que tienes dentro de tu paquete. Puedo confiar en express en este caso, pero la realidad es que no puedo ver todas las dependencias de tránsito que express estará incorporando fácilmente. Tampoco puedo verificar y examinar la security de todas ellas. Al final, te encuentras en una situación en la que simplemente hay mucha incertidumbre en la seguridad general de esa aplicación.

La pregunta entonces es, hemos tenido en cuenta cuáles son los riesgos de usar código abierto, y también hemos considerado los beneficios de usarlo. La pregunta ahora es, ¿cuál es la postura general de seguridad al usar código abierto? Básicamente, de la misma manera en que obtienes valor de la comunidad a través del código abierto, también tienes personas que contribuyen a bases de datos que contienen información sobre vulnerabilidades.

Efectivamente, la respuesta a cómo podemos confiar en las cosas es básicamente confiar nuevamente en otros para proporcionar datos de vulnerabilidad de código abierto. Las personas son muy abiertas a hacer esto y también son muy proactivas al respecto. Pero debe hacerse de una manera en la que realmente puedas tener visibilidad también porque no vas a sentarte allí y simplemente observar todos los hilos y ordenar los diferentes paquetes que estás utilizando en GitHub porque nadie tiene tiempo para eso. Al final del día, tienes una vida.

Hablaremos un poco sobre cómo se ve eso con Sneak en general, y hay otras herramientas y formas de hacerlo, pero lo dejaremos para el final. Lo dejaremos para el final por ahora.

En este momento, vamos a hacer un poco de preguntas y respuestas o un poco de adivinar el número. Entonces, la pregunta aquí es, ¿cuál es el porcentaje de paquetes en npm que no tienen dependencias ni dependientes? Estos son en este caso paquetes que están solos y luego no tienen, okay, el 6% proviene de pizza, el 12%. Estas son cosas que son independientes, no necesitas nada para ejecutarlas, y no las utiliza nadie más. Entonces, el 28% de los paquetes en realidad no utilizan ningún tipo de dependencia y tampoco tienen dependencias basadas en ellos. Pero estas no son necesariamente los paquetes más populares.

Son simplemente paquetes que se crean para lograr ciertas cosas y luego se utilizan a través de otros miembros de la community. Entonces, en realidad no se construyen proyectos basados en ellos. Esta fue una estadística interesante para mí personalmente porque, al igual que la mayoría de ustedes, habría dicho el 6%.

Otra estadística es cuál es la profundidad promedio de una cadena de dependencias de paquetes en npm. Esto se refiere específicamente a los paquetes que tienen dependencias. ¿Cuánto tiempo tiene esa cadena habitualmente? Tenemos 2, 3, 4, 3, 3, 3, 3. Bien, el promedio es aproximadamente tres. Entonces, la respuesta aquí es en realidad cuatro. Una vez más, solo estamos viendo estadísticas. Es un poco extraño ver eso, en realidad. Probablemente debería haber puesto cinco y algunas opciones adicionales para que cuatro parezca la opción mediana. Pero sí, cuatro es la respuesta correcta aquí en términos de la cadena promedio de las dependencias.

Y finalmente, ¿cuántos paquetes en npm se podrían considerar abandonados? Esto se refiere básicamente a todos los paquetes que vimos al principio, que eran 1.8 millones, ¿cuántos de ellos no han sido actualizados o modificados en el último año? Y no son cosas que se pongan en un nivel de mantenimiento. Estos son aquellos que no han tenido una actualización activa o no han tenido ningún aviso o corrección de errores en el último año. Entonces, 61%, eso sería aterrador, 27%, 15%, 27%, bien. Aquí tenemos una distribución más amplia. Sí, la respuesta es en realidad 15%. Así que eso también es una estadística interesante. De todos los paquetes de código abierto, el 15% simplemente no se están tocando más. No se pusieron en una lista de vigilancia. No se están manteniendo de ninguna manera. Completamente abandonados, sin señales de vida. No significa que sean vulnerables, pero significa que los mantenedores, las personas que trabajaron originalmente en ellos, simplemente no están mirando activamente ese proyecto y revisando cualquier posible problema relacionado.

Sí, soy responsable. Sí. Bueno, creo que lo principal es que si recibes notificaciones sobre personas que encuentran problemas en él y errores específicamente relacionados con la security, creo que deberías mantener un ojo en ellos para asegurarte de que, de hecho, si alguien está haciendo el trabajo de promover una solicitud de extracción que solucionaría las cosas, poner un poco de esfuerzo en validar eso y hacer algunas pruebas de regresión y fusionarlo, porque eso ayuda mucho, como hemos visto antes, a apoyar todo el ecosistema porque tienes cadenas de cuatro. Entonces, tu paquete de código abierto podría estar siendo utilizado en muchas cosas.

Pero sí, aquí hay otra cosa sobre el código abierto en general. Aquí hay otro juego de adivinanzas. Esto se trata de una vez que has descubierto qué tipo de paquetes tienes en esta cadena, por ejemplo, tienes Accept MIME y MIME DB. Y ya hemos establecido que esos podrían no ser paquetes en los que confíes necesariamente, especialmente considerando las estadísticas de que la mayoría de las vulnerabilidades están en tus dependencias transitivas. Pero la pregunta es cómo pueden volverse vulnerables las cosas dentro de esas dependencias principales. En el caso de Express, por ejemplo, tenemos el ataque conocido como typosquatting. Básicamente, esto es cuando alguien ha creado un nuevo paquete que es muy similar a un paquete conocido y confiable con la esperanza de engañar a las personas para que utilicen un nombre ligeramente diferente o cometan un error al instalar el paquete incorrecto y poner algo malicioso en él.

Entonces, adivina rápidamente, ¿alguien puede adivinar cuál es el paquete correcto en este caso? Este es el paquete oficial en este caso. ¿Están todos familiarizados con crossenvironment? ¿Alguien lo ha usado antes en el pasado? Efectivamente, una de estas es la respuesta correcta. De acuerdo, genial. La respuesta que puedo decirte es en realidad C en este caso, que nadie dijo en realidad. Así que este es el paquete correcto en este caso. Muchas personas, si lo buscaran en Google y crossenvironment, como por ejemplo, con Outlet Space, todavía aparecía y era malicioso, MPM lo ha eliminado desde entonces, causaría muchos problemas y lo mismo sucedería con A en este caso. A y C son en realidad muy similares. Y si hicieras referencia solo a A, entonces estaría bien, MPM tomaría y obtendría la versión correcta C en este caso. Pero eso solo sucede porque MPM ha bloqueado un nombre y una convención de cross-environment para evitar que las personas lo creen y para que se establezca por defecto. Pero el nombre oficial es en realidad crossenvironment.javascript.

Pero la razón principal por la que quería mencionar esto y jugar a ese juego es porque enfatiza lo fácil que es cometer este tipo de errores como humano. Y si no lo estuvieras escribiendo tú mismo y simplemente estuvieras leyendo un package.json para encontrar, digamos, en mi caso de express, por ejemplo, quiero ver la estructura de las dependencias y express usa environment, cross-environment sin el guion.json. Y solo usa cross-environment. Podrías fácilmente no darte cuenta de que se está instalando un paquete malicioso. Y luego, el otro tipo de vulnerabilidad que podría ocurrir y hacer que una dependencia principal sea vulnerable, una vulnerabilidad en ese caso, podría ser en el caso de cuentas comprometidas.

Entonces, esto básicamente se refiere a los mantenedores de confianza conocidos que pierden sus privilegios o sus derechos de publicación y en realidad son comprometidos. Así que las personas comienzan a cargar código malicioso en paquetes muy confiables. Y esto es algo real. Y ha sucedido en el pasado. Entonces, una cosa que diría, si estás manteniendo alguna biblioteca de código abierto, lo que haría en estas bibliotecas es asegurarme de que tengan habilitada la autenticación de dos factores. Esto puede ser literalmente asegurarse de que antes de que alguien envíe algo a tu repositorio de GitHub, tal vez tengan que tener una configuración, un segundo punto de contacto para habilitarlo. De modo que si tus secretos, por ejemplo, se filtran y las personas tienen acceso a tu cuenta de GitHub, en realidad no puedan realizar cambios en eso sin usar autenticación de dos factores para evitar que tu exposición se convierta en un problema más amplio, especialmente si estás manteniendo muchas proyectos de código abierto que se descargan millones de veces, eso puede causar un problema mucho más extendido. Y eso es en última instancia lo que las personas buscan con esos secretos para obtener privilegios aún mayores en otros lugares. Entonces, esas son dos de las formas en que básicamente puedes comenzar a dudar de la forma en que se mantienen los paquetes.

También quiero hablarles un poco sobre Cross Environment como un caso de estudio. Cross Environment es y sigue siendo un paquete muy popular de NPM. Se utiliza para manejar variables de entorno en diferentes plataformas. Por ejemplo, si hay diferencias entre Linux y Windows, referenciar una variable de entorno en Windows sería muy diferente a hacerlo en Linux. Para simplificar ese proceso, en lugar de realizar comprobaciones del sistema y cambiar los comandos según la plataforma, puedes utilizar este paquete de código abierto para manejar las variables de entorno. Solo necesitas proporcionar el comando o la variable de entorno que deseas crear. Esto facilita el proceso.

Actualmente, se descarga aproximadamente 4 millones de veces por semana. Verifiqué esto ayer mismo. Más de 5000 de esas descargas son paquetes que dependen de él. Por lo tanto, está integrado en muchas cadenas. Sin embargo, en 2017, fue víctima de un ataque de typo squatting. Alguien creó el paquete Cross Environment con un nombre similar. Este paquete se lanzó y estuvo disponible durante aproximadamente 12 días antes de ser reportado y eliminado por NPM. Durante esos 12 días, se descargó casi 700 veces. Por lo tanto, 700 personas potencialmente estuvieron expuestas debido a un simple error tipográfico. Y como este paquete se descargaba a través de otros paquetes, podría haber afectado a muchas más personas. Fue un riesgo muy real asociado a él. Lo que hacía era capturar las variables de entorno y enviarlas a un servidor remoto controlado por el atacante. De esta manera, si descargabas este paquete y lo utilizabas, Es un riesgo muy real en la industria en ese caso.

Afortunadamente, esta es la parte de la masterclass a la que espero que asistan. Vamos a hackear una aplicación en vivo. Nos adentraremos en el aspecto de la seguridad en lugar de solo hablar de datos curiosos. Esta es una breve introducción a la inyección de SQL. Seguro que muchos de ustedes saben qué es la inyección de SQL, pero solo daré una explicación básica para introducir el tema. La inyección de SQL es básicamente cuando puedes manipular una cadena SQL normal y llenarla con todo tipo de variables para realizar acciones maliciosas. Esto puede implicar suplantar usuarios, eliminar tablas o instalar tus propias cosas, o incluso crear nuevas tablas si así lo deseas. En nuestro ejemplo, tenemos una función user.find que recibe un nombre de usuario y una contraseña directamente. Esta función crea una consulta SQL para iniciar sesión. Si encuentra un usuario, redirige la página a una cuenta y muestra el mensaje `Has iniciado sesión como esta persona`. Eso es lo que vamos a explotar en este caso. Voy a mostrarles rápidamente cómo hacerlo. Esta es mi aplicación vulnerable. Si no estuvieron aquí al principio, les proporcioné el enlace y lo compartiré nuevamente. Pueden descargar esta aplicación vulnerable y probar ustedes mismos cómo explotarla. Pero lo que voy a hacer es usarla como una lista de tareas. Por ejemplo, puedo crear listas y subir archivos. También puedo ver la página `Acerca de`, que es muy básica en este momento. Solo la he creado para poder romperla. Y aquí tengo el término que se está alojando aquí.

Lo que voy a hacer es intentar iniciar sesión solo usando Curl en este caso. Solo para mostrarles cómo debería funcionar, y esto va a ser iniciar sesión en el sitio web en este caso, que es mi localhost. Y no voy a escribir nada porque estoy en cámara y no quiero cometer demasiados errores tipográficos. No es divertido.

Entonces, lo que esto está haciendo es usar Curl, está creando un archivo de cookies y está estableciendo el tipo de contenido como aplicación JSON. Y dentro de eso, le estoy pasando variables. Así que estoy tratando de acceder a la página de inicio de sesión aquí, que, por cierto, me aseguraré de que se vea así, se ve así. Y dentro de estas variables, estoy pasando mi nombre de usuario y mi contraseña, que en este caso es un nombre de usuario de administrador y la contraseña súper secreta. Así que esto es muy literal en este caso. Solo lo ingresaré y puedes ver aquí a la izquierda o puedes ver aquí que he sido redirigido a la página de administrador y puedes ver aquí a la izquierda, tengo este mensaje de usuario conectado como administrador. Lo haré un poco más grande para que sea fácil de leer.

Entonces, la pregunta ahora es, ¿qué sucederá si intento ingresar una contraseña incorrecta? Y la respuesta a eso sería, obviamente debería regresar y darme un mensaje de error diciendo que no se ha encontrado o que el usuario no se puede encontrar. Entonces, en este caso, obtengo un 401, por lo que no estoy autorizado para acceder a eso. Y eso es básicamente una prueba de concepto de que esto funciona como una función muy básica en el sentido de que si vuelvo aquí, esto realmente funciona para validar, para encontrar que esta fue la contraseña incorrecta en este caso, por lo que no me inició sesión.

Ahora, la pregunta sería, ¿cómo puedo comenzar a hackear esto? Y en este caso, ¿alguien tiene un ejemplo o alguna sugerencia de cómo puedo comenzar a ingresar a Hackett? Bueno, si no, puedes escribirlo. ¿Algo en el chat si quieres escribirlo? ¿Contraseña identificada como nula? Sí, podrías intentar ingresar algo así. Creo que en este caso no funcionaría porque estamos verificando que coincida exactamente con la contraseña. Entonces, no regresaría diciendo que se encontró. Dirá que es una contraseña identificada como nula. Dirá la coincidencia exacta en ese caso. Entonces, lo que tendrías que hacer es romper este comando aquí. Lo que realmente puedes hacer dentro de esto, y te lo mostraré ahora, es que podrías ingresar. Sí, podrías intentar romperlo con un uno igual a uno. No funcionará en este caso porque no te lo he mostrado, así que te mostraré cuál es la respuesta en este caso. Luego te mostraré al final cómo puedes solucionarlo. Así que lo tengo predeterminado. Así que está aquí. Entonces, lo que estoy ingresando en el campo de contraseña en este caso es en realidad un objeto. Entonces, puedes ver aquí, así es como está anotado. Entonces, esta llave de cierre de llave aquí cierra el binario original data. Y luego, esto cierra el binario data que hemos ingresado. Pero en el campo de contraseña, en lugar de ingresar una cadena, porque no estoy validando una cadena en este caso, literalmente estoy pasando un objeto con eso. Y la forma en que funciona es efectivamente porque estamos validando que se encuentre una longitud, vamos a regresar y decir que en realidad es mayor que uno o mayor que cero en este caso, y simplemente forzarlo a iniciar sesión. Por lo tanto, es parcialmente vulnerable porque en realidad no estamos saneando una cadena. No estamos validando que la cadena esté presente, pero también es vulnerable por diseño en la forma en que funciona esta función de mayor que cero en primer lugar. Entonces, aunque funciona en la práctica, no es necesariamente el método más robusto de autenticación e inicio de sesión de las personas. Entonces, si continuamos y ejecutamos eso, puedes ver que ahora me ha redirigido a la página de administrador. Y que tenemos este mensaje que dice que ahora estamos conectados como administrador en este caso. Y eso fue una pequeña introducción a la inyección de SQL. El siguiente paso ahora que tenemos privilegios de administrador es comenzar a hacer cosas un poco más maliciosas y comenzar a obtener cosas, podríamos hacer un par de cosas aquí, como obtener cookies o comenzar a introducir cosas como scripting entre sitios mediante la carga de archivos, a los que quizás no tengamos acceso. Lo que vamos a hacer es invertir una contraseña o un directorio. Entonces, lo que va a suceder es que como tenemos acceso a un archivo, podemos básicamente, lo que vamos a mostrar aquí en este sistema, ahora tenemos acceso a los detalles de la cuenta. Entonces, tenemos la capacidad de editar la nuestra. ¿Por qué apareció eso? Oh, es porque aún no he iniciado sesión con esta terminal. Así que déjame iniciar sesión de nuevo rápidamente. Y voy a iniciar sesión usando la contraseña súper secreta y un nuevo correo electrónico, solo en este navegador rápidamente, porque no está, creo que debería estar guardado. Una vez que haya iniciado sesión, debería tener acceso a los detalles de la cuenta, así, y efectivamente lo que puedo hacer es ir a aquí y comenzar a poblarlos con mis propias cosas. Lo que es un problema parcial, si alguien ha oído hablar de esto antes, es que al ingresar una variable, puedes comenzar a ingresar a un directorio y comenzar a acceder a cosas a las que no necesariamente tienes acceso. Y la forma de hacer esto es proporcionar nombres de variables con básicamente secuencias de barras invertidas y puntos.

Básicamente, estás navegando hacia arriba. Si ingresara algo en los detalles de la cuenta, efectivamente, lo que haría es alejarse de los detalles de la cuenta y volver a donde se encuentra la estructura de la aplicación, a la cual quizás no pueda acceder. Y en este caso, irá a mi definición de mi aplicación para poder ver cosas como mi código fuente y cosas como mi archivo package.json, que es lo que estoy a punto de hacer. Algunas formas en las que puedes asegurar esto o formas en las que esto ha intentado asegurarse es, efectivamente, tiene algún tipo de validación incorporada en las variables aquí. Entonces, si continuo y hago algo así y luego vuelvo atrás y ordeno. Y luego escribo algo como package.json o algo así, en realidad no podrá pasar nada a través de eso, no podrá traer nada de vuelta porque dentro de estas variables individuales en la forma en que están codificadas, las estamos procesando y validando usando cosas como nuestro validador de recorte y también estamos usando escape para escapar de estos caracteres especiales. Pero una cosa que no estamos haciendo dentro de esto es validar nuevas variables que se crean. Y obviamente, de la forma en que se nos presenta esto, no puedo ingresar variables en este formato, literalmente puedo crear nuevas variables dentro de mi terminal cuando estoy pasando objetos curl. Entonces, lo que puedo hacer es ejecutar esto y básicamente tengo otro comando y solo en el costado, ten paciencia. Está apareciendo en algún lugar. Aquí vamos. Entonces, en este caso, estoy accediendo a este tipo de página aquí. Entonces, estoy haciendo una solicitud o envío a los detalles de la cuenta de este sitio aquí, pero también estoy proporcionando el nombre del correo electrónico. Estoy proporcionando el nombre, apellido. Tengo el número de teléfono del país, pero luego también estoy agregando un campo adicional aquí, este campo de diseño. Y debido a que esto no es algo que esté codificado y no lo estoy esperando, entonces literalmente dentro de mi aplicación no tengo ninguna validación que se esté ejecutando en esta entrada o esta variable. Entonces, lo que puedo hacer es básicamente ver cómo se ven estas variables y verás que tengo mi nombre. Eso es un poco... Este es mi package.json, tengo mi nombre, tengo mi nombre, tengo mi número de teléfono. Y luego tiene este package.json, que es como, ha vuelto a subir en la cadena en términos de mi directorio de archivos. Y ha extraído este package.json, que es obviamente contiene toda la información sobre mis paquetes de código abierto. Entonces, lo que realmente pude hacer con esto es, al escribir esto en curl y básicamente tener permisos de administrador para realizar cambios en mis detalles, pude ingresar y obtener acceso a algo a lo que no debería tener acceso, que en este caso son los archivos package.json. Y con eso, puedo ver información sobre otros tipos de vulnerabilidades utilizando esto. Porque sé lo que hacen y cómo interactúan con las cosas, básicamente puedo aprender cómo explotarlos aún más y hacer otras cosas maliciosas. Entonces, una cosa que puedo ver, si puedo encontrar un ejemplo aquí, sé que también usamos Mark. Sí, también usamos Mark en la versión 0.35, que tiene una vulnerabilidad. Entonces, puedo seguir adelante y explotar Mark. Entonces, si vuelvo a mis diapositivas, también puedes ver que Mark tiene un ejemplo de una inyección de scripting entre sitios. O el scripting entre sitios es efectivamente la capacidad de alojar código en la propia página web. Entonces, literalmente puedo ejecutar un script, inyectarlo en la página principal aquí y luego cuando las personas hacen clic en él y lo activan en su lado del cliente. Ahí es cuando algo malicioso puede activarse. Y esto es muy común tipo de vulnerabilidad. Si alguna vez estás en un sitio web y haces clic en algo y aparece una ventana emergente en tu pantalla, luego desaparece y trata de ocultarse de diferentes maneras. Eso es probablemente lo que está sucediendo. Probablemente tu HTML o tu navegador está siendo instruido para realizar un script. Y luego sucede en tu lado del servidor en lugar de suceder dentro de la aplicación. No es como una inyección de código. Literalmente, algo está sucediendo dentro de mi cliente. Entonces, eso es lo que es el scripting entre sitios. Y la forma en que podemos hacer que esto suceda es porque tenemos esta vulnerabilidad dentro de Marked. Entonces, Marked es un paquete de código abierto muy popular. Se utiliza en aproximadamente seis millones de descargas por semana, y tiene siete mil dependencias diferentes. Por lo tanto, siete mil productos están utilizando Marked para hacer que funcione. Y también tiene esta vulnerabilidad. Entonces, estamos usando la versión 0.35. Esta versión se corrigió hace mucho tiempo en 2016, pero aunque se hizo público en 2016, les llevó casi un año a los mantenedores de Marked actualizar su versión aquí. Entonces, hubo una solicitud de extracción en Marked donde alguien dijo, por favor, ¿pueden actualizar esto? Esto soluciona la vulnerabilidad. Les llevó casi un año parchar esta vulnerabilidad. Y esto es algo que permite el scripting entre sitios en este caso. Así que todos deberían estar muy familiarizados con Marked.

Básicamente, se utiliza para permitir HTML y escritura elegante dentro de los navegadores. Por ejemplo, Reddit lo utiliza. GitHub también lo utiliza para los usuarios de readme. Es ampliamente utilizado en la industria para hacer que el contenido sea legible y funcional, lo que permite agregar HTML en su interior. Es muy útil para la creación de contenido. Pero también podemos explotarlo. Te mostraré rápidamente cómo se ve eso. Dentro de mi GOOF, como viste antes, escribí un comando. Ahora puedo comenzar a usar Marked, que es el lenguaje de marcado, para intentar inyectar algo de scripting entre sitios. Lo siento, no SQL, sino scripting entre sitios. Así que lo que haré es mostrarte por qué quieres usar Marked. En este caso, voy a publicar esto. Básicamente, este es el nombre del texto. Y dentro de eso, Mark sabe que esto será un enlace HTML. Por lo tanto, lo procesará y me permitirá agregar esto como un pop-up interactivo. Ahora puedo agregar un enlace HTML al sitio web que quiero nombrar. También puedes agregar cosas como negrita, por ejemplo, y luego obtendrás texto en negrita. Es muy útil para administrar una página y permitir que las personas creen cosas interactivas en su sitio web. Pero obviamente, con esa interactividad vienen muchos riesgos, por lo que se realizan muchas validaciones. Realmente hacen muchas validaciones. Si intento ingresar algo como JavaScript en este caso, en realidad evitará que se ejecute dentro de él o lo eliminará. Si ve que estás intentando usar JavaScript y crear esto, en realidad me bloqueará. Lo único que pasará en este caso si vuelvo atrás es solo este corchete adicional dentro de eso, porque estamos eliminando el resto de ellos de manera efectiva. Esto muestra que los mantenedores en este momento eran muy conscientes de la seguridad y habían realizado la sanitización para estos casos de uso. Pero si seguimos adelante y tratamos de romperlo de otras formas, si intento esta iteración aquí. Lo que estamos haciendo aquí es intentar usar algunas expresiones regulares en este caso, por lo que estamos tratando de escapar de ella y proporcionar contenido adicional para engañarla y agregar algunos colores diferentes, por ejemplo. Esto aún se está sanitizando, por lo que todavía podemos pasar por eso. Pero en esta vulnerabilidad en particular, había un problema en el que no estaban sanitizando una cantidad y la forma en que esto funcionaba. Si abro esto rápidamente y si no sabes qué es esto dentro de JavaScript, efectivamente, la forma en que funciona es que dentro de esto básicamente está creando o haciendo referencia a un objeto en sí, pero no se está cerrando en este caso. Entonces, lo que estamos haciendo porque solo está buscando que esto se active de una manera que esté cerrada con éxito o que se use de manera precisa. Entonces, la forma en que funciona la expresión regular es que está buscando una instancia de esto y si está cerrada, tal vez en realidad esté tratando de hacer algo de JavaScript y JavaScript interactuaría con eso. Pero lo que dirán es que debido a que esto no está cerrado de una manera que lo acepte, es posible que logre pasar la validación. Y la importancia de esto es que en realidad no importaría porque sería solo JavaScript roto en este caso, pero lo que está sucediendo es que mientras un validador no detecta esto y mientras la aplicación ejecuta esto, lo que hacen los navegadores de manera muy útil o no útil en este caso es que ven que hay un problema con el JavaScript aquí y ven que esto no está representado o no está cerrado y en realidad lo eliminan y el resultado de eso se ve así. Terminas siendo capaz de pasar y crear tu propio pequeño demo o el código que has creado para mostrar que es correcto ejecutarlo. Por lo tanto, nos da la capacidad de actualizar nuestra experiencia mientras estamos en el código fuente, si hay problemas en el backend. Recibimos una alerta por algo. Lo que estamos haciendo es simplemente eliminar las advertencias porque no queremos que el mensaje esté en algo que no se menciona en ningún lugar y no se está utilizando en realidad dentro de él porque, bueno, simplemente no se está representando y el navegador HTML no lo está cargando porque están tratando de obtener algunas variables del usuario y enviarlas a algún lugar, luego puedo comenzar a recopilar información sobre los usuarios que realmente interactúan con este sitio web. Entonces, esa es una forma en que se puede explotar el scripting entre sitios en este ejemplo en particular. Y todo esto se debe a que Marked en sí era vulnerable en esta versión en particular. Y si echas un vistazo a Marked y vas a las diferentes versiones dentro de él. Es una versión bastante antigua. Era la 3.5, 3.6. Es una versión antigua de esto, y pasó literalmente un año entre estas dos versiones diferentes para actualizarse. Por lo tanto, hubo un año de instancias en las que las personas realmente conocían esta vulnerabilidad y realmente pudieron explotar a las personas que la usaban también. En cuanto a dónde obtengo toda esta información, en términos de qué tipo de vulnerabilidades existen en eso. En realidad, puedes acceder públicamente a la base de datos de vulnerabilidades de Snyk. Así que simplemente escribiré esto y luego tengo la base de datos y luego buscaré rápidamente... Esto es por qué no escribo en vivo porque no soy muy bueno en eso.

Pero en este caso, estaba usando, creo que era, 3.6 o algo así. Creo que fue este, en este tipo de vulnerabilidad aquí. Así que porque sabía si vuelvo a mi terminal aquí, porque sabía el tipo de paquetes de código abierto que tengo aquí y pude identificar cuál era vulnerable en forma de esa versión de Marked aquí, pude ir y explotar eso aún más.

Hay otra vulnerabilidad aquí, a la que entraré ahora, que está dentro del Validador. Entonces, el Validador en esta versión en particular es vulnerable a un redos o un ataque de denegación de servicio redirigido. Entonces, si entro en cómo se ve eso, o denegación de servicio de expresiones regulares. Efectivamente, lo que es la denegación de servicio, es más o menos lo que suena. Básicamente, cuando intentas detener un servicio, una aplicación de funcionar como se espera. Puede que desees desactivar una aplicación, se podría usar en ransomware para detener el funcionamiento de las cosas, como cuando un usuario hace una declaración política, o detener algún tipo de servicio para tener acceso a otro efectivamente. Entonces, esa es la razón por la que existe la denegación de servicio como un tipo de ataque. La forma en que funciona la denegación de servicio de expresiones regulares es efectivamente utilizando expresiones regulares cuando estás validando información dentro de una cadena, por ejemplo. Entonces, lo que hace el validador en este caso, se utiliza para todo tipo de diferentes tipos de validación cuando estás mirando cadenas y diciendo, quiero asegurarme de que sea un correo electrónico, por ejemplo. Lo que realmente está haciendo detrás de escena es buscar expresiones regulares para ver si las cadenas o las entradas que estás poniendo coinciden con los caracteres que se esperan. Pero la forma en que funciona como un motor es efectivamente escalando según la complejidad de los diferentes tipos de variables que estás poniendo.

Entonces, en este caso, puedes ver aquí abajo que tengo un número creciente de pasos básicamente para manejar diferentes tipos de cadenas. Y en este caso, donde tengo 14 C diferentes seguidas, y puedo mostrarte en nuestro sitio web cómo se ve la expresión regular detrás de esto, que lleva tiempo validarla, pero puedes ver que esto lleva 65,000 pasos para procesarlo. Y la razón de esto es porque efectivamente hay tres o cuatro formas diferentes en las que podemos agrupar las C. Entonces, lo que sucederá es que comenzará a validar y dirá, primero encontramos una A, luego encontramos una C, luego encontramos otra C, luego encontramos otra C. Y lo que espera encontrar después de eso es una X, y luego seguirá hasta que encuentre una X. Y básicamente, cada vez que pasa por eso, tendrá que realizar otro paso para retroceder. No quiero profundizar demasiado en las expresiones regulares aquí porque puede llevar mucho tiempo explicar realmente el motor detrás de él y por qué esto se convierte en una carga computacional masiva. Pero efectivamente, si una expresión regular no puede encontrar un grupo que espera, y no puede manejar un tipo de carácter que estás poniendo en ella, efectivamente, lo que tendrá que hacer es, tendrá que retroceder a los caracteres anteriores y los caracteres anteriores a eso hasta el punto en el que pueda poner ese carácter o esa cadena en un cierto grupo que se espera. Y esto se conoce como retroceso catastrófico. Y básicamente así es como puedes realizar algún tipo de redos en una aplicación. Eso fue probablemente muy pesado, mucha charla de mi parte. Entonces, lo que voy a hacer es mostrarte rápidamente cómo se ve eso en la práctica. Entonces, esta es una versión particular del Validador que era vulnerable a esto. Era una versión anterior a la 13.7. Creo que fue la versión vulnerable real. Literalmente cualquier versión excepto la última. Y si vamos al Validador aquí, puedes ver que hay alrededor de 6,000 o lo siento, seis millones de descargas semanales diferentes por semana. Y también hay 5,000 proyectos que dependen de él. Y ahí está, la última versión, que se solucionó en 2021, tomó alrededor de tres o cuatro meses para solucionarlo. Se publicó por primera vez como una vulnerabilidad a fines de abril. Y luego la solución se implementó a fines de noviembre. Pero aún hoy, hay más de 400,000 descargas semanales de la versión vulnerable de eso. Entonces, eso es una pérdida de rendimiento masiva que se ve dentro de eso, donde las personas pueden usarlo para enviar constantemente una [858]solicitud al punto final y básicamente romper la lógica, que está dentro de tu Validador para explotarlo. El método en particular que es vulnerable en este caso es rtrim. Y la forma en que se usa es en este caso, puedes ver un ejemplo aquí. Lo que estamos haciendo en el Validador con rtrim es que básicamente estamos eliminando espacios en blanco. Entonces, lo que esto realmente parece, vamos a ir al archivo readme rápidamente y encontrar el Validador. Lo siento, encontrar rtrim. Hay muchas formas diferentes en las que se está utilizando el Validador. Ahí vamos, rtrim. Entonces, lo que está haciendo es recortar caracteres del lado derecho de la entrada. Entonces, la entrada serían caracteres que no son espacios en blanco en este caso. Entonces, lo que termina pareciendo dentro de esto es básicamente si ingresara una entrada como hola, o como mi nombre es Matt o simplemente Matt en este caso, y luego ingreso cien espacios en blanco diferentes después de haber ingresado la entrada, luego puedo eliminar cualquier espacio en blanco diferente después. Básicamente, va a pasar por ellos y luego verá si después de este siguiente carácter hay un espacio en blanco.

Y por lo tanto, eliminar cualquier cosa después de eso y eliminar cualquier cosa después de eso si es un espacio en blanco y básicamente intentar reducirlo al punto donde no haya espacios en blanco dentro de él. La forma en que esto era vulnerable en realidad es efectivamente puedo mostrarte cómo se ve el exploit ahora. Así que volveré a mi consola nuevamente y voy a ingresar una nueva consulta en ella. Voy a enviar nuevamente los detalles de la cuenta, y esta vez en lugar de llenarlo con un archivo vulnerable o algo así, simplemente voy a ingresar una variable que espera ver, así que estará en ese primer nombre donde estoy haciendo esta validation con Arturum. Y lo que voy a hacer dentro de eso es enviarlo y voy a poner mil o 10,000 espacios en blanco diferentes seguidos de un signo de exclamación. Y lo que esto va a hacer es que efectivamente va a parecer un espacio abierto masivo y un signo de exclamación. Y la razón por la que no puede manejar esto es porque los espacios en blanco están al principio de la cadena. Y además, no puede entender que es solo un signo de exclamación conocido porque ese es un carácter especial que no representa el nombre. Pero el resultado de esto es básicamente que va a ir hasta el final y buscar y retener en su memoria todos los diferentes espacios en blanco antes de llegar al signo de exclamación y darse cuenta de que eso no es parte de un grupo que comprende y luego tener que retroceder a través de ellos yendo en la otra dirección. Y al hacerlo, básicamente ocupa mucho tiempo de computación y básicamente deja fuera de servicio durante un período significativo. Entonces puedes ver que ya he ingresado el sim y aún no recibo ninguna respuesta. Si actualizara esto, simplemente estaría caído. Y tarda unos 20 segundos en ejecutarse realmente. Así que ahora ha vuelto con una respuesta y la respuesta termina viéndose así. Ni siquiera puedo llegar a la parte superior de la pantalla porque todo son solo espacios en blanco seguidos de un signo de exclamación. Básicamente, ha terminado cayendo en su lugar y no eliminando los espacios en blanco allí. Entonces, esta es una forma en que esto es vulnerable.

Genial. Solo soy consciente del tiempo. Ya hemos utilizado bastante hasta ahora. Desafortunadamente, literalmente no tenemos forma de ver que es solo una aplicación muy básica detrás de escena. Así que en realidad no puedo ingresar a los detalles de la cuenta y no verlo. ¿Cómo puedo obtener ese paquete para Jason? Así que permítanme volver a ver cómo se ve eso. Entonces, ¿qué está haciendo? Y rápidamente lo revisaré aquí y volveré a ejecutar mi comando y explicaré cómo funciona. Efectivamente, el package.json. Entonces has visto esta entrada de entrada. Entonces los detalles de la cuenta me han sido enviados en este caso. Pero el package.json aquí básicamente estamos creando este nuevo archivo o este nuevo tipo de variable llamado layouts. Y esto es algo que solo podemos hacer con JavaScript. simplemente porque es efectivamente como, es una variable en el objeto mismo de los detalles de la cuenta. Y lo que podemos hacer es proporcionar el contenido del package.json. Entonces va a continuar, nuestra cuenta, nuestra página o nuestro objeto está diciendo cuáles son los detalles de la cuenta que estamos proporcionando con la definición del nombre, apellido y cada uno de estos estamos pasando y estamos diciendo asegúrate de que sea una cadena, asegúrate de que sea una cadena, asegúrate de que sea una cadena excepto en y eliminar los espacios en blanco, pero excepto en layouts. Cuando layout es una nueva variable, no estamos tratando explícitamente de validarla. Y debido a eso, podemos proporcionarle una ruta, como un directorio de archivos. Y lo que está haciendo es ir, Oh, reconozco lo que son estos. Voy a buscar eso desde este archivo aquí. Y está retrocediendo en la cadena de directorios y va a buscar el package.json y lo toma como objeto. Entonces simplemente no asume que es una cadena. Ese es el problema con esto. ¿Eso responde? ¿Está claro? ¿Por qué no lo haría? Bueno, desafortunadamente, es simplemente la naturaleza de cómo funciona JavaScript en el sentido de que no es lo suficientemente inteligente como para. Es el problema de tener un lenguaje de tipos dinámicos. Simplemente toma esto y luego lo ejecuta en función de lo que sabe. Sí. Sí, también puedo compartir esta presentación. Solo haré una copia de ella. Lo que haré, todos los recursos que menciono hoy en términos de y también la aplicación y todas las referencias están en nuestra base de datos y dentro de NPM mismo. Los enviaré a través del canal de Discord para que puedan persistir después de esto, después de que termine la sesión de Zoom. Así que puedes tener esa referencia allí. Y hay un hilo en el interior de este chat dentro de Discord. Genial. En el chat que viene. Si básicamente, no sé. No. La única razón por la que estamos evitando el validador en este caso es porque es una ruta que no se acepta. No se ha encontrado antes. Entonces, lo que sucedería es que si ingresamos más información que solo un montón de espacios en blanco y luego el signo de exclamación al final, y tratamos de ingresar a JavaScript o algo o como SQL, entonces detectaríamos que hay SQL en su interior. Eso se marcaría en el validador. Lo que estamos haciendo en este caso, y lo que estamos haciendo con la función rtrim no es validar si es una cadena o SQL o no. Simplemente está validando, simplemente intenta eliminar los espacios en blanco y ahí es donde estaba el error. Cuando investigamos esto, no hubo ningún problema con el validador real para SQL en este caso, por lo que se marcaría y primero pasaría por el validador de inyección de SQL, y luego pasaría por el validador de espacios en blanco después de eso. Entonces simplemente no se pasaría a la consola.

Ok, hola de nuevo. Esta será la segunda mitad de la masterclass, así que en la primera mitad, solo quería hacer un resumen de lo que hemos hecho hasta ahora. Y en blanco, así que será de memoria. Pero efectivamente, lo que hicimos es hacer una breve introducción sobre el código abierto y la seguridad del código abierto en general y cómo puede causar algunos problemas, especialmente cuando consideramos que todos los hechos que mencionamos sobre cómo las cosas no siempre se mantienen a los más altos estándares donde las cosas han sido abandonadas y la forma en que podrías tener problemas con las dependencias transitivas y cómo las dependencias que se llaman, llaman a otras dependencias, pero no necesariamente tienes mucha visibilidad de ello. Y esto puede ser una amenaza muy real.

Entonces, lo que hicimos en la segunda parte de la primera mitad de la sesión. Lo que hicimos, en primer lugar, fue explorar y explotar algunos fragmentos de código que tenemos dentro de esta aplicación. Uno de ellos fue una inyección de SQL real, que era una vulnerabilidad dentro de la forma en que se diseñó esta aplicación. Pero los otros dos también estaban basados en código abierto. Entonces, lo que vamos a hacer ahora es solucionarlos y mostrarles cómo pueden actualizar las cosas y solucionarlos también. Pero luego vamos a hablar un poco sobre SNK en general, y cómo como plataforma se puede utilizar para ayudar a asegurar tus aplicaciones y tus proyectos.

Para comenzar, vamos a volver a mi aplicación. Y les mostraré rápidamente lo que tengo es este motor aquí, que es ejecutado por SNK. Este es mi complemento de SNK. Y por cierto, recomendaría a todos que lo prueben y lo intenten ustedes mismos. Lo genial de esto es que no necesitas tener una licencia paga para hacerlo. Solo necesitas configurar una cuenta gratuita y luego obtienes 200 pruebas gratuitas al mes. Lo cual es suficiente si lo usas de forma personal, ya sabes, es más que suficiente. Básicamente, puedes configurarlo y ejecutar una prueba rápida y va a escanear no solo mis paquetes de código abierto, sino también mi propio código de aplicación aquí. Entonces, una vulnerabilidad en la que me voy a enfocar es esta aquí. Y esta es una aplicación muy vulnerable. Hay mucho más aquí, a lo que vamos a echar un vistazo. Pero esta es la forma en que realmente hackeamos la aplicación e inyectamos SQL al hacernos pasar por un usuario administrador. Entonces, lo que hicimos es aprovechar el hecho de que esto se está analizando y se da por sentado que es una cadena, un objeto directo, en lugar de validarse como una cadena. Entonces, lo que podemos hacer dentro de esto, y ¿alguien tiene alguna idea de cómo podemos solucionar esto en términos de formato? Está bien. Lo explicaré rápidamente, la gente tarda en escribir, está bien. Es difícil. Tengo uno preescrito, así que me facilita un poco las cosas, básicamente vamos a validar que esto sea en realidad una cadena. Entonces, dentro de este motor aquí, cuando llamamos a esta primera función de este LoginHandler, vamos a crear nuevas variables, este nombre de usuario y contraseña, y básicamente, vamos a ver el inicio de sesión, que es una cadena, y básicamente, forzarlo a convertirse en una cadena. Entonces, al proporcionar esta cadena adicional al final, esta concatenación aquí, y proporcionar una cadena vacía en su interior, JavaScript ahora sabrá automáticamente que esto es ahora una cadena. Bueno, esto es básicamente de tipo cadena, y lo fuerza a ser ese objeto. Entonces, lo que significa es que efectivamente, va a pasar por aquí y aunque fuera un objeto que pasamos en forma de esa vulnerabilidad original, ya sabes, cuando proporcioné una contraseña y dije, esto no es un objeto, y luego mi SQL lo trató como un objeto y luego lo evaluó como longitud. Lo que vamos a hacer es básicamente forzarlo a convertirse en una, si lo guardo rápidamente. Voy a forzarlo a convertirse en una cadena. Entonces ahora SQL tendrá que evaluarlo o JavaScript tendrá que evaluarlo como si fuera una cadena. Oh, lo siento, también olvidé que necesito cambiar esto. Ahora que he creado estas nuevas constantes de nombre de usuario, puedo eliminar eso y ahora también puedo eliminar esto. Ahora también puedo eliminar esto. Y por cierto, simplemente presionaré Control S y va a hacer un nuevo escaneo. Solo toma como 20 o 30 segundos porque es una aplicación bastante simple, pero sigue siendo una herramienta relativamente rápida de usar. Y lo genial que quizás hayas notado justo antes de que desapareciera es que muestra ejemplos de cómo puedes solucionar las cosas. Uno de los ejemplos en los que se basa esta solución es básicamente proporcionar nuevas variables y realizar una conversión a cadena en ellas también, que es efectivamente lo que se está logrando aquí. Entonces, ahora que he guardado esto, esta vulnerabilidad que estaba apareciendo ha desaparecido. Ahora el motor o la herramienta SAS, que estaba usando para encontrar esto ha pasado y me ha mostrado cómo puedo actualizar y solucionarlo basándome en este tipo de método. Ahora, si cierro esto y lo vuelvo a ejecutar, déjame quitar esto de en medio. Y voy a iniciarlo rápidamente en la otra pantalla, solo un segundo. Y... Creo que ahora se está iniciando. Solo para mostrarte que lo reinicié, está ahí. Y ahora lo que haré es intentar iniciar sesión nuevamente usando mi contraseña de objeto.

Permíteme tomar ese comando original que utilicé al principio. Y te mostraré que efectivamente ahora se ha asegurado al hacer este método. Aquí está. Hagámoslo un poco más grande. Y reduzcámoslo bastante, para que sea más legible. Es muy similar a las rutas que hicimos al principio. Dentro de esto, estamos proporcionando un curl post y estamos creando este cookie jar nuevamente. Y dentro de eso, estamos pasando y básicamente proporcionando binarios de datos para este punto final, este punto de inicio de sesión. Aquí tenemos un nombre de usuario que es el que esperamos. Y esto es como el hackeo original que hice al principio que es proporcionar este objeto dentro de él. Entonces, estamos diciendo que debido a que está en este formato básicamente se registra como un objeto originalmente. Y ahora que lo hemos validado y le hemos agregado una cadena al final y lo hemos concatenado, JavaScript ahora lo evaluará como un tipo de cadena lo que significa que ya no puede pasar y ser interpretado por SQL como un objeto por lo que ya no puede tener un enlace mayor que uno y, por lo tanto, no será verdadero cuando evaluemos este enlace. Entonces, en este caso, ahora ha vuelto y me ha proporcionado un 401 y está diciendo que obviamente ya no es accesible. Se está denegando. Entonces, esa es una forma de evaluarlo y esa es una forma en la que puedes solucionarlo utilizando esta herramienta SAS que te muestra dónde está. Bueno, obviamente hay otras formas de ver información al respecto pero efectivamente, en términos de asegurar como el proceso que he realizado hasta ahora al evitar que obtenga acceso de administrador he prevenido muchas vulnerabilidades pero también puedes obtener información sobre tus vulnerabilidades de código abierto también. Entonces, si sigo adelante y lo reviso en esa base de datos que mostré antes y vuelvo a npm y marked puedes ver que la versión de marked que necesitas para solucionar algo. Entonces, porque tenemos, permíteme abrir mi package.json y volvamos a mis archivos, solo un segundo. ¿Dónde está? Sí. Y luego encontremos dónde está validator. Sí, podemos encontrar la versión de validator que estamos solicitando. Y también podemos encontrar la versión de marked, que está aquí. Y también puedes ver que sneak también me está mostrando que tengo 11 tipos diferentes de vulnerabilidades asociadas con este paquete también. Entonces, lo que haría ahora que he encontrado esto y sé que esto es vulnerable, básicamente puedo llamar a una versión corregida de esto. Entonces, podría ir hasta la versión seis ahora y luego lo ejecutaré rápidamente en un segundo. Y luego también el otro, que era para validator. Creo que la versión más reciente es la que lo tiene corregido. Así que lo revisaré rápidamente. Entonces, es la versión, es esta denegación de servicio. Esta es la vulnerabilidad que se encontró con rtrim. También hay otra vulnerabilidad, que no he revisado antes, pero es un proceso muy similar, pero es con isslug. Entonces, está validando cuando proporcionamos una URL para validar, esto tiene que ver con, cuando pasamos y creamos una página, básicamente asegurándonos de que esté en el formato correcto y sea fácilmente legible para el ojo humano. Pero efectivamente, fue un problema muy similar dentro de la forma de un redos. Entonces, simplemente estaba causando tiempos de espera con ese método de evaluar la cadena generada allí. Entonces, lo que puedo hacer es, efectivamente, puedo actualizar y ser explícito con una versión que data desea. Y puedo decir, en lugar de permitir la conversión a 13.5 y superior, puedo decir que solo quiero 13.7 exactamente, o puedo decir 13.7 y superior. Y hay un argumento para tener tanto tipos duros como versiones dinámicas o versiones dinámicas permitidas. Eso es lo que significa este pequeño sombrero, obviamente, está diciendo las versiones que estoy permitiendo y superiores. Entonces, si tuviera otra versión que se llamara allí, que NPM considerara una versión válida o que quieran admitir para obtener una versión diferente allí, entonces veo que hay una pregunta. Oh, lo siento, acabo de ver que era tuya, Chris. Efectivamente, esta podría ser una forma en la que puedo comenzar a asegurar las cosas. Entonces, lo que puedo hacer, si guardo esto ahora, necesito salir de mi aplicación nuevamente. Simplemente terminemos eso y reiniciémoslo. Y luego navegaré rápidamente por mi directorio de pantalla, solo un segundo. Y luego esto es, aquí está mi... Entonces, lo que voy a hacer es reconstruir los nodos o mi package.json, voy a ejecutar como un NPM install antes de iniciar realmente el servicio. Y lo que esto hará es actualizar los paquetes instalados en función de mis cambios aquí. Y luego todo lo que puedo hacer es iniciar el servicio nuevamente utilizando estas nuevas versiones. Y puedo mostrarte que esto se está solucionando en este caso. Entonces, si ejecuto eso, lo ejecutaré rápidamente.

Y estaba explotando Validator, que es diferente a lo que obtenemos en NPM. Sí. Permíteme mostrarte rápidamente cómo se ve eso. Esto es una ejecución completa de sneak test. Y puedes ver que al ejecutar, literalmente solo ejecuté NPM install. Creo que todavía tengo visibilidad un poco más arriba. Y puedes ver que obtengo información sobre 76 vulnerabilidades, dos de baja gravedad, 15 de gravedad media, 43 de alta gravedad. En total, 73. Solo un vistazo rápido, no entraremos en demasiadas diferencias aquí porque no quiero que sea una exhaustiva comparación entre nosotros y la auditoría de NPM. Pero efectivamente, sneak tiene su propia base de datos, que mantiene de diferentes vulnerabilidades. Y descubrirás que puede ser mucho más detallado en cuanto a los tipos de vulnerabilidades que encontramos. Y la razón de esto es porque sneak es muy bueno en básicamente descubrir dependencias de tránsito y cosas que estás importando. Entonces puedes ver aquí que en comparación con la auditoría de NPM. que encuentra 76 problemas, esto encuentra 105, por lo que puede ser mucho más detallado en cuanto a los detalles. Así que sí, continuaré con eso. ¿Qué iba a mostrarte? Iba a mostrarte que validator y marked pueden ser solucionados ahora.

Entonces, para explotar validator, lo que estaba haciendo era pasar información a través de una redirección, lo siento, para activar un Redos. Entonces, si vuelvo atrás e intento ingresar, en realidad no podré hacerlo ahora porque necesito iniciar sesión rápidamente como administrador. Así que dame un segundo. Como hemos solucionado el problema donde la inyección SQL no funciona, ahora necesito ingresar la contraseña correcta en lugar de ingresarla como un objeto. Y ahora que lo he hecho, puedo ingresar algo en el arquero que en este caso fue ingresar en los detalles de la cuenta, ingresar básicamente una serie extremadamente larga de espacios en blanco seguidos de un signo de exclamación en ese caso. Y puedes ver que se ejecutó instantáneamente. Así que no hay demora esta vez, no hay demora ni nada, son como 21 milisegundos. Así que literalmente entre esas dos versiones, básicamente actualizaron su regex para poder manejar esta situación. Ya no puedes seguir tirando de esto y causar un cascada infinita de retroceso y hacer que un servicio se caiga y ahora es muy rápido. Y luego el otro tipo de vulnerabilidad estaba dentro de mocked. Entonces, si vuelvo a mocked y tuvimos una instancia donde pudimos crear una alerta o ejecutar algún tipo de scripting de sitios cruzados actualizando esa versión. Básicamente hemos evitado que se encuentre eso. Entonces, si proporcionamos la misma información aquí, déjame pegar. Así que equiparemos este runback, así es como se veía. Puedes ver que estábamos ingresando en este término JavaScript y luego lo ingresamos en este término. Se encontró que esto se estaba referenciando y luego se pudo decir, en realidad esto no es válido en cuanto a JavaScript válido. Entonces no se podía ingresar en cierto tipo de grupo. Y luego mocked básicamente permitía que eso pasara y asumía que era seguro hacerlo como una cadena. Nuestro navegador básicamente lo recogía y veía que estaba allí y decía, ah, eso está obviamente mal, JavaScript está ahí, sé qué hacer con eso. Y los pasaba como un script ejecutable. Pero porque actualizaron marked ahora dentro de esta versión, ahora eso realmente se ha pasado como algo que no puede pasar por el validador porque hicieron un cambio dentro de esa versión. Entonces, esas son las formas en que puedes solucionar estas explotaciones. Una de ellas venía de nuestro propio motor. Entonces venía de mi propia aplicación, lo siento. Y básicamente lo actualicé aquí dentro. Y los otros dos componentes se trajeron a través de paquetes de código abierto. Y obviamente esos se han actualizado ahora, así que eso es genial. La pregunta es, obviamente, como, en este caso, sabía exactamente a qué versiones ir porque sabía qué tipo de vulnerabilidades tenía dentro de ellas. Pero la realidad es que ustedes no podrán realizar un seguimiento de todas las dependencias diferentes y todos los diferentes tipos de vulnerabilidades que tienen con sus dependencias. Y esto fue en mi caso, por ejemplo, y actualizando cosas, todas estas eran dependencias indirectas también. Aquí es donde se encuentra la vulnerabilidad. En lugar de cualquier dependencia transitoria que se haya traído necesariamente. Entonces la pregunta es, ¿cómo asegurarse y evitar ser vulnerable a esas cosas? Y la respuesta es usar una herramienta como Sneak, donde podemos básicamente buscar dependencias indirectas. Así que lo mostré allí en términos de cómo funciona la prueba de Sneak. Lo que también puedes hacer dentro de esto es ejecutar un comando de monitoreo. Entonces, el comando de prueba, que acabo de hacer, vendrá y creo que probablemente debería cerrar esto porque va a consumir CPU innecesaria pero continúa de todos modos, pasará por y me mostrará todos mis diferentes tipos de vulnerabilidades y cómo puedo solucionar las cosas. Si ejecuto un comando de monitoreo, esta es la misma respuesta exacta en términos del contenido principal, que acabo de recibir pero lo enviará a la interfaz gráfica de Sneak o a nuestro sitio web. Y cuando veas esto, es como una interfaz muy fácil de usar, permíteme mostrarte cómo se ve. Entonces, si voy y voy a esto, esta es una instancia guardada de esa exploración que acabo de hacer y puedes ver que ya se exploró hace unos segundos y me muestra cómo fueron los resultados de mi exploración, pero en términos de esta interfaz. Entonces, lo que puedo hacer con esta interfaz es ver de manera gráfica de dónde provienen mis dependencias transitorias. Y esta es una perspectiva realmente valiosa para comprender dónde están tus riesgos y comprender qué cosas están llegando. Entonces puedo ver en este caso, todas las dependencias transitorias que tengo y cuáles no tienen vulnerabilidades. Y luego, básicamente, vamos un paso más allá en términos de decirte qué puedes hacer al respecto. Entonces, lo que muchas herramientas hacen es básicamente decirte que tienes una dependencia transitoria como Negotiator en este caso que tiene una vulnerabilidad. Y esta vulnerabilidad, que tiene, puede tener una versión corregida. Entonces podría ir a la versión siete o algo así y corregir Negotiator en ella. Pero el problema entonces, es que en realidad no estás llamando a Negotiator tú mismo, estás llamando a algo como Excepts. Y lo siento, estás llamando a Express, que llama a Accepts, que llama a Negotiator. Entonces, la parte difícil y en lo que Sneak ayuda en este caso es básicamente te diremos la versión de Express a la que debes ir, que llama a la versión más alta de Accepts, que llama a la versión corregida exacta de Negotiator y lo valida por ti. Entonces, si echamos un vistazo dentro de esto, veremos que Express era la versión original de Express que estaba llamando y estaba llamando a esta versión de Negotiator.

La versión corregida de Negotiator es 0.61. Y luego la versión exacta de Express que se llama en esta versión corregida es 4.14. Y eso básicamente entra en cómo podría afectar y reducir las vulnerabilidades dentro de mi aplicación. Otra cosa que hacemos, que es realmente genial, es proporcionarte contexto para cuando las cosas son explotables. Esto significa básicamente lo que he mostrado hoy en términos de una explotación de principio a fin. Básicamente podemos, y si echas un vistazo al README de esta aplicación, recorremos y explotamos cada una de estas vulnerabilidades si las recorro así. Y también podemos mostrarte cómo solucionarlas. Por ejemplo, AMD zip, que tiene una traversía de directorio o una traversía de ruta que hemos visto hoy. Esta es una, y es una traversía de zip muy famosa también conocida como, pero puedes ver en nuestro sitio web y tenemos una información muy completa sobre cómo funciona esto y cómo se puede explotar. Y lo que me gusta de esto es que también te proporciona enlaces directos a donde puedes encontrar como donde han ocurrido las conversaciones sobre esto. Así puedes hablar de ello o compartirlo entre tus compañeros para obtener más información sobre cómo funciona realmente la traversía de zip. Y esto es algo que está impulsado por Snyk. Así que te guiará a través de lo que es la traversía de zip y cómo se puede explotar, pero si volvemos a esto, puedes ver que tenemos esta puntuación de prioridad y esto básicamente te proporciona información basada no solo en un CVSS que es algo muy estándar. Entonces, eso es cómo las herramientas normales básicamente califican entre crítico, alto, medio y bajo. Y somos un sistema de puntuación CVSS acreditado u organización de puntuación. Entonces, cuando nuestros expertos en security encuentran una vulnerabilidad podemos darle su propia puntuación basada en cómo la calificamos. Pero lo que hacemos antes de ingresarla en nuestra database, es ver si una vulnerabilidad tiene un exploit real en ella. Y esto significa básicamente una vulnerabilidad madura o un exploit maduro. Básicamente tenemos evidencia documentada de que un atacante lo ha utilizado maliciosamente en este paquete en particular. Así que sabemos que esto es realmente vulnerable. Y luego un proof of concept es básicamente cuando hay un documento técnico asociado con aunque alguien no lo esté explotando en un entorno en vivo, tenemos un documento técnico que muestra cómo se puede explotar de principio a fin. Entonces, con estas dos métricas obtienes una medida ideal del riesgo asociado con ello. Obtienes una medida de la gravedad con un CVSS, y también obtienes una medida de lo fácil que es solucionar algo basado en si algo tiene una solución. Esa es probablemente la forma más fácil de usar Snyk en este momento, especialmente si no tienes una cuenta adecuada o una membresía de pago, efectivamente cualquier proyecto en el que estés trabajando, simplemente puedes ir a tu directorio, instalar Snyk. Y aquí es donde debes tener NPM instalado o puedes instalarlo mediante binarios y simplemente ejecutar este NPM I-G Snyk. O lo que puedes hacer es instalarlo como una extensión en Visual Studio. Así que puedo ir a mis extensiones y simplemente escribir Snyk y será el primer resultado que encuentres y luego simplemente puedes instalarlo. Y luego puedes escanear cosas en tu entorno de trabajo y escanear cosas así.

¿Alguien tiene alguna pregunta sobre el uso de Snyk? ¿Tienen ingenieros que lo buscan activamente en su Edge Once? Sí, lo tenemos. Entonces, dos cosas, Stuart. Tenemos ingenieros que utilizan nuestro motor SAS. Este motor que analiza el propio código fuente. Y escaneamos miles de proyectos a tiempo incluyendo proyectos de código abierto y proyectos privados pero también proyectos que quizás no te des cuenta que podrían ser vulnerables en la tienda de aplicaciones, por ejemplo. Y publicamos actualizaciones sobre... Actualizamos nuestra database a diario y también, ya sabes, actualizamos a los mantenedores de esos proyectos para informarles al respecto. Y sí, puede que tenga Jack, filtrado de IntelliJ back send. Sí, también tenemos soporte para IntelliJ y el resto de las herramientas de JetBrain. Otra cosa que hacemos, si vuelvo rápidamente a mis diapositivas, es que también publicamos blogs. Así que echemos un vistazo rápido a eso. Dame un segundo ahora. Y básicamente estos son blogs de nuestros ingenieros de security. A medida que encuentran cosas, hacen blogs y puedes suscribirte a esto como un boletín de correo electrónico. Pero voy a echar un vistazo rápido al lado de la aplicación, la security de la aplicación. Y estos serán básicamente nuevos temas candentes a medida que van surgiendo. Es una forma muy fácil y digerible de mantenerse al tanto de lo más nuevo en la industria en términos de nuevas amenazas de security a medida que las encontramos. Tenemos cosas, artículos sobre ransomware y cosas así, donde por ejemplo, se encuentran nuevas vulnerabilidades debido a la guerra en Ucrania donde las personas están haciendo sus aplicaciones maliciosas a propósito para las personas que las instalaron y están dentro de una geolocalización de Rusia. Entonces, entran y actualizan sus propios paquetes y dicen, si estás en Rusia, borra todos los archivos de tu computadora y cosas así. Básicamente, nos mantenemos al tanto de todo lo que está sucediendo desde un panorama político así como nuevas vulnerabilidades que se encuentran. Si Express no ha tenido una versión de la dependencia de tránsito corregida, ¿recomiendan usar la resolución modular? No. Evitamos explícitamente la resolución modular.

Para NPM exclusivamente, lo que hacemos es ofrecer parches donde vamos y proporcionamos soluciones rápidas para esa vulnerabilidad en particular. Entonces, lo que hará es, no va a revisar y decir, digamos por ejemplo, si es un problema transitorio, proporcionaríamos un parche dentro del problema transitorio. Permíteme volver a una ayuda visual. El parche estaría aquí, el parche estaría dentro de mi en ese caso, si hubiera una vulnerabilidad dentro de él y hubiera una dependencia transitoria que tuviera un problema, no sería un caso de usar modules para vincular la versión de Express, sería una actualización a la versión de mi que estás usando directamente para básicamente tener la solución involucrada en ella, hemos lanzado bastantes parches, pero en última instancia no es realmente como, es más bien una solución temporal porque obviamente pierdes muchas de las funcionalidades principales cuando te quedas en un punto en el tiempo como una versión de parche de mi y no pasas a las versiones posteriores. Entonces, lo que haremos es que podemos parchearlo por ti y luego bien, tienes un módulo de parche, efectivamente sí. Permíteme mostrarte cómo se ven realmente los parches. Así que podemos abrir esto. No sé si tengo un ejemplo real donde se apliquen parches. Parcialmente reparable, ¿se puede solucionar con un parche o se puede parchear esto? No tenemos un parche para este. No creo que tenga un ejemplo para ti. Lo que haré es comunicarme en el hilo de Discord para esto. Enviarte un ejemplo. Te enviaré, sí, tengo un parche en este ejemplo en particular. Te enviaré nuestra documentación sobre cómo funciona nuestro sistema de parches, si eso te sería útil. Pero sí. ¿Hay alguna otra pregunta sobre cómo funciona en la práctica? De lo contrario, puedo hablar un poco sobre cómo asegurar el entorno en cuanto al proceso holístico en general.

De acuerdo. Continuaré un poco sobre todo el entorno en términos de lo que hemos visto hasta ahora desde una perspectiva general. Hasta ahora, hemos estado trabajando a nivel local y escaneando cosas en el IDE y en mi terminal. Pero lo que realmente puedes hacer es integrar Snyk en tu repositorio Git. Si estás utilizando cosas como GitHub, puedes integrarlo en él. Y una vez que lo hayas hecho, lo que hará es monitorear las ramas dentro de él. Y si voy aquí, puedo mostrarte. Básicamente puedo monitorear diferentes ramas. En este caso, es una rama de características, pero puedo tener una rama de desarrollador, por ejemplo. Y luego, dentro de esas ramas, cada vez que haga una solicitud de extracción. Así que digamos que intento cambiar algo, al comienzo del día, termino de escribir código y luego lo subo con Git push. Básicamente, lo que sucederá es que al hacer ese cambio, se realizará un escaneo basado en las diferencias entre el inicio del día cuando saqué el código y el final del día, cuando estoy subiendo el código, básicamente hará un delta y descubrirá cuáles son las diferencias técnicas desde una perspectiva de security entre la versión A y la versión B. Y te permite, básicamente, mirar rápidamente tu día y comprender qué es lo que has introducido desde una perspectiva de security para que puedas solucionarlo. Y podemos mostrarte ejemplos exactos de cómo puedes solucionarlo, en este caso, utilizando un método de dos cadenas en lugar de proporcionarlo como una variable estándar. Entonces, esa es una forma en la que puedes comenzar a utilizar Snyk de manera integrada.

Y luego, lo otro que puedes hacer es integrarlo también en tus pipelines. Así que dentro de cosas como pipelines de GitHub o volviendo a la historia dentro de Jenkins, TeamCity, cualquier cosa que realmente uses para pipelines, básicamente puedes instalar la herramienta SneakCLI para pipelines esta herramienta aquí, que acabo de instalar dentro de ella y ejecutando los comandos de prueba y monitoreo de Sneak básicamente puedes romper las compilaciones basándote en la definición de lo que encontramos dentro de ellas.

Entonces, lo que podrías hacer es decir quiero romper una compilación basándome en algo que tenga una vulnerabilidad de alta gravedad dentro de ella. Entonces, lo que eso prácticamente termina pareciendo e incluso podemos hacerlo basado en una vulnerabilidad crítica es que significa que cualquier cambio que subas a tu plataforma no tenga ningún tipo de gravedad crítica dentro de ellos. Así que quieres asegurarte de no ingresar cosas en tu sistema que tengan problemas críticos dentro de ellos. Y puedes ser muy detallado con cómo funciona esto. Entonces, lo que puedes hacer es ingresar filtros, voy a obtener rápidamente un filtro mientras tanto solo para mostrarte cómo se ve eso.

Solo un segundo. Creo que eso es todo. Sí, este es mi filtro. Solo voy a hacer una prueba de Sneak. Y lo que hago entonces es pasarlo a un JSON y luego lo ingreso en otra herramienta que aloja GitHub. Es una herramienta de código abierto que mantenemos llamada un filtro de Sneak. Y lo que hace es pasar el formato JSON con el filtro JQ y luego empujar eso a un filtro que he definido dentro de este directorio. Entonces, lo que puedo hacer es asignar este archivo ya sea como una variable global accesible a través de mi pipeline o puedo asignar esto y guardar este archivo dentro de mis proyectos mismos. Entonces puedo especificar diferentes filtros basados en ellos. Lo que este filtro logra en mi caso es hacer el mismo filtro que estaba mostrando en nuestra interfaz gráfica donde estaba filtrando cosas basado en lo que era reparable y si las cosas tienen un exploit maduro o una prueba de concepto y si las cosas son críticas y tienen problemas de alta gravedad. Entonces, en lugar de romper una compilación basada en 105 problemas diferentes que te impiden trabajar realmente y te obligan a volver y solucionar cosas durante el resto del día, efectivamente solo romperías la compilación en cosas que puedes a, solucionar de manera rápida y fácil y b, cosas que son explotables que tienen un nivel severo de riesgo asociado con ellas y también tienen un alto nivel de gravedad. Ahora que ha hecho eso, efectivamente puedes ver que estas son las vulnerabilidades por las que rompería una compilación y básicamente luego de eso puedes ejecutar un comando de monitoreo y descubrir cómo puedes solucionar estas cosas. Te muestra dónde en la ruta estas dependencias deben ir, estas dependencias están desactualizadas, tengo una dependencia histórica, ¿de acuerdo? Básicamente me dice cómo puedo solucionar esto a medida que avanzo con eso. Y esto es algo que puedes poner dentro de tus pipelines, y en última instancia, así es como puedes asegurar todo el ciclo de vida del desarrollo de software. La idea es que en lugar de usarlo solo como una puerta de seguridad y básicamente ralentizarte en el momento de entregar cosas, lo que deberías hacer es básicamente usar una herramienta como esta desde el principio de construir algo. Digamos, por ejemplo, quiero ver si puedo instalar la versión más reciente de Express, ¿verdad? Entonces lo que puedo hacer es, puedo ejecutar un comando de prueba de Sneak, y tal vez no Express, pero cualquier tipo de biblioteca de código abierto que voy a usar, que comencé desde cero con un nuevo proyecto. Digamos que no estoy familiarizado con eso, y creo que necesito lograr esto dentro de mi proyecto, voy a buscar la mejor biblioteca que pueda ayudarme a lograr eso. Y lo que haré es en realidad hacer una prueba de esas. Entonces, digamos, por ejemplo, pruebo colors. Lo que sucederá entonces es que puedo hacer una prueba de Sneak, y encontrará la última versión de colors dentro de eso. Y volverá, y me mostrará, veamos, Ruta del proyecto Colors. En realidad, no, espera, no. Reabrir eso. Cerrar eso. No creo que haya encontrado la versión de colors en el Tracker. De acuerdo, sí. Entonces lo registró como un elemento empaquetado. No. Es posible que deba especificar la versión exacta. Permíteme encontrar rápidamente una versión de colors. Vamos a la versión. Vamos a la versión anterior, así que hagamos la versión 1.4. Hagamos un sneak alrededor. Así que escríbelo, disculpa por esto. Intentemos esto. Genial, parece que no encuentra ese paquete en particular. Efectivamente, lo que deberías poder hacer es antes de comenzar a usar un paquete de código abierto, deberías poder probarlo, y desde allí básicamente tener una idea de cómo se ve desde una perspectiva de código abierto, si quieres usarlo o no. El motor no lo está ejecutando, pero lo que puedes hacer es usar nuestra base de datos. Así que vamos a ir a la base de datos y vamos aquí. Y luego buscaré colors rápidamente. Entonces, quiero decir, ayuda si especificas versiones con eso, pero este es un ejemplo de un ataque de denegación de servicio que ocurrió en cualquier versión anterior a 1.4.0. Entonces sabrías las versiones de colors que deberías comenzar a usar en su lugar. Y el otro recurso que quería señalarte es el Asesor de Sneak.

Entonces, esto es completamente, por cierto, la database en términos de acceder a esto, es completamente gratuito hacerlo. Y lo mismo ocurre con el Asesor. Así que si continuamos y miramos esto y escribo colors en este caso, busco npm, y luego lo que puedes ver es colors aquí, en realidad tenemos la capacidad de evaluar esto también. Entonces puedes ver de antemano qué tipo de paquetes te estás comprometiendo, y puedes ver versiones alternativas de paquetes que podrías querer usar en su lugar. La idea detrás de esto es que te da una idea de las bibliotecas a las que te estás comprometiendo antes de comenzar a hacerlo realmente. Porque si voy a comenzar a construir cualquier tipo de aplicación que se base en este recurso, entonces voy a comenzar a usar métodos y argumentos en los que se basa. Y si luego descubro en un par de meses que hay una vulnerabilidad en él, y estos chicos no son muy buenos en términos de frecuencia de lanzamiento y mantenimiento y lanzamiento de nuevas actualizaciones, entonces será un problema porque efectivamente, no hay garantía de que estas personas aún estén activas, podrían no estar actualizando vulnerabilidades y solucionando errores. Entonces, lo que podrías terminar haciendo es tener que eliminar esto y reemplazarlo por un paquete similar para lograr la misma funcionalidad. Entonces, aunque esto es algo que te puede resultar familiar, como usar colors en este caso, lo que podrías terminar haciendo es eliminarlo, por lo que podrías hacer eso de todos modos y optar por un paquete más sostenible y con una mejor cobertura general. Por ejemplo, te recomendaría usar Chalk. Esto es algo que surgió bastante recientemente. Entonces, si vas a Chalk, que tiene una puntuación de salud muy buena, logra básicamente lo mismo en términos de la funcionalidad principal detrás de él, pero tiene muchos compromisos recientes y también tiene una community más amplia y también está financiado. Por lo tanto, hay una práctica sostenible real en mente al usar esto porque tiene muchos colaboradores. Estos colaboradores son compensados por su tiempo en mantener esto actualizado. Por eso se recomienda básicamente como un paquete muy saludable para usar también. Otra cosa que puedes hacer es verificar cuáles de estos lo son. Sigamos adelante y busquemos un archivo JSON de paquete, cuáles de estos se recomiendan como no saludables o no recomendables.

¿Hay alguna pregunta, por cierto? Veo que me he perdido el chat por un momento. Permíteme echar un vistazo rápido, ¿por qué no se está cargando esto? Solo esperaré un segundo a que se cargue. Y revisaré el chat en busca de soluciones.

¿Las herramientas de línea de comandos están vinculadas al panel de control? Sí, lo están. Sí, absolutamente. Entonces, si ignoras algo, es agnóstico, y podemos profundizar en eso un poco más en un momento. Pero sí, puedes probar cosas y será consistente.

El Asesor de Sneak es muy bueno, especialmente puede ser útil usarlo cuando tienes casos de uso en la biblioteca, sí. ¿Sneak tiene paquetes similares? Mejor puntuación de salud. Sí, los tiene. Esto es lo que quería mostrarte en cuanto a cómo funciona el Asesor. Esto está dentro de IntelliJ, y esto es algo que está solo dentro de IntelliJ en este momento. Estamos planeando lanzarlo en el resto de los IDE, pero actualmente es solo una función beta.

Sí, lo tenemos. Principalmente enfocado en JavaScript debido al evento que estamos realizando hoy, pero tenemos un muy buen soporte para cosas como Java, Python, Go, C-Sharp. ¿Qué otros lenguajes importantes hay, como Ruby, supongo? Efectivamente, muchos lenguajes. Tenemos una lista más larga de los lenguajes que admitimos que de los que no admitimos. Entonces, si tienes alguna pregunta específica, Stuart, házmelas saber, y luego podemos abordar qué tan bueno es el soporte para ellos. Pero sí, tenemos mucho soporte para diferentes lenguajes.

Pero aquí dentro, puedes ver, por ejemplo, que me dará consejos basados en este puntaje del Asesor de Sneak, y esto lo ha abierto aquí al costado, y esto me mostrará, básicamente, cómo se compara esto con otras cosas. Esta comunidad y este mantenimiento no están gestionados en absoluto, por lo que podría ser una buena idea usar paquetes alternativos en su lugar, y debería darme ejemplos de diferentes tipos de paquetes que podría usar. No estoy seguro de por qué no los muestra pero, efectivamente, sabrías a partir de esto que tendrías que pasar por y cambiar una versión de Code Roku.

En realidad, no existe tal cosa como una, sí, puedes tener parches, especialmente si es un proyecto abandonado. Ahí es cuando generalmente intervenimos para parchear las cosas. Pero en realidad, la mayoría de las cosas no tendrán parches debido a la escala en la que se adopta el código abierto y las formas en que estos paquetes se vuelven abandonados a una tasa bastante exhaustiva como hemos visto. Entonces, la realidad es que no existe tal cosa como una aplicación completamente segura. Y cómo se maneja eso en términos de cómo lidiar con eso es efectivamente tener algún tipo de proceso de triaje y no hay una solución única para todos y debería ser algo que ustedes aborden continuamente y verifiquen continuamente ustedes mismos.

Pero por ejemplo, si encontrara, digamos algo que no se puede solucionar y lo reviso y veo algo como esta contaminación del prototipo aquí, entonces, lo otro que vale la pena mencionar es que tenemos un curso en línea sobre lo que puedes comenzar a aprender hoy sobre vulnerabilidades específicas. Así que tenemos esta herramienta llamada Sneak Learn y está vinculada a nuestra plataforma y si encontramos una vulnerabilidad sobre la cual tenemos una lección, entonces puedes abrirla directamente y obtener una lección. Es un entorno virtual donde puedes probar cosas e intentar romper cosas y comprender cómo se explota en realidad y te mostrará la definición de ello en detalle.

Pero también hay ejemplos donde la realidad es que es posible que nunca haya una solución para esto. Y la razón de esto es porque estos paquetes podrían no estar siendo mantenidos o simplemente es una vulnerabilidad muy nueva a la cual las personas aún no han tenido la oportunidad de abordar. Y la realidad es que tendrás que pasar por y evaluarlo tú mismo y formarte tu propia opinión al respecto. Entonces, lo que podrías hacer es que tenemos mucha información sobre este tipo de vulnerabilidades en nuestra biografía de información. Te mostrará el tipo de vulnerabilidad asociada con ella, cómo puedes explotarla tú mismo y cómo puedes hacer una prueba de concepto en tu propio entorno. Entonces, la realidad es que probablemente deberías realizar una especie de prueba de penetración para ver si puedes explotarla tú mismo y comprender qué tan vulnerable es para ti. Puede ser que en este caso particular, puedas ver el método que se ha llamado set value. El paquete que crea valores anidados e interpreta cualquier intermediario utilizando protección de punto. De acuerdo, genial. Entonces, la forma en que esto funciona es cuando se utilizan claves proporcionadas por el usuario en los arreglos de parámetros de ruta. De acuerdo, genial. Entonces, lo que podrías hacer es efectivamente pasar por y asegurarte de que el objeto en sí no sea susceptible a la contaminación. Y lo que quiero decir con esto es que esto es algo específico de la contaminación del prototipo como ejemplo. Pero la forma en que funciona la contaminación del prototipo es efectivamente que está poblado por un objeto en el que puedo ingresar y cambiar la definición de su prototipo. Por lo tanto, solo se explota realmente a través de cierto conjunto de métodos. Y estos métodos se consideran como agregar métodos inseguros para hacer. Y generalmente están relacionados con medidas recursivas. Entonces, como en este caso, es una medida recursiva que este que el valor establecido básicamente ejecuta la lógica en la que se encuentra la propia aplicación principal y por qué es vulnerable y por qué no hay una solución es simplemente porque se está utilizando un método muy inseguro para fusionar cosas de manera recursiva. Esa es simplemente su naturaleza y es vulnerable a y simplemente es vulnerable a la contaminación del prototipo debido a las formas en que la medida recursiva realmente funciona dentro de JavaScript.

La razón de esto si puedes revisar y ver este contenido o verlo en términos de la lección de Sneak Learn, si quieres aprender un poco más sobre esto y cómo se puede explotar. Pero al final del día, esto es algo sobre lo que tienes control directo porque al final del día estás escribiendo estas aplicaciones. Es posible que estés usando los métodos que se llaman pero lo que puedes hacer es revisar y cuando los estés referenciando puedes controlar los parámetros en los que pueden ser explotados. Entonces, lo que puedes hacer es entrar en ello y te mostraremos las diferentes formas en las que este tipo de ataques pueden ocurrir.

Así que la ejecución remota y la inyección de denegación de servicio. La denegación de servicio, puedes hacer algo como sobrescribir el método two string o value, que son funciones extremadamente populares de un objeto y al sobrescribir estas cosas casi con seguridad romperás una aplicación al eliminar las propiedades de un objeto porque cada vez que llames a un objeto y luego intentes convertirlo en una cadena o convertirlo en un valor, simplemente fallará y romperá la aplicación. No funcionará como se esperaba. Podrías hacer una ejecución remota de código al definir el prototipo de un objeto. La forma en que se compone el objeto es básicamente inyectar algo que deseas inyectar en él. Entonces puedes ingresar a esta otra clase de operaciones dentro de él. Y cuando se instancia el objeto, también instancia su propio código. Y hay otras cosas que puedes hacer con él en términos de propiedad. Esto es simplemente asignar variables para asignarle permisos, que luego se utilizan más adelante. Quiero decir, esto es realmente relevante en la situación en la que sabes cómo se están ejecutando estas variables. Si esto nunca se llama, entonces no es realmente un problema y no has obtenido la convención de nombres correcta. Entonces podrías inyectar un ISAdmin, pero si no lo evalúas contra ISAdmin para obtener permisos, no importa realmente. Pero la forma en que puedes manejar esto es básicamente congelando el objeto. Entonces, cuando lo creas y fusionas recursivamente un objeto. Entonces, la función en última instancia, para lo que estás usando esto, este set value, cuando comienzas a hacer esto, básicamente congelas el objeto en ese momento y específicamente congelas este prototipo de objeto. Y al hacerlo, esta fusión recursiva, todo este problema del que he estado hablando, ya no es relevante porque simplemente no permite ningún tipo de cambio aunque la función siga funcionando. Entonces tienes que triar las cosas una por una, desafortunadamente no hay una solución única para todo tipo de vulnerabilidades, pero lo que puedes hacer es agregar el contexto del triaje que has hecho y simplemente agregarlo al contenido sin procesar. Entonces, en este caso, podría decir que no es vulnerable porque cuando estoy usando set value y podría nombrar las formas en las que lo estoy llamando así que podría estar llamando a set value, algo así y nombrar el objeto y los parámetros que se le pasan. Y luego usar algo como object.3 también. Con eso puedo estar seguro de que en realidad no estoy expuesto a ningún tipo de contaminación del prototipo. Pero agregar este contexto de los tres pasos que estás haciendo para triar algo y decir si es vulnerable o no es efectivamente el proceso. No es como si no se pudiera solucionar todo pero son los pasos que se toman para solucionar las cosas y asegurarse de que no sean vulnerables. Entonces, si guardas esto, aparecerá en tus informes y esperaremos hasta que se cargue y echemos un vistazo a los ignorados. Sí, aparecerá y me mostrará las diferentes formas en las que esto ha sido básicamente, he ignorado un par de ellos en el prototipo porque no es algo que esté cambiando para cosas como esa, pero efectivamente puedes agregar el contexto de por qué estás congelando las cosas o por qué estás diciendo que no es vulnerable y al hacerlo no aparecerá eso es básicamente una respuesta muy larga de decir, ¿qué sucederá si las cosas no se pueden solucionar? La respuesta es que simplemente tienes que aguantar entender el contexto de lo que realmente se muestra como vulnerable y luego evaluar si es una amenaza en tu caso o no. Puede ser una amenaza, puede ser que no haya nada que puedas hacer al respecto desde una perspectiva del usuario y la realidad es que simplemente debes pasar a un paquete de código abierto más seguro y mejor mantenido que pueda abordar eso. Pero sí, la respuesta no es realmente tan simple, desafortunadamente, pero este es el proceso que necesitarías seguir para llevarlo a cabo y así es como puedes hacerlo con estas herramientas. ¿Tuvo sentido eso? Puede que me haya excedido un poco en el tema específico. Sí, gracias. Genial. ¿Alguien más tiene alguna otra pregunta específica? Sí, gracias. Sí, Peter, en términos del ejemplo de colors a chalk. Sí, ese fue el ejemplo en el que también estaba pensando cuando Node era vulnerable, solo la versión de Node era vulnerable a la denegación de servicio. Terminé siendo afectado por eso durante todo un fin de semana, no fue divertido, pero si vuelvo a Pfizer, echaré un vistazo rápido a colors, creo que era otros colores o colors.js. Espera a que aparezca esto, y luego puedes ver diferentes tipos de paquetes a los que puedes recurrir en su lugar. Entonces, en este caso tiene un colors.js, podría ir a chalk en este caso, y luego usarlo como método para encontrar qué tipo de paquetes hacen cosas muy similares pero son mucho más seguros. Así que eso es un rápido intercambio. De acuerdo, genial. Creo que eso es todo lo que tenemos tiempo. También quiero mencionar rápidamente algunas otras cosas, recursos que tengo aquí. Ya he hablado de la base de datos de Snyk, Snyk Learns, Snyk Advisor. Lo otro que vale la pena mirar es esta hoja de trucos que se adentra específicamente en NPM para que puedas echar un vistazo y comprender algunas formas en las que puedes comenzar a trabajar con las cosas desde las mejores prácticas. Sí, muchas gracias por su tiempo y por su atención, sí.