Asegurando Aplicaciones Renderizadas en el Servidor – Caso Next.js

Hola a todos, y bienvenidos a esta charla, Asegurar el Servidor en las Aplicaciones Rojas en el Contexto de Next.js. Mi nombre es Eric Burel. Soy un ingeniero freelance de Francia. Soy miembro del colectivo Devo Graphics que realiza las encuestas de estado de JavaScript, HTML, CSS, GraphQL, y ahora React. Soy un formador de Next.js y autor de cursos, y actualmente estoy escribiendo un curso llamado Next Patterns donde muestro demostraciones interactivas de patrones de programación avanzados con Next.

Estas nuevas tecnologías, Next.js, tecnologías de renderizado del lado del servidor, traen muchos nuevos desafíos para nosotros, los desarrolladores front-end, para nosotros, los desarrolladores de React. Porque full stack significa tener un back-end, y un back-end significa muchos problemas para los desarrolladores front-end y las personas que tradicionalmente han estado escribiendo aplicaciones front-end en React. Además, estas tecnologías nos permiten mezclar de manera transparente el código del servidor y del cliente, JavaScript que se ejecuta en el navegador y JavaScript que se ejecuta en el servidor. Esta es una gran fuente de complejidad, a pesar de ser una innovación muy interesante. Así que full stack y mezclar el código del servidor y del cliente puede significar muchos problemas, problemas de seguridad. Por lo tanto, es importante comenzar a pensar en la seguridad en el contexto de las aplicaciones Next.js.

Cada nueva tecnología puede traer nuevas pistolas de comida. Las pistolas de comida son errores que los desarrolladores tenderán sistemáticamente a cometer, y algunos de ellos podrían crear vulnerabilidades de seguridad. Por ejemplo, ¿verificas la autenticación en un diseño de Next.js? Esta es una pregunta que vamos a responder en unos minutos. Pero primero, hablemos del OWASP. El OWASP es una fundación sin fines de lucro que quiere que tu software sea seguro. Son personas realmente geniales. Así que publican un top 10 de los riesgos de seguridad más comunes que enfrentan las aplicaciones web. También lo hacen para aplicaciones móviles e incluso aplicaciones de IA recientemente. Así que aplicar el OWASP top 10 a Next.js y a los frameworks de renderizado del lado del servidor full stack más ampliamente es una muy buena manera de comenzar con la seguridad porque estos son los problemas más comunes. Así que si eres capaz de remediar las 10 principales vulnerabilidades, ya tienes una aplicación muy segura. Así que descubramos este top 10, y tratemos de pensar cómo podemos aplicarlo a Next.js.

Número 10, falsificación de solicitudes del lado del servidor, SSRF. Estas siglas son realmente buenos ejercicios de pronunciación para hablantes no nativos como yo, y también una especie de pesadilla diaria, pero de todos modos. La idea es que permites al usuario pasar una URL y lanzas la solicitud a esta URL desde tu propio servidor. El problema es que el atacante entonces se beneficia de los privilegios de tu servidor. Así que una aplicación de ejemplo podría ser que estás creando un servicio de resumen de IA. Entonces el usuario pasa una URL de un sitio web y tú creas un resumen del contenido del sitio web. La cuestión es que también podrían elegir pasar la URL a localhost, y localhost no será su computadora sino tu servidor en este caso. Así que pueden comenzar a lanzar una solicitud desde tu servidor a tu propia infraestructura privada, a otros servicios en tu infraestructura, por ejemplo, tu base de datos u otros servicios privados similares. Así que es una mala. No estoy necesariamente dando soluciones a cada problema. Lo siento, porque cada una de estas vulnerabilidades o familias de vulnerabilidades requeriría su propia charla. Pero al menos me gustaría que estuvieras al tanto de la existencia de estos ataques si estás desarrollando aplicaciones similares. Y luego puedes trabajar en las remediaciones.

Pasemos al número nueve, fallos en el registro y monitoreo de seguridad. Básicamente estás registrando basura, pero no información. Este es muy importante porque si no configuras adecuadamente tu sistema de registro, ni siquiera ves los ataques. Así que esa es realmente la base de un sistema de seguridad, poder decir cuándo tienes un ataque. No es tan obvio. Así que podrías querer tener registros que estén más enfocados en la parte crítica de tu aplicación como pagos, creación de cuentas, inicio de sesión, que son realmente conocidos por ser puntos de entrada para atacantes.

Número ocho, fallos de integridad de software y datos. Es uno muy amplio. Así que tus dependencias son hackeadas, tu CI es hackeado. Ejecutas código de usuario deserializado. Básicamente cualquier cosa que podría ayudar a tener código malicioso en tu aplicación. No solo inyección. La inyección es una vulnerabilidad específica, pero más ampliamente ejecutar malware desde tu aplicación. Los ataques a la cadena de suministro son muy populares en estos días. Así que esto es cuando una de tus dependencias es hackeada. Son populares porque son muy eficientes para el atacante. Solo hackeas una aplicación y de repente has hackeado todas las aplicaciones que están usando una dependencia.

Así que esto es una locura para un atacante. Pueden tener un impacto realmente grande. Así que esto es realmente algo de lo que estar consciente. Especialmente al usar paquetes npm, por ejemplo, antes de instalar tu paquete, podrías querer verificar el repositorio de GitHub. ¿Es pronto? ¿Está actualizado? ¿Hay algunas pruebas? Cosas así. Deberías estar consciente de lo que estás usando en tu aplicación.

Número siete, fallos de identificación y autenticación. Tu contraseña de administrador es robada. Es como la idea, la idea más común que tenemos de un problema de seguridad es que la contraseña es robada. Sí, realmente típico. Estás en problemas. Así que ten cuidado con las contraseñas.

Número seis, componentes vulnerables y desactualizados relacionados con dependencias, problemas con dependencias y ataques a la cadena de suministro. Así que si nunca actualizas tu aplicación y surge un CVE conocido, CVE significa vulnerabilidad común y exposiciones. Es una vulnerabilidad documentada. Se sabe que está en una base de datos pública. Hay personas que mantienen tales bases de datos. Así que la cuestión es, ¿tiene el atacante simplemente la receta para ejecutar un ataque? Y es un poco tu culpa porque no actualizaste tu aplicación. Por ejemplo, Next.js tenía una vulnerabilidad conocida, una vulnerabilidad SSRF de la que hemos hablado anteriormente, número 10 en nuestra lista. Así que necesitas evitar la versión 40.1.0. Necesitas 14.1.1 al menos para evitar esta vulnerabilidad. Así que podrías querer mantener tu aplicación Next.js actualizada, no necesariamente a la última versión, pero al menos a una versión que no tenga esta vulnerabilidad.

Bien, estamos entrando en el top cinco. Voy a intentar mostrar un ejemplo más elaborado para este top cinco. El orden es en términos de popularidad. Así que el top cinco son los más populares entre estos ataques y vulnerabilidades. Top cinco, mala configuración de seguridad. Configuras un usuario administrador predeterminado, va a producción. O no usas los encabezados de seguridad adecuados. La cosa del administrador es muy común cuando estás haciendo seeding.

La siembra es llenar una base de datos con datos básicos para que puedas comenzar con una aplicación. Debes tener mucho cuidado al sembrar el usuario administrador. No debería suceder en producción. En producción, deberías tener un sistema más elaborado para crear el usuario administrador en primer lugar. Los encabezados de seguridad son realmente interesantes también para los desarrolladores front-end porque aprendes mucho. No estamos familiarizados con los encabezados de seguridad como desarrolladores de React. Esto está realmente lejos de tu trabajo. Así que no quieres que esta mala configuración sea explotada.

Por ejemplo, aquí están los encabezados que estoy usando en mi blog técnico personal. Y la cuestión es que no escribí esta configuración yo mismo. De hecho, estoy usando un blog template de Lee Robinson de Vercel. Así que es una muy mala práctica simplemente copiar y pegar la configuración así sin al menos darle un vistazo. Y al leer esta configuración, he aprendido mucho. Así que fue realmente interesante. No estaba perdiendo mi tiempo. Por ejemplo, he aprendido sobre Content Security Policy. Este es un encabezado que puede prevenir la ejecución de ciertas características, características de JavaScript, en tu sitio web como ejecutar eval script, que es un vector común de ataques. Así que es bueno tener una buena Content Security Policy. Lo he ajustado un poco en mi propio sitio web.

Otro que he aprendido es el strict transport security al final. Básicamente, le dice a los navegadores que usen HTTPS para tu sitio web. Si está bien configurado, esto previene que la primera conexión a tu sitio web use HTTP. HTTP es realmente malo porque permite ataques de man-in-the-middle. Un pirata podría interceptar la conexión, leer el contenido y alterarlo. Así que con HTTPS, estás evitando muchas vulnerabilidades. Así que este encabezado es muy importante. La política de permisos también es interesante porque no previene técnicamente los ataques, pero reduce el alcance y la gravedad de un posible ataque. En este ejemplo, no permitirá el uso de cámara, micrófono geolocalización, que no necesito en mi blog personal. Así que si alguien de alguna manera intenta y logra ejecutar un ataque de inyección en mi sitio web, para ejecutar JavaScript en mi blog personal, no podrán activar tu cámara. El navegador lo impedirá.

Así que estamos reduciendo la criticidad de un ataque y eso es algo muy, muy importante que hacer en el contexto de asegurar una aplicación.

En esta imagen, estoy usando el HSTS, los acrónimos son realmente horribles para los no nativos de todos modos, estoy verificando el encabezado de strict transport security con este servicio de Google. Aquí he notado que el sitio web de mi empresa no estaba configurado correctamente. No es una vulnerabilidad, pero aún así es algo que podría mejorar para hacer mi aplicación personal más segura. Así que buen progreso. Vamos al número cuatro, diseño inseguro.

Realmente me gusta este porque es simplemente que tu código es malo y deberías sentirte mal. También es bastante amplio. En realidad, no es exactamente tu código, no es tu código el que es malo, es realmente el diseño, la arquitectura de tu aplicación lo que está en esta vulnerabilidad. La cuestión es que aunque tu código no tenga errores, incluso si es perfecto, si la arquitectura en sí está fallando, no está funcionando. Conducirá a fallos y brechas de seguridad. Así que para evitar eso, podrías querer leer artículos sobre las mejores prácticas en HTS.

Por ejemplo, cómo pensar en la seguridad en HTS de Sebastian Marpage, del equipo oficial de Vercel, por supuesto. Algunos consejos fueron separar la capa de acceso a datos, para que puedas aislar el código que se comunica con tu base de datos en un área específica de tu aplicación HTS. Esa es una muy buena práctica. Facilita la auditoría. Facilita la detección de problemas de seguridad. Este es un buen diseño que previene problemas de seguridad. Necesitas validar las entradas de los usuarios y más ampliamente, seguir los recursos de aprendizaje oficiales evitará un mal diseño en tu aplicación HTS. Vas a escribir lo que podemos llamar código HTS idiomático. Es realmente importante entender cómo los diseñadores del framework están pensando sobre el framework en sí, para usarlo de la manera que piensan que podrías querer o deberías tal vez usarlo. De esta manera, estás evitando muchos errores que pueden ocurrir.

Número tres, inyección. Por ejemplo, dejas que los usuarios publiquen imágenes. Eso es lo básico de tener un sistema de foro o tal vez una sección de comentarios en tu blog. Pero en lugar de publicar una imagen, el atacante publicará una URL que apunta a un script que recopila cookies. Malo. Realmente malo. Porque cualquier usuario que cargue la imagen será hackeado. Este es el tipo de ataque como la cadena de suministro, donde el atacante intentará ampliar el alcance del ataque.

Sabes, intentarán atacar a muchos usuarios, todos los usuarios finales de tu sitio web y no solo tu sitio web. Así que son realmente malos. De hecho, este script de inyección de imágenes se está volviendo muy poco común porque los navegadores hoy en día están previniendo este tipo de ataques. Así que para simularlo, tuve que implementar realmente otro tipo de ataque. Estoy haciendo un poco de trampa en esta ilustración. Pero implementé una demostración de ataque CSRF, que es la contraparte del lado del cliente de la falsificación de solicitudes del lado del servidor.

En la falsificación de solicitudes del lado del servidor, el atacante forzará a tu servidor a enviar una solicitud a tu infraestructura. En la falsificación de solicitudes del lado del cliente, es aún peor. Honestamente, están forzando al navegador del usuario a enviar una solicitud. Así que típicamente aquí, en lugar de mostrar una imagen, la URL será API transfer money to attacker ID. Bien, así que todos los que muestren esta imagen tendrán su cuenta hackeada y activarán una transferencia, una transferencia de dinero al atacante. Y dado que la solicitud se envía desde su navegador, estará autenticada. Así que funcionará. El atacante no tiene que robar tu contraseña. Solo te obligan a enviar la solicitud. Hoy en día, creo que este es el tipo de ataques de los que realmente deberías estar consciente. Es muy popular. Es muy fuerte. Cuando sucede, realmente puedes eludir todas las seguridades de tu sistema. Es realmente malo para los usuarios finales. Así que CSRF es realmente una vulnerabilidad interesante si quieres profundizar más.

Número dos, fallos criptográficos. Por ejemplo, digamos que eliges tu algoritmo de cifrado de contraseñas de un post de Medium. O ni siquiera cifras las contraseñas que almacenas en la base de datos. Realmente eres una mala persona si haces eso en 2024. Es realmente malo. No deberías hacer eso. Incluso si crees que tienes buenas razones para hacerlo en tu empresa, no las tienes. No deberías hacer eso. Es una falta de respeto para el usuario final.

Y así eliges tu algoritmo de cifrado, pero resulta ser reversible. Alguien que robe la base de datos y la clave secreta puede entonces descifrar la contraseña inmediatamente. Normalmente, deberías estar, en la mayoría de las situaciones, usando un algoritmo de cifrado que no sea reversible. Un algoritmo de hash. Los algoritmos de hash no son reversibles. Así que no almacenas la contraseña, solo almacenas un hash de ella. Y cuando el usuario inicia sesión, haces un hash de lo que escriben y comparas los hashes. Nunca manipulas la contraseña real. Solo el usuario puede iniciar sesión escribiendo su contraseña.

Es interesante. Nos enfrentamos a esto en las encuestas del estado de JavaScript, no con contraseñas, afortunadamente, sino con correos electrónicos. No queremos almacenar correos electrónicos, incluso si no son tan sensibles como las contraseñas, por supuesto. Son un gran problema. No queremos que la gente sea spam si nuestra base de datos es robada. También son datos personales, así que es molesto de gestionar desde un punto de vista legal. Vivo en Europa. Así que hacemos un hash del correo electrónico, pero inicialmente, teníamos un algoritmo inadecuado. Estábamos cifrando el correo electrónico, pero era posible revertir el cifrado usando la clave y robando la base de datos.

No puedo revertir este hash. Así que estamos seguros.

Finalmente, control de acceso roto. Digamos que las personas pueden acceder a las cuentas de otras personas en tu aplicación. Esto es malo. No necesito explicar que es muy malo.

Entonces, de nuevo, una categoría muy amplia. Pero, por ejemplo, volvamos a nuestro faultgen en una aplicación AGS. Autenticando desde layouts. Resulta que no funciona porque los layouts en AGS, por diseño, esto no es una vulnerabilidad. Por diseño, pueden ser eludidos. Puedes forzar la renderización de la página bajo un layout. No está garantizado que un layout se renderice sistemáticamente antes que una página. Y eso, de nuevo, por diseño. Este es el punto de los layouts en AGS. Así que al usar el encabezado RSC configurado en uno, puedes observar el contenido de la página. Puedes saltar la autenticación del layout que demostré aquí. Así que tienes un problema de control de acceso roto que está ligado a un mal diseño en tu aplicación. En su lugar, deberías verificar la autenticación en las páginas. Y los mantenedores de Vercel y AGS aconsejan verificar la autenticación donde obtienes los datos. Básicamente, cada vez que te comuniques con tu base de datos. Para evitar este problema.

Bien. Así que hemos terminado con nuestro top 10. ¿A dónde ir ahora? ¿Qué hacer ahora? Primero, podrías querer seguir educándote. Ya lo hiciste muy bien al ver esta charla. Es realmente genial que ahora estés al tanto de los riesgos de seguridad más comunes y cómo pueden ocurrir en la vida real. Next.js reacciona a través de aplicaciones de renderizado del lado del servidor de pila completa. Estar más educado hace la vida del atacante bastante difícil. Luego puedes mejorar tus herramientas. Sé que muchas grandes startups están trabajando en herramientas de seguridad más enfocadas y eficientes. En el sentido de que funcionan mejor para pequeñas empresas que no tienen los presupuestos para investigar cualquier tipo de problemas de seguridad teóricos. En su lugar, se enfocan en vulnerabilidades reales que tienes en tu aplicación. Así que podrías querer seguirles la pista.

Gracias por ver esta charla. Tienes una larga lista de referencias al final de las diapositivas que podrías querer explorar más tarde. Mantente seguro. Adiós. Adiós.