Aplicaciones Vue y Nuxt más seguras - Por defecto

o ingenieros de DevOps. Pero hoy en día, cada vez más funcionalidad se está trasladando al front-end. Y es por eso que creo que todos deberían preocuparse por la seguridad. Y también es por eso que he seleccionado este tema para mi presentación de hoy, que son las aplicaciones más seguras de Next de forma predeterminada. Mi nombre es Jakub y trabajo en Allokai como desarrollador senior y defensor. Además de eso, también soy un experto desarrollador de Google en performance web. Soy parte del equipo de Next y también soy embajador de Algolia, Storyblok, Cloudinary y SuperBase. Así que, después de esta presentación, serán unos ninjas de la seguridad. Suena genial, ¿verdad? Pero la realidad es que no es posible. No es posible transferirles todo el conocimiento de seguridad que es necesario para construir aplicaciones seguras desde cero. Entonces, mi idea es hacerlos más conscientes de los riesgos y problemas que pueden aparecer en las aplicaciones web modernas. Porque creo que si están conscientes de estos problemas, podrán proteger su aplicación contra ellos.

Para eso, les recomendaría que se familiaricen con el concepto de OWASP y específicamente OWASP Top 10. OWASP es un documento de concientización estándar tanto para desarrolladores como para seguridad web, especialistas en seguridad de aplicaciones web, y representa un amplio consenso sobre los riesgos de seguridad más críticos para las aplicaciones web. Y como pueden ver, marqué dos lugares aquí. Uno es el documento de concientización estándar, lo que básicamente significa que este OWASP Top 10 es un documento. Y el segundo, riesgos de seguridad. Entonces, es un documento que les mostrará los riesgos de seguridad más populares. OWASP Top 10 también es reconocido por los desarrolladores como el primer paso hacia una codificación más segura. Esta vez también, marcado con color verde, primer paso. Entonces, no deberían considerar OWASP Top 10 como la única solución para hacer que su aplicación sea más segura. Más bien es un primer paso. Como un primer paso sólido. Entonces, si miran el sitio web de OWASP Top 10, verán básicamente esto. Y si nos acercamos un poco, veremos esta lista de los riesgos de seguridad más populares que pueden aparecer en su aplicación web. Y como pueden ver en el

En el lado izquierdo, tenemos 2017, y en el lado derecho, está 2021. Y pueden ver que la lista, tanto el orden como los elementos de la lista, están cambiando. Lo que significa que esta lista está en constante evolución. Todo el tiempo. Porque están apareciendo nuevos problemas o nuevos riesgos y tenemos que hacer que nuestras aplicaciones sean cada vez más seguras en función de los entornos cambiantes. Y también hay un recurso grande, muy grande de conocimiento en términos de hacer que su aplicación sea más segura en el sitio web de OWASP, que básicamente es una lista de listas de verificación, como hojas de trucos, que pueden revisar para ver si su aplicación es segura en un área determinada. Entonces, por ejemplo, tenemos una hoja de trucos para aplicaciones REST, aplicaciones GraphQL, aplicaciones construidas con Ruby, y así sucesivamente.

Entonces, echemos un vistazo a algunos de estos riesgos de seguridad. No vamos a ver todos ellos, nos centraremos solo en algunos seleccionados. Así que, en primer lugar, tenemos las inyecciones. Y los dos principales ataques aquí, o riesgos, son la ejecución de código en sitios cruzados e inyecciones SQL. Y en términos de inyecciones SQL, podrían pensar que esta es una vulnerabilidad muy antigua y que ya no aparece, pero se sorprenderían de cuántos sitios web en producción todavía tienen este tipo de vulnerabilidad. Entonces, en ambos casos, la idea es que el atacante inyecta algún tipo de código malicioso ya sea en SQL, en nuestra base de datos, o en las aplicaciones a través de JavaScript, por ejemplo, y luego este código malicioso básicamente obtiene los datos a los que no debería tener acceso, como usuarios, contraseñas, cosas así. Yendo más allá, tenemos el control de acceso roto. El control de acceso significa que nuestra aplicación permitirá obtener ciertos datos si estamos debidamente autorizados. Entonces, por ejemplo, si estamos conectados o somos parte de una organización o grupo que tiene acceso a cierto recurso. Entonces, el control de acceso roto significa que el atacante puede tener acceso a los datos que básicamente no debería tener. Y mi favorito, que es DOS o DDoS, que significa denegación de servicio, significa que nuestra aplicación se ejecuta en un servidor que solo puede manejar una cierta cantidad de solicitudes. Entonces, si el atacante logra enviar demasiadas solicitudes, nuestra aplicación no podrá responder a estas solicitudes y básicamente se rendirá. Entonces, tenemos DOS, que es la denegación de servicio, y DDoS, que es como la denegación de servicio distribuida, que es el enrutamiento se distribuye entre muchos dispositivos zombi llamados así. Pueden ser teléfonos móviles, pueden ser dispositivos de escritorio, y así sucesivamente. Y tengo un caso interesante adicional, que se llama paquetes maliciosos de NPM y confusión de dependencias. Esto puede sucederle a cualquier persona que esté construyendo aplicaciones web en la actualidad. Entonces, cómo funciona es básicamente que tenemos un usuario que se supone que debe obtener un paquete que está almacenado en un registro privado, como un registro privado de NPM. Podría ser otra cosa. La idea es que este registro es privado y solo los usuarios autorizados deberían tener acceso a él, deberían poder obtener este paquete. Entonces, lo que hace el usuario en cambio, de manera involuntaria, es obtener el paquete con el mismo nombre, pero desde el registro público, como el público de NPM. Y este paquete puede contener un código malicioso. Y este es un caso real. Y esto, desafortunadamente,

esto está en polaco. El artículo está en polaco, pero puedes buscar los que están en inglés para paquetes NPM maliciosos. Entonces, en este caso, lo que fue la recompensa, porque hay algunos, hay estos desafíos para hackers éticos, que básicamente pueden detectar las vulnerabilidades y obtener recompensas por ello. Entonces, el autor de este ataque logró crear estos paquetes para empresas grandes y populares, como PayPal, Microsoft, Apple, Shopify, Netflix, Tesla o Uber. Así que, grandes empresas. Y este código, lo que hacía, era hacer algo llamado shell inversa. Y esta shell inversa básicamente podía ejecutar comandos en tu dispositivo, de forma remota. Entonces, alguien podía operar o ejecutar comandos en tu computadora portátil o en tu dispositivo de forma remota, por completo. Y la recompensa fue de aproximadamente $130,000 por tal recompensa. Así que, bastante dinero. En cuanto a asegurar tus aplicaciones, siempre digo que las API nativas del navegador son tu mejor ayuda. Entonces, comencemos con los encabezados de seguridad HTTP. La forma en que funcionan es básicamente en el servidor, enviamos esos encabezados de respuesta de seguridad para informar al navegador lo que puede hacer. Entonces, en este caso, por ejemplo, podemos indicarle que solo puede funcionar con HTTPS, que no puede usar el micrófono, como todos los diferentes tipos de servicios, como el micrófono, la geolocalización, la cámara, y así sucesivamente. Y que los recursos en este sitio web, en este navegador, en este sitio web en particular, solo pueden obtener recursos de cierto dominio u origen. Así es como funcionan. Tenemos el nombre del encabezado y el valor. Es posible que hayas oído hablar de la política de seguridad de contenido o las opciones de XFrame, la seguridad de transporte estricta. En realidad, hay bastantes de ellos. Pero la idea es que podemos configurarlos en el servidor para indicarle al navegador lo que puede hacer. Pero esto funciona con aplicaciones de servidor, las aplicaciones que tienen un servidor. Entonces, ¿qué podemos hacer si nuestra aplicación es estática? Podemos usar algo llamado HTTP AQUIF. Espero haberlo pronunciado correctamente. Lo que hace es que podemos configurarlo como una etiqueta meta. Entonces, podemos hacerlo en nuestras aplicaciones estáticas en el puro frontend. Y de alguna manera podemos emular el encabezado de respuesta que se enviaría desde el servidor. En este ejemplo en particular, estamos emulando el encabezado de política de seguridad de contenido. Y lo estamos pasando como contenido, el mismo valor que normalmente se enviaría desde el servidor. También podemos configurar permisos del navegador. Y estos permisos del navegador básicamente nos permiten

desactivar ciertas API que se pueden habilitar en el lado del cliente. Entonces, en este caso particular, estamos mostrando la geolocalización. Entonces, si el servidor envía el encabezado de respuesta de la política de permisos con el valor geolocalización con estos corchetes, básicamente, si intentamos acceder a la geolocalización del usuario, este es el code en el medio, obtendremos el error de que la geolocalización ha sido desactivada en este documento por la política de permisos. A continuación, tenemos la autenticación básica. Entonces, la autenticación básica permite al usuario acceder al sitio web solo si proporciona las credenciales correctas. La forma en que funciona es que el servidor envía el encabezado www authenticate con el valor básico realm y el valor de este reino. Y luego los clientes, el cliente que desea authenticate necesita enviar un encabezado de autorización con un básico y estas credenciales. Es como usualmente usuario y contraseña. Y si estas credenciales son correctas, ese usuario puede acceder a este sitio web. De lo contrario, obtendrán un error 401. Pero por favor, no uses este tipo de ejemplo de nombre de usuario y contraseña si tienes la intención de tener este tipo de credenciales para tu autenticación básica. También puedes omitirlo. Porque esto no protege a nadie ni a nada.

Entonces, ¿cómo podemos hacer que las aplicaciones Vue y Nuxt sean más seguras? Hay hojas de trucos muy buenas, tanto en el sitio web de documentación de Vue.js como en la hoja de trucos de seguridad de HTML, que básicamente enumera todas las cosas que puedes hacer en el frontend, en el lado del cliente, para hacer que tu aplicación sea más segura, lo cual te recomiendo encarecidamente que consultes. Sin embargo, si echamos un vistazo a Nuxt, tenemos acceso al módulo de seguridad de Nuxt, que básicamente utiliza OWASP y configura tu aplicación automáticamente para que siga los patrones y recomendaciones de seguridad de OWASP para hacer que tu aplicación sea más segura por defecto. Y lo hace utilizando los encabezados HTTP, algunos de los que ya te mostré, y también el middleware.

Entonces, sin ninguna configuración, Nuxt security viene con encabezados de respuesta de security que funcionan tanto para aplicaciones SSR como SSG, como aplicaciones del lado del servidor y aplicaciones estáticas. Viene con el middleware para limitadores de tamaño y velocidad de solicitud, que básicamente protege tu aplicación de demasiadas solicitudes y solicitudes demasiado grandes. Tenemos acceso a la validación de scripting entre sitios, que nos protege de situaciones en las que alguien envíe código malicioso a través de solicitudes GET o POST. Tenemos acceso al intercambio de recursos de origen cruzado, que es como un curso en resumen, donde podemos decidir desde dónde esta aplicación puede obtener los datos, desde qué orígenes. También podemos usar el middleware para los métodos HTTP permitidos, donde podemos decidir qué métodos están permitidos para ciertos puntos finales. Entonces, en ciertos puntos finales, es posible que solo queramos habilitar solicitudes POST o eliminar o GET. Y también tenemos soporte para la protección contra falsificación de solicitudes entre sitios.

Pasemos a la demostración. Tengo aquí una aplicación Nuxt en ejecución, que básicamente es una aplicación Nuxt muy simple. No tiene ninguna biblioteca de UI, no tiene ningún componente. Es solo una simple aplicación de Hola Mundo Nuxt. Entonces, si la inspeccionamos en el navegador, veremos esta página de bienvenida de Nuxt. Y ahora, si la inspeccionamos, vamos a la red y actualizamos la página. Aquí, veremos los encabezados de respuesta. Tenemos conexión, longitud del contenido, tipo de contenido,

fecha, x powered by. ¿Qué sucederá cuando habilitamos o descomentamos el módulo de seguridad de Nuxt es que cuando inspeccionemos este mismo documento, ahora veremos que la sección de encabezados de respuesta es mucho más grande. Tenemos encabezados de seguridad para una política de seguridad de contenido, una política de apertura de origen cruzado, una política de permisos y muchos más configurados automáticamente para nosotros, según las recomendaciones de OWASP. Esto viene por defecto en términos de encabezados de respuesta. También tenemos acceso a la validación de scripting entre sitios, lo que básicamente significa que si decimos texto y aquí decimos script, digamos alerta uno, y lo cerramos, script, así, lo que sucederá Olvidé que necesita ser un parámetro. es que obtendremos una solicitud de error 400. Esto básicamente significa que esta validación subyacente de scripting entre sitios desencadena este texto que enviamos en esta solicitud GET como un código malicioso. Bien, esto es sobre algunas de las características. Para otras, necesitaría pasar alguna configuración. Entonces, aquí, en el archivo config.ts de Nuxt, generalmente pasamos alguna configuración ya sea a Nuxt framework o a los modules que forman parte de nuestra aplicación. Tenemos acceso al objeto de security, donde podemos configurar toda nuestra configuración de seguridad de Nuxt. Entonces, aquí, tengo acceso también a los encabezados donde puedo decir, por ejemplo, que quiero que la protección X-XSS sea uno. Y si inspeccionamos el navegador, pero ahora sin esto, veremos que ahora la protección X-XSS es uno. Entonces, cambiémoslo a cero. Y vemos que se ha cambiado. Configurar encabezados de esta manera es global. Esto significa que estos encabezados se configurarán globalmente de esta manera. Sin embargo, con el módulo de seguridad de Nuxt security, también tenemos acceso a reglas de ruta. Entonces, lo que puede suceder es que podemos hacer reglas de ruta, pasar nuestra ruta. Digamos secreto. Y aquí, podemos decir security. Y lo mismo que antes, encabezados. Y aquí, podemos decir X-XSS protección uno. Esto significa que para la ruta con slash secreto, el valor del encabezado X-XSS protección se establecerá en uno. Y esto funciona para todos los encabezados y para todas las funcionalidades de middleware que forman parte del módulo. Quiero mostrarte una cosa más.

Aquí, lo que haré es configurar el limitador de tasa. Y diré tokens por intervalo. Y lo estableceré en cinco. Y el intervalo, lo estableceré en, digamos, 10 segundos.

Entonces, lo que sucederá ahora es que si comienzas a hacer spam en el botón de actualización aquí, después de algunas solicitudes, seremos bloqueados. Y veremos que hay demasiadas solicitudes, de cuatro a nueve. De acuerdo. Así que, el módulo viene con mucho, mucho más. Tenemos acceso a ALF básico, como mencioné, la falsificación de solicitudes entre sitios y muchas, muchas más. Así que asegúrate de consultar la documentación de seguridad de Nuxt para aprovechar al máximo estas características. Permíteme volver a la presentación. Esto es solo la punta del iceberg en términos de patrones de seguridad. Y quiero decirte que no existen sistemas infranqueables. Solo existen aquellos que son tan difíciles o que requieren tanto tiempo para romper que los atacantes básicamente se rinden. Así que mi recomendación para ti es ser uno de esos sistemas. Sé uno de esos sistemas que son difíciles de romper para que los atacantes se rindan. Muchas gracias por estar aquí conmigo. Asegúrate de consultar la seguridad de Nuxt. Si hay algo que creas que falta en el módulo o que se podría mejorar, solo avísanos a través de problemas o discusiones. Siempre estamos abiertos a recibir comentarios. Y si quieres contactarme en algún lugar, asegúrate de hacerlo a través de X o DevTool. Estoy allí como Jacob Andrewski. También tengo un canal de YouTube llamado Jacob, igual que en GitHub. Así que, gracias por recibirme y disfruta el resto de la conferencia.

Entonces, con respecto a la pregunta que publicaste en la encuesta, era cuáles son los tres problemas de seguridad más populares en la última edición de los documentos OWASP Top 10. En algún momento, el público tenía razón porque Jacob en realidad hizo una trampa y quería decir que los tres son respuestas válidas. En algún momento, tuvimos un 50-50. Pero ahora, sí, las personas que eligieron el control de acceso roto están equivocadas, las inyecciones están equivocadas y las fallas criptográficas están equivocadas porque son los tres al mismo tiempo. Así que fue una pregunta trampa. Pero está bien. Volvamos y pasemos a algunas preguntas y respuestas. De todas las preguntas que tuvimos, una de las más interesantes es si hay herramientas para probar mi aplicación Nuxt en busca de problemas de seguridad. Claro. Primero, puedes simplemente escribir securityheaders.com. Este sitio web te permitirá auditar tu sitio web en busca de encabezados de seguridad y si cumplen con los valores recomendados. Funciona de manera similar a Lighthouse, por ejemplo, o page speed.dev, donde ingresas una URL que deseas auditar. Pero en este caso, se trata de rendimiento. Pero en nuestro caso, se trata de la validación de los encabezados de seguridad. Así que, sin duda, securityheaders.com. No tengo más en este momento, pero probablemente si buscas en Google un escáner de encabezados de seguridad, probablemente encontrarás más herramientas que te puedan dar la respuesta correcta. De acuerdo. Tiene sentido. Otra pregunta que tenemos es una de las mías, pero sigue siendo la más votada. ¿Crees que un desarrollador frontend debería conocer estas preocupaciones de seguridad en absoluto? Sí, diría que es igualmente importante. No de la manera en que como desarrollador frontend, estarás desarrollando la misma cantidad de regulaciones o protecciones de seguridad para tu aplicación. Es más bien si estás consciente de los problemas de seguridad que pueden aparecer en las aplicaciones web modernas, es menos probable que filtres algún tipo de información. Puede ser un token de acceso. Puede ser una página que solo debería estar disponible para un usuario que tenga los derechos apropiados. Así que siempre creo que si estás consciente de estos problemas, problemas de seguridad, es menos probable que tengas este tipo de riesgos en tu aplicación web, incluso como desarrollador frontend. Porque inicialmente, cuando pensamos en el desarrollo frontend, pensamos en estilos, en HTML, tal vez en algunas animaciones. Pero honestamente, hoy en día, cada vez más lógica se está trasladando al frontend. Tenemos frameworks como Next, donde básicamente podemos construir aplicaciones de pila completa con él. Entonces, considerando que estos frameworks son principalmente frontend, también tienen un poco de backend, estos desarrolladores frontend necesitan tener este conocimiento de seguridad, al menos el básico de los riesgos. Es posible que no necesites entender cada riesgo y conocer todas las protecciones de seguridad, pero si estás consciente de estos riesgos, es menos probable que los tengas en tu aplicación web.

Sí. También suelo tener muchas personas en Stack Overflow que preguntan, hey, tengo este token. ¿Qué hago con él? ¿Cómo lo oculto? Y a veces lo complicado es que tienes tokens públicos y privados. Entonces, dependiendo de eso, necesitas encontrar una manera de lidiar con eso. Así que, sí, lo que suelo recomendar a esas personas es simplemente, hey, probablemente tengas un equipo de backend. Ve y habla con la gente allí, para que te puedan explicar un poco más. Porque, de lo contrario, si tomas un token privado con algo de dinero o algún servicio detrás, sí, puede ser un poco complicado. ¿Qué hay de la seguridad de NUC y las aplicaciones SSG, como las aplicaciones de generador estático?

Sí, claro. Entonces, si pensamos en la seguridad en general, generalmente pensamos en aplicaciones que involucran algún tipo de servidor. Porque, por ejemplo, incluso con los encabezados de respuesta, como su nombre sugiere, son encabezados de respuesta. Entonces, deben ser enviados desde el servidor al cliente y el cliente, cuando recibe estos encabezados, el navegador sabe cómo comportarse. Pero con la seguridad de NUC, también la implementamos de tal manera que incluso si tu aplicación es estática, como una aplicación SSG estática, aún puedes beneficiarte de ciertas mejoras de seguridad del módulo. En primer lugar, obtienes la política de seguridad de contenido como un HTTP EQIF, creo que lo pronuncio correctamente, como la etiqueta meta. Y esto es una cosa. Y una cosa más es que también obtienes el soporte para eliminar los registros de consola. Esta es una pequeña función de utilidad que permite ocultar los registros de consola, los depuradores de consola y otros métodos de consola que podrías olvidar mientras desarrollas. He tenido situaciones en las que tal vez no filtré información, pero dejé algunos registros de consola en lugares donde no deberían estar.

De acuerdo. De acuerdo, de acuerdo. Supongo que eso es todo. Muchas gracias de nuevo. Si tienes alguna otra pregunta, si no se respondieron, puedes ir a Discord, puedes preguntar allí. Y algunos oradores ya han dado respuestas sobre temas anteriores. Así que, sí, si realmente quieres obtener la respuesta, siéntete libre de hacer lo mismo. Así que, gracias de nuevo por tu participación, Jacob. Te deseo un día increíble. Continuemos con la conferencia. Gracias. Nos vemos.