Cómo Explotar Vulnerabilidades del Mundo Real

Rate this content
Bookmark

Este masterclass te guiará a través de la instalación y explotación de una serie de aplicaciones intencionalmente vulnerables. Las aplicaciones utilizarán paquetes del mundo real con vulnerabilidades conocidas, incluyendo:

- Traversing de directorios
- Denegación de servicio de expresiones regulares (ReDoS)
- Scripting de sitios cruzados (XSS)
- Ejecución remota de código (RCE)
- Sobrescritura arbitraria de archivos (Zip Slip)
- Estas vulnerabilidades existen en varias aplicaciones, la mayoría de las cuales deberás instalar localmente o en una instancia en la nube.

Puedes realizar este masterclass de 2 formas diferentes:

- Utilizando las imágenes Docker preparadas O
- Instalando todo en tu máquina local.

47 min
17 Nov, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Discutiremos los beneficios y vulnerabilidades del software de código abierto, incluyendo la importancia de ser consciente de las dependencias transitivas. La seguridad de la cadena de suministro de software de código abierto es una preocupación creciente, y herramientas como Snyk pueden ayudar a identificar y solucionar vulnerabilidades. El masterclass cubre temas como el traversing de directorios, el scripting de sitios cruzados y el backtracking catastrófico, demostrando cómo se pueden explotar y solucionar estas vulnerabilidades. Los puntos clave incluyen el escaneo continuo, la verificación de vulnerabilidades en nuevas dependencias y el uso de herramientas como Snyk para el desarrollo seguro de software.

Available in English

1. Introducción a Open Source y Seguridad del Software

Short description:

Repasaremos una visión general del código abierto, sus beneficios y cómo ahorra tiempo. Luego hackearemos una aplicación. Mi nombre es Noa, un ingeniero de soluciones en Snyk. Siéntanse libres de hacer preguntas en el sistema de mensajería de preguntas y respuestas o en el chat. Hagan un fork de nuestra aplicación Node.js en github.com/Snyk/exploit workshop. ¿Cuál es el futuro de la seguridad del software de código abierto? Vamos a discutirlo. La mayoría del código es de código abierto y las vulnerabilidades se encuentran a menudo en las dependencias transitivas.

Hola, chicos, gracias por unirse a mi sesión. Vamos a hacer una visión general de lo que vamos a hacer. Vamos a repasar algunas diapositivas para entender el código abierto, por qué es increíble, cómo nos ahorra tiempo y todo, y luego vamos a pasar a hackear una aplicación. Así que empecemos. Mi nombre es Noa. Soy un ingeniero de soluciones en Snyk. Y obviamente, si tienen alguna pregunta durante el taller, tienen el sistema de mensajería de preguntas y respuestas si quieren ser un poco anónimos o pueden preguntarme en el chat. Estaré mirando también allí. Y si aún no lo han hecho, por favor vayan a github.com/Snyk/exploit workshop, ahí es donde se llevará a cabo la sesión práctica y hagan un fork de nuestra aplicación Node.js, que estará conectada con el primer repositorio.

Genial, para empezar, ¿no es increíble el código abierto, nos ahorra mucho tiempo, nos da, ya saben, nos hace menos frustrados, no tenemos que escribir el código nosotros mismos a veces, podemos traerlo de fuera. Y solo una pregunta para reflexionar, ¿cuál es el futuro de la seguridad del software de código abierto? ¿Vamos a tener más código abierto, menos código abierto, ya saben, porque a veces puede traer vulnerabilidades, y vamos a tocar ese tema muy pronto. Entonces, como desarrolladores, ya saben, escribimos código, depuramos código, nos enfrentamos al código y obviamente, nos emocionamos con el código cuando solucionamos problemas. Sin embargo, el código con el que realmente nos enfrentamos todos los días es muy pequeño en comparación con las aplicaciones. Es solo la punta del iceberg. Y para aquellos que realmente han mirado el código, ¿pudieron encontrar algún problema de seguridad? Les daré un segundo, si alguien quiere intentarlo. Enviaré los enlaces del taller aquí en el chat. Ahí vamos. Exactamente. Sí, las entradas no están sanitizadas. Y simplemente las enviamos sin verificar qué son primero. Ese es el problema de seguridad. Buen trabajo. Genial. Cuando pensamos en el código, como dijimos, solo hemos visto la punta del iceberg. Pero en realidad, el 80 al 90% de la base de código es de código abierto. Y el 80% de las vulnerabilidades se encuentran en las dependencias transitivas. Incluso son las dependencias de las que no somos conscientes en nuestro código. Digamos que traigo una dependencia. Pero no sé qué dependencias están trayendo ellos.

2. Vulnerabilidades en Dependencias Transitivas

Short description:

El 80% de las vulnerabilidades se encuentran en las dependencias transitivas. Debemos ser conscientes de lo que incorporamos en nuestro código. Herramientas como Snyk nos ayudan a encontrar y solucionar vulnerabilidades. Nuestra aplicación se construye sobre algo más que código personalizado. El código abierto ahorra tiempo pero puede introducir nuevas vulnerabilidades. La conciencia es clave. ¿Sabes qué hay dentro de tus dependencias? Se han producido problemas de seguridad en la cadena de suministro en el pasado.

Así que el 80% de las vulnerabilidades se encuentran en las dependencias transitivas. Aquí tengo un ejemplo de un paquete de código abierto, Dust.js LinkedIn, y veo que tiene una vulnerabilidad. Puede que no sepa dónde está la vulnerabilidad, pero al menos debería ser consciente de ella. Y ahí es donde necesitamos, ya sabes, ser conscientes de lo que estamos incorporando en nuestro código. Podemos utilizar herramientas como Snyk, que más adelante, durante la masterclass en sí, una vez que lleguemos a la parte práctica, vamos a crear un inicio de sesión, como un usuario en Snyk. Así que realmente podemos encontrar vulnerabilidades. Y más tarde, después de explotarlas, podemos solucionarlas y evitar que vuelvan a ocurrir. Nuevamente, no sé dónde está el problema, pero sé que hay un problema. Y sé la versión en la que estoy en esta dependencia y sé a qué versión quiero solucionarlo, para eliminar el problema. Así que visualicemos esto, supongo, en nuestra cabeza, esta es nuestra aplicación, ¿verdad? Estás trabajando en una aplicación, escribes el código. Esto es lo que pueden estar pensando, algunas líneas de código. Sin embargo, como dijimos, la imagen es mucho más grande. Nuestra aplicación se construye sobre mucho más que solo nuestro código personalizado. Y por eso necesitamos ser conscientes de ello.

También podemos ver que se utiliza mucho el código abierto. Se crean nuevos paquetes por ecosystem al año. Simplemente sigue creciendo y no se detiene. Porque, nuevamente, nos ahorra mucho tiempo. Nos ahorra mucha frustración y es súper útil para nosotros. Entonces, el hecho de que estemos utilizando código abierto es genial y fantástico, y nos ayuda. Pero no deberíamos sorprendernos cuando se agreguen nuevas vulnerabilidades a nuestros proyectos. Entonces, el código abierto es genial, pero también trae nuevas vulnerabilidades. Así que hay como esta pregunta, ¿es asombroso? ¿O no es asombroso? Nuevamente, la conciencia es clave aquí. Entonces, ¿qué tan bien conoces realmente lo que hay dentro de tus dependencias? ¿Las conoces bien? Y en realidad, hubo un problema de seguridad en la cadena de suministro en 2018. Sé que volvió a ocurrir en 2019.

3. Seguridad de la Cadena de Suministro de Código Abierto

Short description:

La seguridad de la cadena de suministro de código abierto es un término muy utilizado en el mundo de la seguridad. Un paquete llamado event stream tenía dependencias transitivas mortales, lo que hacía que los usuarios fueran vulnerables. Debemos ser conscientes de las dependencias transitivas y buscar lo que traen consigo. El gobierno de Estados Unidos está buscando una solución. Verificar los contribuyentes y utilizar herramientas como Snyk advisory es importante para comprender lo que hay dentro de nuestro código.

Y nuevamente, creo que prácticamente escuchamos de un gran problema cada año. Y la seguridad de la cadena de suministro de código abierto es siempre un tema candente en el mundo de la seguridad. Entonces, lo que sucedió es que había un paquete llamado event stream. Y con cientos de miles de personas que trajeron esta dependencia y la usaron, luego la siguiente versión que publicaron en realidad tenía una dependencia mortal, dependencias transitivas que event stream trajo consigo. Entonces, las personas que actualizaron sus dependencias sin mirar lo que estaban trayendo, en realidad se volvieron muy vulnerables a esto. Y es por eso que cuando traemos algo, realmente necesitamos ser conscientes de esas dependencias transitivas, especialmente de ellas, porque no podemos saber completamente, necesitamos buscar y ver qué dependencias están trayendo. Entonces, el código abierto ha sido un tema muy debatido, incluso el gobierno de Estados Unidos está tratando de encontrar alguna solución, necesitamos comprender cómo se puede resolver este problema. Entonces, hay una comisión de ciberespacio y solarium que se encargó de estos problemas de código abierto. Y volviendo a esta pregunta, ¿cuánto realmente sabes sobre tus dependencias? Para cualquiera que quiera escribir en el chat o tal vez responder, ¿qué hacen ustedes cuando descargan una dependencia que quieren usar? ¿Investigan? ¿Hay alguna o simplemente dicen, oh, conozco esta biblioteca, la voy a descargar sin verificar la versión? Voy a esperar. No piensan mucho en ello. La mayoría de las personas no lo hacen. Así que está bien. Genial. Entonces, realmente no tenemos una solución OCA limitada. Genial. Verificar los contribuyentes también es muy importante. Increíble. Gracias chicos por responder. Eso fue genial. Para comprender lo que hay dentro de nuestro código. Obviamente, la comunidad para verificar cuántos desarrolladores contribuyentes hay. Si es solo una persona, no podemos estar muy seguros al respecto. Snyk en realidad tiene un asesor. El asesor de Snyk. Estoy seguro de que si ustedes están usando algo más, está bien también. Esto es cómo se vería, por ejemplo, para el paquete moment, aquí verificamos la popularidad. Cuántas descargas tiene. Saben, si tiene muchas descargas significa que la gente lo está usando. Es genial. Entonces, se muestra el puntaje de salud del paquete, por ejemplo, si no está mantenido, no deberías usarlo solo porque si se encuentra un problema, nadie lo va a solucionar más adelante en términos de seguridad. Si tiene vulnerabilidades, a veces moment no tiene vulnerabilidades pero está utilizando

4. Comunidad de Código Abierto y Escaneo de Dependencias

Short description:

Comprender a la comunidad y a los contribuyentes. Vulnerabilidades en dependencias directas e indirectas. La vulnerabilidad de NPM en dependencias indirectas. Herramientas para automatizar actualizaciones. Uso de Snyk para actualizar. Hacer un fork del repositorio y configurarlo. Escaneo de dependencias normales y de desarrollo. Verificar package.json en busca de vulnerabilidades. Solucionar vulnerabilidades con actualizaciones. Visita sneak.io para obtener más información.

Otra dependencia que tiene vulnerabilidades y que hará que moments sea vulnerable. Y por último, la comunidad realmente comprendiendo a esos contribuyentes del repositorio de código abierto. Así que realmente tenemos que verificar todos ellos. Y nuevamente, tocar el tema de que la vulnerabilidad proviene de las dependencias directas versus las dependencias indirectas. Sé que esto es una conferencia de Node.js, por lo que NPM es en realidad muy, digamos, si esto fuera una competencia, estaría ganando en cuanto a las dependencias indirectas más vulnerables en el juego. Por lo tanto, realmente necesitamos herramientas que incluso automatizan las actualizaciones para mantenernos actualizados. Por ejemplo, si se lanza una nueva versión y descubrimos que la versión anterior es vulnerable, necesitamos tener una herramienta que pueda automatizar esas actualizaciones. Así que en realidad vamos a usar esto hoy y vamos a usar Snyk y pueden ver cómo pueden usarlo para actualizarlo. Sé que esta es la parte divertida. Así que empecemos con esa aplicación. ¿Han hecho un fork del repositorio? ¿Lograron hacerlo funcionar? Si alguien tiene problemas, avísenme. Les daré dos minutos para que lo configuren y luego les explicaré cómo va a funcionar. Sí, entonces, en realidad, escaneamos las dependencias normales. Las dependencias de desarrollo, podemos escanearlas, pero necesitamos agregar una bandera para eso, simplemente porque sabemos que a veces realmente no nos importan esas dependencias. Así que podemos escanearlas. Es otra bandera en el escaneo. Disculpen. Mi perro está justo a tiempo. Genial. Así que voy a asumir que todos tienen la aplicación funcionando. Debería verse algo así... algo como esto. Sí, puedo enviar el repositorio nuevamente. Entonces, Snyk verifica esas vulnerabilidades de código abierto. Específicamente, NodeJS, el gestor de paquetes NPM. Miramos el archivo package.json y vemos las dependencias allí. Y luego, las comparamos con nuestra base de datos. Y según lo que tengas en tu proyecto y la versión, te decimos cuáles son vulnerables y si puedes solucionarlos con una actualización, por ejemplo. Así que para aquellos que tienen la aplicación funcionando, pueden ir a sneak.io. Definitivamente vamos a

5. Escaneo y Explotación de Vulnerabilidades

Short description:

Tenemos una versión gratuita que pueden usar. No es necesario agregar sus tarjetas de crédito. Escanea tu código y obtén vulnerabilidades. Tendremos diferentes tareas, comenzando con la traversión de directorios. Configura el proyecto, escribe código y escanéalo con Snyk. Verás las vulnerabilidades en tu aplicación. El primer problema es una vulnerabilidad de traversión de directorios. Puedes leer al respecto e intentar explotarla. Usa la opción de punto-punto para navegar a través de los archivos. Vamos a la línea de comandos e intentemos obtener el contenido del sitio web.

envíalo aquí también. Tenemos una versión gratuita que pueden usar. No es necesario agregar sus tarjetas de crédito como algunas compañías. Pueden usarlo de forma gratuita e incluso pueden integrarlo con su cuenta de GitHub o cualquier otro lugar, como Bitbucket. Y pueden escanearlo. Y luego, después de unos segundos, obtendrán las vulnerabilidades. Y supongo que mientras ustedes hacen eso, simplemente explicaré cómo funcionará. Entonces, una vez que tengan todo configurado y escaneen Goof con Snyk y obtengan las vulnerabilidades, la masterclass es, tendremos diferentes tareas y las explicaré pronto. Pero para cada tarea, por ejemplo, realmente tendrán, por ejemplo, tenemos traversión directa. Y necesitarán hackear usando esta vulnerabilidad. Entonces, pueden consultar Snyk para comprender cuál es la vulnerabilidad. Y luego obtendrán pistas de los pasos de cómo hacerlo. Quiero decir, si saben cómo hacerlo, genial. Incluso pueden ir directamente al último. Pero creo que es mejor hacerlo paso a paso. Y creo que la mejor manera de hacerlo es dar como 10 minutos para cada uno. Revisar juntos la solución y pasar al siguiente. Entonces, el primer problema que abordaremos, imaginemos, quiero decir, estoy bastante seguro de que para aquellos que acaban de obtener, que lo vieron, y para aquellos que no, imaginen que alguien cambió el contexto de su aplicación. Eso es algo que puede suceder con la traversión de directorios, y ese es en realidad el primer desafío. Entonces, con Docker, irían, lo siento, sí, necesitan, oh, simplemente lo descomprimirían, irían a ese archivo y luego harían docker compose, el exacto, así que lo descargaría y estos son los comandos, sí, tal vez después, sí, entonces estos, docker load, menos i snkdemo2goof.tar, y luego, también el mongo, y luego docker-compose-up, genial, entonces para aquellos que tienen el proyecto funcionando, aquí, y pueden escribir, ya saben, hola, es una aplicación de tareas, es genial, podemos ir a la página de acerca de, la mejor aplicación de tareas de todas, quiero decir, si realmente quieres, puedes jugar con el, CSS, pero no llegarás muy lejos, nuestro equipo no, aceptará esas solicitudes de extracción, así que volviendo a mis tareas, tengo hola, puedo eliminarlo, y jugar con ello, y luego en términos de Snyk, una vez que lo hayan escaneado, pueden ver, nuestra súper, súper, súper vulnerable aplicación, en realidad tenemos 88 problemas en esta aplicación, donde vemos que, muchos de ellos son altos, y también tenemos algunos críticos. Genial. Entonces, para aquellos que lo tienen funcionando, en nuestro Goof, comiencen a jugar con él, y luego, como dijimos, nuestro primer problema, es un problema de denegación de servicio, así que iremos, lo siento, no me refería a la denegación de servicio, sino a la traversión de directorios, y nos llevará aquí, en realidad podemos leer al respecto, esta es una captura de pantalla que también pueden encontrar en Snyk, pueden leer al respecto, el problema, podemos ver una descripción general de ello, y luego podemos intentar explotar esta vulnerabilidad. Traversión de directorios. La mayoría, ¿cómo lo harían, ya saben, cuando piensan en ello, especialmente en la línea de comandos, ¿verdad, cuando vamos a un archivo diferente, simplemente vamos, ya saben, cd, y luego si quiero retroceder, puedo hacerlo. Si quiero volver a mi masterclass de Goof, voy a volver a ella. Entonces, el punto-punto es realmente una opción aquí. Entonces, si van a Goof, intentemos, ya saben, usar el punto-punto, no sucede nada realmente, ¿verdad? Entonces tal vez sea solo un problema del navegador. Así que seamos verdaderos hackers y vayamos a la línea de comandos. Y voy a hacer trampa un poco porque soy demasiado perezoso para escribir el sitio web, así que lo voy a copiar. En realidad, quiero ver si puedo obtener el contenido del sitio web aquí. Bien, entonces obtuve el contenido dehtml acerca de aquí.

6. Traversión de Directorios y Cross-Site Scripting

Short description:

Discutiremos cómo evitar el punto-punto y utilizar la codificación de URL. Retroceder desde lo público nos permite encontrar vulnerabilidades en las dependencias. Por ejemplo, marked 0.3.5 es vulnerable. La traversión de directorios nos permite acceder a lugares no autorizados y sobrescribir archivos. El siguiente problema: enlace malicioso que lleva a cross-site scripting.

Ahora voy a intentar hacer lo mismo o tal vez subir ya sabes, un directorio. Y estoy obteniendo algo extraño aquí. Sabes, la mejor forma de hacer el tonto que es la página principal. Así que déjame intentar uno más. Subir un directorio más. Y en realidad estoy obteniendo el mismo resultado. Entonces para aquellos que ya llegaron allí o aquellos que aún no lo han hecho pero aún quieren responder cómo puedo evitar el punto-punto aquí. ¿Alguna idea? Sí, exactamente. No cómo defenderse aún contra eso. Queremos primero hackear y luego defendernos. Entonces, codificación de URL, ¿alguien sabe qué son? ¿Cuáles son las codificaciones de URL para los puntos? Sí, exactamente. Entonces necesitamos dos de esos, ¿verdad? Ahora vamos a subir uno. Así que nos movimos, bien, ¿qué significa eso? Nos movimos uno y en realidad, hagamos esto. Oh, un segundo. Curl, en lugar de retroceder clave por clave. Bien, nos movimos desde lo público. Y ahora podemos buscar y encontrar cosas. Por ejemplo, si veo el package.json, puedo ver todas las dependencias que hay en este proyecto. Y al conocer las dependencias de este proyecto, puedo encontrar dónde están esas vulnerabilidades. Correcto. Entonces, por ejemplo, no quiero arruinar la sorpresa, pero marked es el próximo ejercicio que vamos a explotar. Entonces, al saber que están usando mark 0.3.5, sabemos que es vulnerable y sabemos que podemos explotarlo. Entonces, la traversión de directorios en realidad me permite llegar a lugares a los que no debería llegar. Y, por ejemplo, si incluso tienen permisos de escritura, puedo sobrescribir archivos y, ya sabes, obtener contraseñas y nombres de usuario y cosas realmente confidenciales si es necesario. Voy a borrar esto. Y vamos a volver aquí, presentar. Les voy a dar el siguiente escenario y ustedes me dirán qué problema podría ser. Entonces, si uno de sus usuarios recibe un enlace malicioso de su sitio web, ¿qué podría ser eso? Cross site scripting.

7. Explorando Cross-Site Scripting y Enlaces Markdown

Short description:

Y les daré unos cinco minutos para repasarlo nuevamente. El próximo tema es cross-site scripting. Discutiremos qué es y cómo hackearlo. Repasaremos la solución paso a paso. Exploraremos el uso de scripts y alertas, y entenderemos cómo funciona el sanitizador de la aplicación. También aprenderemos sobre los enlaces Markdown.

Exactamente. Ese es nuestro próximo problema. Y les daré unos cinco minutos para repasarlo nuevamente. Nuevamente, todos los pasos están aquí. Pueden pasar al siguiente.

Esto. El siguiente es este. Cross-site scripting. Me salté uno y vamos a volver a él. Entonces, cross-site scripting. Y tienen aquí. Explicación. Qué es cross-site scripting. Y, por supuesto, la pista. Cómo hackear esto. Así que les daré cinco minutos y repasaremos la solución. Si no hay voluntarios, repasaré la solución. De manera sencilla, cuando pensamos en cross-site scripting, en realidad pensamos en agregar un script JavaScript. Usando algo como esto, y no lo estoy escribiendo porque cuando haga clic en él, verán todas las respuestas. Así que lo haremos paso a paso. Por ejemplo, si intento usar scripts y agregar una alerta, no pasará nada. Y la razón de esto es que cuando se construyó esta aplicación, se utilizó el paquete. Así que si en realidad jugamos y lo hacemos en negrita y hermoso. Y eso en realidad proviene de esto. Vemos a Mark aquí. Y en realidad estamos usando un sanitizador para Mark. Y ese sanitizador busca algunas cosas específicas sobre JavaScript. Por ejemplo, ve el script, alert1. Porque ve el script, sabe que es algún tipo de JavaScript y simplemente lo crea como una cadena. Y por eso lo vemos así. Entonces, si leemos sobre Markdown y lo que realmente nos permite hacer, podemos usar enlaces Markdown. Y esos enlaces Markdown se usan así, por ejemplo.

8. Explotando el Sanitizador de JavaScript

Short description:

Y si lo hago, puedo hacer clic en él y me llevará a la interfaz de sincronización. La razón de esto es que el sanitizador de Mark busca la palabra JavaScript seguida de dos puntos. Podemos intentarlo nuevamente con algunas codificaciones, representando el punto y coma y el corchete. Este truco confunde al navegador, permitiéndonos explotarlo.

Y si lo hago, puedo hacer clic en él y me llevará a la interfaz de sincronización, lo cual es genial. Y si voy, digamos que quiero algo más. Así que en realidad puedo hacer algo que se vea así tal vez. Si lo intento, sabes, tengo mi JavaScript alerta aquí y mi enlace malicioso. Y estoy rezando para que funcione. Bueno, pero aún no funcionó. Y la razón de esto es que el sanitizador de Mark busca esta palabra JavaScript, ya sabes, JavaScript, y luego los dos puntos. Entonces, tiene una expresión regular detrás de escena que en realidad busca esto y si coincide, no te permitirá publicarlo. Así que podemos ser inteligentes y tal vez intentarlo nuevamente con algunas codificaciones, y representar el punto y coma y el corchete, así. Así que, con esperanza de nuevo de que esto funcione. Bueno, esto tampoco funcionó. Y la razón de eso es el mismo concepto, la expresión regular también está buscando JavaScript punto y coma, y JavaScript y signo, signo de almohadilla, 58, así que en realidad está buscando todo esto. Y está diciendo, bueno, sé que esa es la representación del punto y coma, así que tampoco lo dejaré pasar. Así que, pensando de nuevo, pensando de nuevo. Bueno, ¿qué pasa si agrego esto? Agregando esto. Así que este truco. En realidad funciona. ¿Alguien sabe la razón por la que esto funciona para nosotros? Entonces, de alguna manera, específicamente esto se usa para confundir al navegador. Entonces, el navegador está diciendo, bueno, esta palabra this realmente no coincide aquí, pero probablemente quisieron decir que fue probablemente un error y quisieron tenerlo sin this. Entonces, en este caso de uso específico, el navegador en realidad ignora esto, pero la expresión regular, dado que hay un this, no lo captura. Entonces, el navegador es en realidad la razón por la que podemos explotarlo.

9. Problemas de la Comunidad de Código Abierto

Short description:

Las comunidades de código abierto carecen de responsabilidad y mantenimiento, lo que las hace vulnerables a la explotación. Las vulnerabilidades de scripting entre sitios pueden surgir al utilizar ciertos documentos. La falta de responsabilidad en el código abierto puede llevar a problemas de seguridad. Los ataques de denegación de servicio pueden bloquear a los usuarios el acceso a sitios web. Dependencias como M.S. y M.S. pueden contribuir a estos problemas.

Y de hecho, otro problema con la comunidad de código abierto es que nadie es realmente responsable de nada. Y si voy aquí, este fue en realidad un problema que se planteó específicamente, que si usamos documentos o esto, va a causar un problema de scripting entre sitios. Y esto se planteó en mayo de 2015. Perdón, mayo de 2015. Y en realidad se cerró un año después. Entonces, en términos de usar código abierto, ya sabes, no hay responsabilidades. Es solo una comunidad que lo hace. Y si la comunidad no lo mantiene, podría ser explotable.

En lugar de esta alerta. Intentemos eso. En realidad no estoy seguro. Intentemos. Esto. Eliminar. No, no funcionó. Si estoy enviando el enlace de GitHub. Genial, eso fue scripting de próstata. Continuemos.

Y ahora Otro caso para ti. Entonces, es Navidad y tienes una tienda de suéteres muy bonita, y la gente quiere comprar en línea, y algo está bloqueando al usuario para acceder a tu sitio. ¿Qué podría ser? Muy negación. Sí. Denegación de servicio. Entonces, nuevamente, el mismo concepto. Tenemos, tenemos los pasos aquí. Y quiero que crees algunos, ya sabes, usa la línea de comandos, usa lo que necesites y bloquea tu sitio web, congélalo. Este problema en realidad proviene de mis dependencias directas.

10. Usando el paquete M.S. y la retrotrazabilidad catastrófica

Short description:

Vamos a usar el paquete M.S. para agregar un elemento a nuestra lista de tareas y ver el resultado en la página web. Al agregar múltiples cincos y ceros, observamos un retraso entre cada adición. Agregar nuestro nombre varias veces no tiene ningún efecto. Este comportamiento se conoce como retrotrazabilidad catastrófica.

que están trayendo. Se llama M.S. y M.S. en realidad está trayendo una dependencia de dependencias transitivas llamada tengo el nombre exacto de ello. Tengo un abierto aquí. Así que sí, está bien. Entonces M.S. es sus dependencias directas y esto en realidad es traído por mi humanizado M.S. Entonces este problema específico es traído por una dependencia transitoria.

Así que vamos a ser buenos hackers de nuevo y vamos a ir a la línea de comandos y vamos a usar ese comando. Usar el paquete M.S. y vamos a, ya sabes, vamos a quieres agregar otra cosa en mi lista de tareas, quiero comprar leche en cinco minutos. Voy a ingresar eso y vemos que ha terminado y si voy aquí y actualizo la página veo mi leche en cinco minutos. Genial. Así que voy a hacer eso de nuevo. Así que cinco correcto, muchos cincos. Veamos qué sucede. OK. Voy a actualizar mi página de nuevo. Sigue funcionando bien. Así que ahora en lugar de escribir manualmente todos esos cincos en realidad voy a usar este comando que imprime muchos cincos muchas veces. Así que voy a hacer eso. Y vemos que empezamos a ver que hay un pequeño retraso entre cada uno. Así que hagamos lo mismo y agreguemos otro cero. OK, así que empezamos a ver ese retraso Así que lo voy a hacer con uno, dos, tres, cuatro ceros. Eso es cuatro. Sí, estoy ciego. Sí, cuatro ceros. Y. OK, está tardando un poco más y quiero eliminar cosas y agregar cosas. Agregando mi nombre muchas veces y realmente no está sucediendo nada. Así que detrás de escena, algo que se llama retrotrazabilidad catastrófica está.

11. Retrotrazabilidad catastrófica en Regex

Short description:

En este paquete específico, estamos utilizando regex para buscar números seguidos de palabras como minutos u horas. Sin embargo, un cambio de 'S' a 'A' causó una retrotrazabilidad catastrófica, donde el regex intenta encontrar una coincidencia pero entra en pánico cuando no la encuentra. Este ejemplo más pequeño implica encontrar una secuencia de 'A' o uno o más 'C' seguidos de 'D' al final.

Lo siento, se me olvidó por completo eso. En realidad. Bueno, disculpas por esto. Me salté un paso en mi explicación y lo olvidé por completo. Entonces, lo que sucede aquí en este paquete específico es que estamos buscando algún tipo de número. Y luego usando regex y luego buscando la palabra minutos u horas o cualquier otra cosa, realmente. Entonces, esto es lo que estamos buscando ahora en regex.

Hay algo que se llama retrotrazabilidad catastrófica, que es decir. Está intentando buscar una coincidencia. OK, lo que hice que causó la denegación de servicio es que Cambié la S al final por una A. Entonces, si volvemos al último comando que ejecuté, ves aquí, cambié la S por una A. Y esa es la razón que causa la retrotrazabilidad catastrófica. Entonces, lo que hace es buscar, ya sabes, está pasando por todos esos números, ya sabes, como muchos cincos, buscando en todos ellos finalmente obtiene. Es como, OK, los encontré. Genial. Encontré una I. Genial. Todo el camino. Encontré una última letra increíble. Oh no, no es una S. ¿Qué hago? Entonces comienza a entrar en pánico. El regex comienza a entrar en pánico. Así que retrocede y realmente intenta encontrar esa coincidencia. Este es un ejemplo más pequeño y a menor escala porque no tenemos tiempo para ir a cientos de ejemplos.

En este ejemplo, tenemos una a y luego B o C más. Así que muchos C, al menos debe haber uno. Y luego toda esta expresión debe ocurrir al menos una vez y luego debe tener una D al final.

12. Explotación y Solución de Vulnerabilidades

Short description:

Cuando cambiamos la 'D' por algo más, el número de pasos aumenta de 9 a 38. Esto causa pánico ya que se pierde la coincidencia. Lo mismo ocurre cuando cambiamos 'minutes' por 'minutA'. Después de algún tiempo, finalmente se realizan todas las adiciones. Hemos explotado la aplicación y ahora queremos solucionarla. Al actualizar la versión, podemos resolver los problemas. Puedes obtener más información sobre este problema en el módulo de aprendizaje.

Entonces, la forma en que se vería esto es algo así. Estos son los pasos. OK. Ahora, si eliminamos la D aquí y la cambiamos por algo más. Podemos ver que de nueve pasos, saltó a treinta y ocho pasos y esto es solo por cinco letras. Así que ahora entra en pánico y trata de encontrar esa coincidencia nuevamente. Y eso es lo que está sucediendo con 'minutes' con una A al final en lugar de una S.

Entonces ahora vemos que después de que pasó el tiempo, finalmente agregó todos mis Noah's. Y milk. ¿Alguna pregunta sobre esto? ¿Tuvo sentido eso? Lo siento. Me salté ese paso súper importante por completo.

Genial, ahora que realmente hemos explotado. ¿Cómo lo hacemos bien para verlo? Puedo enviártelo aquí. Solo está en línea, es un sitio web muy útil. Me gusta mucho, para aquellos que aman las expresiones regulares, este es un sitio web realmente bueno para encontrar coincidencias y todo eso. Casi como Tinder. Solo bromeo. Así que ahora hemos explotado. Hemos explotado la aplicación y ahora realmente queremos solucionarlo. Entonces, si vas a Snyk y ya tienes todas esas cuestiones específicas. Cada una. Esta es la marca que estamos buscando. Cada una tiene, por ejemplo, SD, el primer problema que explotamos. Así que podemos ver toda esta información al respecto. Vemos que se introdujo desde la versión 0.2.4 y dónde se solucionó. Entonces, si lo actualizamos solo 0.01 versión más arriba, ya no es vulnerable. Y en realidad, si quieres aprender más sobre esta vulnerabilidad de recorrido de directorios, hay un módulo de aprendizaje completo que puedes hacer aquí que realmente te enseña de manera práctica qué es este problema, aunque ya lo hayamos hecho. Así que ahora todos ustedes son expertos. Y también, una descripción general de qué es este problema.

13. Solución de Vulnerabilidades y Pruebas

Short description:

Prevenir vulnerabilidades utilizando el sistema común de puntuación de vulnerabilidades. Acceder a la vulnerabilidad y abrir una solicitud de extracción corregida. Snyk ejecuta pruebas para asegurarse de que no se agreguen nuevas vulnerabilidades. ¿Alguien probó la solicitud de extracción corregida? Reconstruye y prueba la aplicación para ver el impacto de la versión.

Para evitar que esto suceda, no podrás lidiar con ello. Por supuesto, información adicional como el sistema común de puntuación de vulnerabilidades, que es un estándar de la industria, y por supuesto, si quieres aprender más sobre esta biblioteca específica, puedes leer todo al respecto aquí. Así de fácil, ya sabes, con solo hacer clic en un botón.

Voy a acceder a la vulnerabilidad. Pero va a llevarme a una página donde puedo agregar si quiero corregir más vulnerabilidades, por ejemplo, tengo un recorrido de directorios aquí por Adam's. Pero no quiero corregirlo ahora mismo, solo quiero centrarme en St. Así que voy a abrir una solicitud de extracción corregida.

Ahora Snyk, detrás de escena, va a escribir un mensaje de confirmación y abrir una nueva rama para este problema. Tomará un poco de tiempo. Abro mi GitHub y voy a mi aplicación tonta. Puedo ver que no es esta. Vale, mi Internet está un poco lento. Pero en general, una vez que abres esa solicitud de extracción corregida, se verá así. Se verá así. Y en realidad tendrás ese mensaje de confirmación con toda la información sobre este problema. Si está corregido o no, el sistema común de puntuación de vulnerabilidades o qué tipo de problema es. Así que este en realidad también es un problema de fuera de servicio. Pero está llegando a través de mime, es un problema diferente.

Además de eso, Snyk ejecutará pruebas adicionales en esta rama para asegurarse de que no estés agregando nuevas vulnerabilidades a tu aplicación. Porque tenemos una especie de fase inicial donde solo queremos limpiar nuestra aplicación de vulnerabilidades en lugar de agregar nuevas. Así que nos aseguramos de que no estemos agregando problemas de seguridad de código abierto, problemas de licencia y problemas de análisis de código estático en el plan gratuito, creo que solo verás este. Así que nos aseguramos de que no estemos agregando nuevas vulnerabilidades a esto. ¿Alguien pudo probarlo? ¿Pudieron probar la solicitud de extracción corregida? ¿Alguien? Permítanme intentar corregirlo. Creo que tal vez sea un problema de mi lado. Pero una vez que las corrijas, puedes ejecutar tu aplicación nuevamente. Después de reconstruirla, obviamente. Y una vez que lo hagas, intenta hackearlo nuevamente. Intenta explotar la aplicación nuevamente. Y verás que la versión realmente importa.

14. Solución de Vulnerabilidades y Conclusiones

Short description:

Actualizamos la versión de la biblioteca marked, solucionando el problema de cross-site scripting. Conclusiones: conecta tu repositorio de código fuente para un escaneo continuo, conoce tus fuentes, utiliza el asesoramiento de Snyk para verificar las vulnerabilidades en nuevas dependencias antes de descargarlas. Snyk está disponible de forma gratuita.

Así que en esos términos aquí. Ahí vamos. Así que tenemos marked. Así que podemos hacer una solicitud de extracción para marked y realmente actualizamos una versión. Y vemos que todas las comprobaciones pasaron. Genial. Y puedo fusionarlo y saber que realmente se solucionó el problema de cross-site scripting. Así que ahora, cuando lo fusione y vuelva a ejecutar mi aplicación, no podré explotarlo utilizando la biblioteca marked. ¿No fue divertido, chicos? ¿Qué puedes hacer al respecto?

Entonces, las conclusiones de la sesión de hoy son: conecta tu repositorio de código fuente para escanearlo continuamente. Y obviamente, conoce tus fuentes. Si estás utilizando nuevas dependencias, puedes utilizar el asesoramiento de Snyk para verificarlas antes. De esa manera, sabrás qué versión es vulnerable y cuál estás esperando que pase la prueba. Increíble. Por lo tanto, puedes utilizar el asesoramiento para comprender realmente lo que estás incorporando a tus proyectos antes de descargar el paquete. Y sí, puedes utilizar Snyk de forma gratuita. Aquí mismo. Y mantente seguro en tu trayecto.

Watch more workshops on topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Top Content
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.