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

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Slides
Rate this content

La seguridad no se trata solo de corregir errores; se trata de entender las suposiciones que hacemos (y evitar el pánico innecesario). En esta charla, profundizaremos en los modelos de amenazas de Node.js y Express, que coautoré, para desglosar en qué confían, en qué no, y por qué eso realmente importa para los desarrolladores e investigadores de seguridad.

Examinaremos vulnerabilidades del mundo real que encajan dentro de estos modelos, aclararemos algunos de los conceptos erróneos de seguridad más comunes (porque no todo es un colapso crítico), y exploraremos cómo estas suposiciones de seguridad influyen en las recompensas por errores, la explotabilidad y las soluciones a largo plazo. Al final, los asistentes se irán con una mejor comprensión de lo que es un riesgo de seguridad real, lo que no lo es, y cómo construir aplicaciones que no les quiten el sueño.

This talk has been presented at Node Congress 2025, check out the latest edition of this JavaScript Conference.

Ulises Gascón
Ulises Gascón
17 min
17 Apr, 2025

Comments

Sign in or register to post your comment.
  • Costanza
    Costanza
    Bromley web works. Founder
    👍
Video Summary and Transcription
En esta charla, discutiremos la seguridad, las vulnerabilidades y cómo mejorar su seguridad general. Exploraremos varias vulnerabilidades y la diferencia entre errores de desarrollador y configuraciones incorrectas. Entender los modelos de amenazas es crucial para determinar la responsabilidad de las vulnerabilidades. Los desarrolladores tienen la responsabilidad última de manejar la entrada del usuario, los datos de la red y otros factores. Entender los modelos de amenazas, las mejores prácticas y asumir la responsabilidad de las dependencias son clave para mejorar la seguridad. La seguridad es un proceso continuo que requiere dedicación y comprensión.

1. Introduction to Security and Vulnerabilities

Short description:

En esta charla, discutiremos sobre seguridad, vulnerabilidades y cómo mejorar tu seguridad en general. Una vulnerabilidad es un defecto, una mala configuración de seguridad o un punto débil en nuestro sistema que puede ser explotado por terceros. Hoy, exploraremos varias vulnerabilidades.

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

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

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

2. Understanding Vulnerabilities and Threat Models

Short description:

En los ejemplos dados, uno es un caso claro de error del desarrollador con una inyección SQL, mientras que el otro es una mala configuración que expone una vulnerabilidad. Entender la diferencia entre estos dos escenarios es crucial para determinar la responsabilidad de las vulnerabilidades. La charla se centrará en los modelos de amenazas, un enfoque estructurado para comprender los riesgos de seguridad, identificar amenazas potenciales y discutir mitigaciones. Explora qué necesita ser protegido, problemas potenciales y límites, y proporciona recomendaciones para mejorar la seguridad.

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

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

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

3. Threat Models and Developer Responsibility

Short description:

Los modelos de amenazas son herramientas esenciales para comprender las vulnerabilidades en bibliotecas y runtimes como Node.js y Express. Estos modelos se basan en la confianza y ayudan a los investigadores a determinar qué se considera una vulnerabilidad. Sin embargo, es crucial entender que, aunque los frameworks proporcionan mecanismos para prevenir ciertas vulnerabilidades, los desarrolladores tienen la responsabilidad última de manejar la entrada del usuario, los datos de red y otros factores.

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

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

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

4. Developer Responsibility and Shared Models

Short description:

Los desarrolladores tienen la responsabilidad última de manejar la entrada del usuario, los datos de red y otros factores. El modelo de responsabilidad compartida en los servicios en la nube espera que los desarrolladores asuman la responsabilidad. Dependiendo del modelo de implementación, los desarrolladores pueden ser responsables del equipo de hardware, la seguridad física y la configuración de la aplicación. Comprender este modelo de amenazas es crucial ya que los frameworks y runtimes tienen sus áreas de responsabilidad mientras que los desarrolladores manejan otras.

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

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

5. Understanding Threat Models and Best Practices

Short description:

Comprender los modelos de amenazas y cómo interactúan las bibliotecas es crucial. Puntos clave: validar y sanitizar toda entrada, entender la autenticación, usar encabezados de seguridad y estar al tanto de los ataques web comunes en el OWASP top 10. Asumir plena responsabilidad de las dependencias.

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

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

6. Dependency Ownership and Security Practices

Short description:

Asume plena responsabilidad de tus dependencias. Entiende la seguridad de las bibliotecas y revisa y audita las dependencias. Pon límites al uso de recursos para servicios fuera de internet. Gestiona las cookies adecuadamente y maneja los errores y el registro. Prioriza la seguridad y está al tanto de vulnerabilidades comunes como la contaminación de prototipos y paquetes maliciosos de terceros.

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

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

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

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

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

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

7. Understanding Dependencies and Security Processes

Short description:

Entiende las dependencias, CVEs, y establece límites en los datos recibidos. No todos los problemas de seguridad son vulnerabilidades. Los desarrolladores juegan un papel clave en la comprensión de límites, modelos de amenazas y en la construcción de políticas de seguridad. La seguridad es un proceso continuo que requiere dedicación y comprensión. Se proporcionan recursos y ejemplos para un mayor aprendizaje.

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

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

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

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

Es una jungla ahí fuera: ¿Qué está pasando realmente dentro de tu carpeta Node_Modules?
Node Congress 2022Node Congress 2022
26 min
Es una jungla ahí fuera: ¿Qué está pasando realmente dentro de tu carpeta Node_Modules?
Top Content
The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.
El estado de la autenticación sin contraseña en la web
JSNation 2023JSNation 2023
30 min
El estado de la autenticación sin contraseña en la web
Passwords are terrible and easily hacked, with most people not using password managers. The credential management API and autocomplete attribute can improve user experience and security. Two-factor authentication enhances security but regresses user experience. Passkeys offer a seamless and secure login experience, but browser support may be limited. Recommendations include detecting Passkey support and offering fallbacks to passwords and two-factor authentication.
5 Formas en las que Podrías Haber Hackeado Node.js
JSNation 2023JSNation 2023
22 min
5 Formas en las que Podrías Haber Hackeado Node.js
Top Content
The Node.js security team is responsible for addressing vulnerabilities and receives reports through HackerOne. The Talk discusses various hacking techniques, including DLL injections and DNS rebinding attacks. It also highlights Node.js security vulnerabilities such as HTTP request smuggling and certification validation. The importance of using HTTP proxy tunneling and the experimental permission model in Node.js 20 is emphasized. NearForm, a company specializing in Node.js, offers services for scaling and improving security.
Política de Seguridad de Contenido con Next.js: Mejorando la Seguridad de tu Sitio Web
React Summit US 2023React Summit US 2023
9 min
Política de Seguridad de Contenido con Next.js: Mejorando la Seguridad de tu Sitio Web
Top Content
Lucas Estevão, a Principal UI Engineer and Technical Manager at Avenue Code, discusses how to implement Content Security Policy (CSP) with Next.js to enhance website security. He explains that CSP is a security layer that protects against cross-site scripting and data injection attacks by restricting browser functionality. The talk covers adding CSP to an XJS application using meta tags or headers, and demonstrates the use of the 'nonce' attribute for allowing inline scripts securely. Estevão also highlights the importance of using content security reports to identify and improve application security.
Cómo se hackean las aplicaciones React en el mundo real
React Summit 2022React Summit 2022
7 min
Cómo se hackean las aplicaciones React en el mundo real
Top Content
How to hack a RealWorld live React application in seven minutes. Tips, best practices, and pitfalls when writing React code. XSS and cross-site scripting in React. React's secure by default, but not always. The first thing to discover: adding a link to a React application. React code vulnerability: cross-site scripting with Twitter link. React doesn't sanitize or output H ref attributes. Fix attempts: detect JavaScript, use dummy hashtag, transition to lowercase. Control corrector exploit. Best practices: avoid denialist approach, sanitize user inputs. React's lack of sanitization and output encoding for user inputs. Exploring XSS vulnerabilities and the need to pretty print JSON. The React JSON pretty package and its potential XSS risks. The importance of context encoding and secure coding practices.
Permíteme mostrarte cómo las aplicaciones de React son hackeadas en el mundo real
React Advanced 2021React Advanced 2021
22 min
Permíteme mostrarte cómo las aplicaciones de React son hackeadas en el mundo real
Top Content
React's default security against XSS vulnerabilities, exploring and fixing XSS vulnerabilities in React, exploring control characters and security issues, exploring an alternative solution for JSON parsing, and exploring JSON input and third-party dependencies.

Workshops on related topic

Masterclass Práctica: Introducción a Pentesting para Aplicaciones Web / APIs Web
JSNation US 2024JSNation US 2024
148 min
Masterclass Práctica: Introducción a Pentesting para Aplicaciones Web / APIs Web
Featured Workshop
Gregor Biswanger
Gregor Biswanger
En esta masterclass práctica, estarás equipado con las herramientas para probar efectivamente la seguridad de las aplicaciones web. Este curso está diseñado tanto para principiantes como para aquellos que ya están familiarizados con las pruebas de seguridad de aplicaciones web y desean ampliar su conocimiento. En un mundo donde los sitios web juegan un papel cada vez más central, asegurar la seguridad de estas tecnologías es crucial. Comprender la perspectiva del atacante y conocer los mecanismos de defensa apropiados se han convertido en habilidades esenciales para los profesionales de TI.Esta masterclass, dirigida por el renombrado entrenador Gregor Biswanger, te guiará a través del uso de herramientas de pentesting estándar de la industria como Burp Suite, OWASP ZAP y el marco profesional de pentesting Metasploit. Aprenderás a identificar y explotar vulnerabilidades comunes en aplicaciones web. A través de ejercicios prácticos y desafíos, podrás poner en práctica tu conocimiento teórico y expandirlo. En este curso, adquirirás las habilidades fundamentales necesarias para proteger tus sitios web de ataques y mejorar la seguridad de tus sistemas.
De 0 a Autenticación en una hora con ReactJS
React Summit 2023React Summit 2023
56 min
De 0 a Autenticación en una hora con ReactJS
WorkshopFree
Kevin Gao
Kevin Gao
La autenticación sin contraseña puede parecer compleja, pero es simple de agregar a cualquier aplicación utilizando la herramienta adecuada. Hay múltiples alternativas que son mucho mejores que las contraseñas para identificar y autenticar a tus usuarios, incluyendo SSO, SAML, OAuth, Magic Links, One-Time Passwords y Authenticator Apps.
Mientras abordamos los aspectos de seguridad y evitamos errores comunes, mejoraremos una aplicación JS de pila completa (backend Node.js + frontend React) para autenticar a los usuarios con OAuth (inicio de sesión social) y One Time Passwords (correo electrónico), incluyendo:- Autenticación de usuarios - Gestión de interacciones de usuarios, devolviendo JWTs de sesión / actualización- Gestión y validación de sesiones - Almacenamiento seguro de la sesión para solicitudes de cliente posteriores, validación / actualización de sesiones- Autorización básica - extracción y validación de reclamaciones del token JWT de sesión y manejo de autorización en flujos del backend
Al final del masterclass, también exploraremos otros enfoques de implementación de autenticación con Descope, utilizando SDKs de frontend o backend.
Principales Diez Vulnerabilidades de Seguridad OWASP en Node.js
JSNation 2024JSNation 2024
97 min
Principales Diez Vulnerabilidades de Seguridad OWASP en Node.js
Workshop
Marco Ippolito
Marco Ippolito
En este masterclass, cubriremos las diez vulnerabilidades más comunes y riesgos de seguridad críticos identificados por OWASP, que es una autoridad confiable en Seguridad de Aplicaciones Web.Durante el masterclass, aprenderás cómo prevenir estas vulnerabilidades y desarrollar la capacidad de reconocerlas en aplicaciones web.El masterclass incluye 10 desafíos de código que representan cada una de las vulnerabilidades más comunes de OWASP. Se proporcionarán pistas para ayudar a resolver las vulnerabilidades y pasar las pruebas.El instructor también proporcionará explicaciones detalladas, diapositivas y ejemplos de la vida real en Node.js para ayudar a comprender mejor los problemas. Además, obtendrás información de un Mantenedor de Node.js que compartirá cómo gestionan la seguridad en un proyecto grande.Es adecuado para desarrolladores de Node.js de todos los niveles de habilidad, desde principiantes hasta expertos, se requiere un conocimiento general de aplicaciones web y JavaScript.
Tabla de contenidos:- Control de Acceso Roto- Fallas Criptográficas- Inyección- Diseño Inseguro- Configuración de Seguridad Incorrecta- Componentes Vulnerables y Obsoletos- Fallas de Identificación y Autenticación- Fallas de Integridad de Software y Datos- Fallas de Registro y Monitoreo de Seguridad- Falsificación de Solicitudes del Lado del Servidor
Cómo Construir Control de Acceso Front-End con NFTs
JSNation 2024JSNation 2024
88 min
Cómo Construir Control de Acceso Front-End con NFTs
WorkshopFree
Solange Gueiros
Solange Gueiros
Comprende los fundamentos de la tecnología NFT y su aplicación en el fortalecimiento de la seguridad web. A través de demostraciones prácticas y ejercicios prácticos, los asistentes aprenderán cómo integrar sin problemas mecanismos de control de acceso basados en NFT en sus proyectos de desarrollo front-end.
Encontrar, Hackear y solucionar las vulnerabilidades de NodeJS con Snyk
JSNation 2022JSNation 2022
99 min
Encontrar, Hackear y solucionar las vulnerabilidades de NodeJS con Snyk
Workshop
Matthew Salmon
Matthew Salmon
npm y seguridad, ¿cuánto sabes sobre tus dependencias?Hack-along, hacking en vivo de una aplicación Node vulnerable https://github.com/snyk-labs/nodejs-goof, Vulnerabilidades tanto de código abierto como de código escrito. Se anima a descargar la aplicación y hackear junto con nosotros.Corrigiendo los problemas y una introducción a Snyk con una demostración.Preguntas abiertas.
Aporta Calidad y Seguridad al pipeline de CI/CD
DevOps.js Conf 2022DevOps.js Conf 2022
76 min
Aporta Calidad y Seguridad al pipeline de CI/CD
Workshop
Elena Vilchik
Elena Vilchik
En esta masterclass repasaremos todos los aspectos y etapas al integrar tu proyecto en el ecosistema de Calidad y Seguridad del Código. Tomaremos una aplicación web simple como punto de partida y crearemos un pipeline de CI que active el monitoreo de calidad del código. Realizaremos un ciclo completo de desarrollo, comenzando desde la codificación en el IDE y abriendo una Pull Request, y te mostraré cómo puedes controlar la calidad en esas etapas. Al final de la masterclass, estarás listo para habilitar esta integración en tus propios proyectos.