Micro-Frontend Security Guide

Hola a todos, y bienvenidos a la sesión sobre micro-frontends y seguridad. Espero que hayan tenido una gran conferencia hasta ahora, y espero también traerles ahora algunas ideas sobre cómo desarrollar su solución de micro-frontend con la seguridad en mente.

Antes de comenzar, solo unas pocas palabras sobre mi persona. Soy Florian, o en resumen, simplemente Flo. Soy un arquitecto de soluciones que trabaja para una empresa más pequeña aquí en el área de Múnich en Alemania. Estamos especializados en la creación de plataformas IoT y aplicaciones web distribuidas en general. También realizamos algunas masterclass y revisiones. Así que si tienen, digamos, cualquier tipo de demanda en esas áreas, quieren alguna consultoría general o están pensando en adentrarse en los micro-frontends, entonces siempre siéntanse libres de contactarme o enviarme un mensaje en LinkedIn. Ahora, suficientes palabras sobre mí. Vamos a sumergirnos directamente en el tema.

Y una cosa que siempre me gusta, por supuesto, mostrar, y esto será, digamos, la guía también para la sesión de hoy, es echar un vistazo al OWASP top 10. Así que esta es una lista de las vulnerabilidades de seguridad más, digamos, críticas y más utilizadas en el sector de aplicaciones web. Y actualizan esta lista con bastante regularidad. Y lo que pueden ver aquí es la lista más reciente disponible. Y he traído cuatro temas de esta lista donde podemos, digamos, identificar lo que generalmente sale mal en las soluciones de micro-frontend y lo que podemos hacer para mitigar esas vulnerabilidades y vectores de ataque que naturalmente ocurren.

Así que comencemos ahora mismo con el tercero, que son las inyecciones. Los sistemas de micro-frontend son muy a menudo muy abiertos a ataques de inyección porque esto es de lo que se tratan los micro-frontends. Estamos inyectando código que, digamos, no está directamente compuesto en tiempo de construcción, sino que se compondrá en tiempo de ejecución. Muy naturalmente, tendrás que enfrentar ataques de inyección o vectores de ataque que necesitas mitigar. Y vamos a echar un vistazo a eso.

El otro área es mirar el diseño inseguro porque muy a menudo, por supuesto, te abres con estas, digamos, composiciones en tiempo de ejecución a un diseño inseguro, lo que significa que de repente permites tal vez a otros ejecutar su código, lo cual al principio parece bien. Pero, ¿cómo puedes asegurar que el código que fue publicado por alguien ahora es realmente el código que fue publicado por esta, sí, persona de confianza? Y muy similar, pero por supuesto, ligeramente diferente, es la configuración incorrecta de seguridad. Así que aquí tratamos en un área donde decimos, ¿cómo podemos configurar el sistema de tal manera que aunque necesitábamos abrir la puerta en algunas áreas, no esté tan abierta como, bueno, potencialmente puede estar, de modo que, por ejemplo, puedan ocurrir ataques de intermediarios, o que pueda haber algunas modificaciones en el camino desde, digamos, un servidor al navegador del usuario, por ejemplo.

Y lo que quiero comenzar con, y esa será el primer área que miramos, es esencialmente, bueno, los buenos y viejos fallos de identificación y autenticación. Entonces, ¿cómo puedes asegurar que autenticas a tus usuarios, y estos son realmente los usuarios que queremos tener, queremos ver, además, por supuesto, los datos, potencialmente, digamos, tokens, por ejemplo, no se pierden, o llegan, bueno, a manos de alguien con quien no quieres compartir el token. Así que echemos un vistazo allí, y comencemos con los fallos de autenticación.

El vector tecnológico que traje para la charla de hoy, solo tenemos 20 minutos, así que necesito ser rápido, es que usamos autenticación basada en tokens. Hay más vectores tecnológicos, pero yo, todas estas secciones que acabamos de cubrir, solo mencionaré un vector tecnológico para cada una. Ahora, para el vector tecnológico que seleccioné aquí, la autenticación basada en tokens es muy popular, ¿verdad? Si creas una aplicación de una sola página, entonces potencialmente usas un mecanismo como OAuth2 con un JWT, que es un token que generalmente es sin estado, por lo que puedes simplemente transportarlo. Y lo bueno es que puede ser creado por un sistema, pero múltiples sistemas pueden leerlo y pueden verificar que este es de hecho un usuario que fue autenticado correctamente por este único sistema que lo creó.

Bien, hasta ahora todo bien, eso suena genial, pero si tienes un sistema de micro-frontend, por supuesto, necesitas de alguna manera distribuir este JWT, por ejemplo, y aquí es donde comienzan los problemas, ¿verdad? Porque incluso si confías en todos tus micro-frontends y todas las cosas que aún hablaremos en esta sesión son, digamos, respetadas, quiero decir, todavía podría haber, digamos, un problema de implementación ocurriendo aquí. Y entonces, si este problema ocurre, podría ser, pero lo que sea, digamos, error que se cometió allí que envías el token como una solicitud a, digamos, un servidor web al que no deberías enviarlo. Esperemos que, por supuesto, entonces este servidor web no haga nada con esta información, pero en el peor de los casos, por supuesto, puede aparecer que este es también un servidor web malicioso. Tal vez todo este ataque fue de alguna manera, digamos, diseñado y ahora el token de tu usuario terminó en manos de un actor malicioso. Así que, si miramos eso desde un punto de vista diagramático, lo que ves aquí, tenemos nuestro sitio que está en el rectángulo azul y luego, por supuesto, estamos ejecutando tres micro-frontends en sus respectivos colores naranja, púrpura y verde. Y lo que ves es que, bueno, naranja y verde están bien. Están enviando el JWT a sus respectivas APIs, pero púrpura no lo está enviando a la API púrpura, sino a algún sitio malicioso aquí. Ahora, el sitio malicioso es, digamos, el propietario de ese JWT. Y eso no es realmente lo que queremos tener. Entonces, ¿qué podemos hacer aquí? ¿Cómo podemos mitigar eso? Bueno, hay varias cosas que hacer, pero siempre me gusta señalar una de las soluciones más simples, y en mi opinión, aquí está, simplemente usar cookies de sesión. Especialmente si estableces, por supuesto, la política al mismo sitio, lo que deberías hacer. Así que, restringes esto. Otra cosa que deberías hacer aquí es tenerlas solo HTTP y todos los canales HTTP seguros. Entonces estás realmente, digamos, bien. Así que, las cookies solo se intercambian en el mismo dominio bajo la circunstancia de que no es, digamos, visible dentro de tu código JavaScript. Y solo se intercambia, digamos, cuando tienes un canal seguro abierto. Así que, todo está genial entonces y no necesitas tener el token de autenticación. No necesitas distribuirlos entre tus micro-frontends.

Así que, bastante bien. Estamos listos aquí. Y si miras cómo el diagrama cambia, ahora ves que hay este gateway que ahora está entre el sitio web que está ejecutándose y las respectivas APIs de backend. Y el trabajo de este gateway que introdujimos aquí es doble. Por un lado, es, por supuesto, el guardián de las sesiones. Así que, recibe las sesiones y luego, por supuesto, puede hacer algo con estas sesiones. Por ejemplo, intercambiar la sesión por un JWT. Y la segunda cosa es que luego hace proxy de la solicitud a algún destino objetivo. Así que, generalmente es un proxy inverso y toma rutas que no, digamos, resuelve directamente. Pero luego hace proxy, por supuesto, detecta cuál es el objetivo. Que debería ser, por supuesto, un objetivo que configuramos previamente. Y luego simplemente reenvía el respectivo JWT con el resto de los detalles de la solicitud al objetivo. Así que, bastante bien. Y si ahora fueras a un sitio malicioso, quiero decir, no pasaría nada porque, bueno, la cookie no se envía aquí. Y, sí, no te importa, esencialmente. Aún no deberías ir allí. Pero, quiero decir, el vector de ataque está mitigado. Genial.

Ahora, en Codeform, lo que podríamos ver aquí es que teníamos un fetch antes y este otro servicio mycompany.com. Bueno, ahora simplemente vamos a API slash otro servicio, y ahora el gateway sabría que, por ejemplo, la solicitud final debería ser enviada a otro servicio de mycompany.com. Pero la parte importante, nuevamente, es que no mencionamos aquí un dominio porque debería ir al mismo origen. Así que, el dominio es implícito en este fetch. Y no necesitamos tener, ahora, este token. Así que, tampoco necesitamos preocuparnos de, por ejemplo, una actualización de token. Así que, en general, nuestro frontend ahora es un poco más simple que antes y también más seguro. Diría que siempre es una gran ventaja.

Pero hablando de, por supuesto, tener un frontend seguro, el diseño inseguro es el próximo problema que podría ocurrir, ¿verdad? Así que, ¿cómo podemos asegurar que no haya, bueno, al menos ningún ataque de man-in-the-middle desde, digamos, la fuente donde almacenamos nuestro micro frontend hasta el navegador? Ahora, hay varias razones por las que esto podría ocurrir, ¿verdad? Podría no ocurrir ni siquiera en, digamos, el canal de transporte entre, digamos, el punto de almacenamiento del micro frontend y el navegador. Pero podría incluso ocurrir que el almacenamiento, digamos, en sí mismo sea inseguro. Así que, no sé, alguien perdió la contraseña de, digamos, un Azure Blob Storage y localizas tu micro frontend allí. Ahora, por supuesto, si esa clave de acceso al Azure Blob Storage cae en las manos equivocadas, el contenido podría ser cambiado.

Pero hay una manera o hay múltiples maneras, nuevamente, de mitigar un escenario, como se describe aquí, donde dices, oh, ahora en lugar de obtener el micro frontend púrpura o el original púrpura, obtenemos este código JavaScript modificado. Entonces, las dos formas de hacerlo, y me gustaría hablar más sobre la última aquí, es tener firma de código, lo que significa que usas un enfoque que es muy similar a un JWT. Tú, digamos, tienes una clave pública y una privada, y a través de la clave privada, puedes, digamos, junto con, por ejemplo, el hash, poner algo en tu código que diga, bueno, si esto se cumple, el código está debidamente firmado, por lo que puedes leerlo más tarde, el código en sí todavía es totalmente legible, y junto con la clave pública, verificas que esto no ha sido alterado. Pero también hay una manera más simple, por lo que, por supuesto, eso también hace algunas suposiciones, y eso es simplemente transportar la integridad del archivo JavaScript, y esto es esencialmente solo la función hash utilizada en los contenidos binarios del archivo. Ahora, si obtenemos, por ejemplo, junto con la referencia que usualmente tenemos a un micrófono, esta integridad, entonces podemos, por supuesto, usarla para también verificar que el contenido no ha sido alterado. Cómo funciona eso es que usualmente tienes un servicio de descubrimiento de micrófono central, y colocas esto en el medio de tu arquitectura, de tal manera que tu aplicación no solo, digamos, obtenga las referencias al JavaScript, sino que también obtenga estos valores de integridad, y luego puedes instruir al navegador para que realmente use los valores de integridad, y asegurar, por lo tanto, que solo si no han sido alterados, se ejecutarán. Así que, bastante bien, y el navegador, en este caso, bloqueará el JavaScript modificado porque ve que hay una discrepancia entre lo que el servicio de descubrimiento dijo, lo que se subió originalmente, por supuesto, y lo que realmente recibimos. Y nuevamente, no importa si lo recibimos porque hay un problema con el canal de transporte, o porque alguien podría alterar el almacenamiento de los archivos. Y para nosotros, es algo bueno. En forma de código, podría verse así. Entonces, la primera parte es la respuesta de un servicio de descubrimiento. Nos dice el nombre del micrófono, la versión, también nos da, por supuesto, una referencia a él, y luego, lo más importante, nos da el valor para la integridad. Finalmente, si queremos ahora incrustar esto, lo pondremos en una etiqueta de script, y esto no estaría cableado como lo vemos aquí. Por supuesto, todo esto se hace programáticamente, pero la parte realmente crítica es que usamos el atributo de integridad que ya está, digamos, entendido por todos los navegadores evergreen, y estamos bien. El navegador no bloqueará la ejecución de este archivo si detecta que la integridad no se cumple. Muy bien, entonces, otro problema ha sido resuelto. Esto es genial. Quedan solo tantos y tantos, pero veamos los problemas uno a la vez, y continuemos con la inyección, ¿verdad? Como ya se mencionó, la inyección es algo que quieres tener, pero quieres restringirlo tanto como sea posible, siguiendo, por supuesto, el principio de menor privilegio, que no lo abras innecesariamente, sino solo hasta donde necesites abrirlo. Ahora, el vector de ataque que vemos en este aspecto es, bueno, por supuesto, podemos construir un vector de ataque en el navegador, pero tal vez cambiemos un poco aquí y digamos que ejecutamos microformance en el servidor. Ahora, aquí, por supuesto, tenemos bastantes vectores de ataque críticos que ocurren muy naturalmente porque, bueno, todo se ejecuta en nuestro, por ejemplo, servidor, por lo que podríamos tener acceso allí a alguna base de datos SQL. Podríamos acceder aquí a una caché de Redis o lo que sea. Así que, muchos, muchos recursos, las variables de entorno, que generalmente se usan y, por ejemplo, obtienen el acceso a algo como la base de datos SQL, son muy, muy sensibles. Así que, al final del día, lo que podríamos decir, si hay algún código inyectado, que, por ejemplo, puede entonces leer variables de entorno, también podría enviarlo a algún lugar. Ahora, aún podríamos argumentar, tal vez podamos seguir un modelo como DNO y restringir solicitudes HTTP no deseadas, pero digamos que somos Node.js, no tenemos tales opciones. Claro, aún podríamos proteger el servicio, pero luego hay muchos otros vectores aquí. Entonces, ¿cómo podemos prevenir esto en primer lugar? La respuesta en Node.js es que podemos usar sandboxing con el módulo VM. Esencialmente, esto nos permite realmente solo determinar qué cosas deberían ser accesibles desde un módulo cuando lo ejecutamos. Esto es genial porque entonces, por supuesto, recursos como, por ejemplo, acceder a fetch o acceder a alguna dependencia de terceros que pueda tener acceso a fetch pueden ser severamente restringidos, y no necesitas preocuparte por ninguno de esos. Aún mejor, puedes restringir desde el principio. Ni siquiera necesitas tener acceso, por ejemplo, a process EMV.

Puedes simplemente proporcionar tus propias variables de entorno solo para la evaluación de este módulo. Entonces, si miras un ejemplo aquí, y esto es realmente un ejemplo simple, simple, simple de lo que puedes hacer, pero para mostrarlo es que usamos del módulo VM para crear contexto y ejecutar en contexto, crear contexto, para crear un nuevo contexto de evaluación. Ponemos todo lo que el módulo necesita saber, cosas generales básicas como encontrar el nombre del trato, pero luego, por supuesto, tal vez también fundamentos de JavaScript como buffer, JSON, etcétera. Y luego la parte respectiva donde se pone interesante es process y require, ¿verdad? Porque el proceso en sí, entonces esta cosa tiene realmente algunas, bueno, digamos implicaciones sobre lo que podrías, bueno, saber en tu módulo. Entonces, deberías al menos proporcionar algo aquí, pero deberías, por supuesto, restringir algo como process EMV. Entonces, lo que vemos aquí, esto podría ser un buen punto de partida, pero aconsejaría no simplemente pasar todas las variables de process EMV. Así que esto es solo, digamos, tal vez un pequeño ejemplo de anti-patrón. Y la otra cosa es, por supuesto, tener la API completamente hecha y el custom require, no entramos en detalles aquí, pero potencialmente querrás permitir el uso de ciertas cosas, pero en general, no querrás tener, digamos, tal vez require cualquier cosa allí porque eso podría usarse para, por supuesto, entrar en territorio no deseado nuevamente. Y finalmente, si estás ejecutando contexto, la parte interesante es que puedes establecer un tiempo de espera que, bueno, esencialmente limita tu, cuánto tiempo puede ejecutarse un script. Y eso también es bueno porque no quieres que scripts deshonestos detengan tu servidor.

Muy bien. Entonces, la última sección de la que quiero hablar es la mala configuración en general. Aquí, el consejo general que quiero darte de antemano es siempre intenta usar tanto de los estándares web como sea posible. Entonces, si sabes, hay una cierta cosa, como tomemos course. No estoy hablando de course hoy, pero no deberías intentar evitarlo. Deberías adoptarlo y deberías más bien pensar, ¿cómo puedo usar mi course para encajar en mi solución de micro-formato y para seguir abriendo la puerta tanto como debería ser posible, pero no, bueno, tanto como sea necesario, pero no tanto como sea posible. Muy bien. Entonces, intentemos resumir esto. El vector de ataque que veo aquí es un script de terceros que, por supuesto, tenemos muchos. Usualmente tenemos muchas dependencias y tal script podría contener, por ejemplo, un key logger, ¿verdad? Quiero decir, no sabes cómo siempre hay paquetes NPM que se han vuelto deshonestos. Y siempre hay un poco de retraso hasta que la comunidad descubre que hay algo realmente malo sucediendo aquí. Y entonces, esto podría ser algo con lo que te encuentres. Simplemente actualizas tus dependencias y de repente tenemos un script deshonesto allí. Así que ni siquiera estamos afirmando que los equipos están cometiendo un error. Bueno, quiero decir, por supuesto, lo están, pero no están realmente cometiendo este error a sabiendas. Ahora, la pregunta es, ¿cómo podríamos, digamos, intervenir aquí? ¿Qué podemos hacer? Y, bueno, la primera cosa de la que me gustaría hablar, pero hay una segunda cosa que quiero introducir, es incluir una política de seguridad de contenido, porque eso limita la ejecución de solo código arbitrario. Y aunque ciertas cosas aún pueden ser posibles, otras cosas serán realmente, bueno, limitadas o no serán posibles en absoluto. Ahora, cómo funciona un CSP se explica bastante simplemente cuando el navegador envía una solicitud al servidor y el servidor responde a ella y puede adjuntar varios, digamos, encabezados. Y uno de estos encabezados es una política CSP que se puede agregar.

Puedes hacer un poco más, como incluir un servicio de informes. Así que, no, digamos, tratar las violaciones como errores, sino más bien como advertencias. Estas advertencias podrían enviarse a una URL. Así que, toda la sección inferior de este diagrama aquí es, digamos, por conveniencia o llamémoslo flexibilidad. Pero la parte superior, esto es realmente interesante porque aquí podemos configurar el navegador y cómo interpreta el acceso a los recursos. Y lo hace a través de este encabezado, como se mencionó. Este encabezado entonces consiste en el valor de diferentes políticas llamadas así. Así que, todo en una sección como esta entre los puntos y comas, eso es una política llamada así. Tenemos una política predeterminada. Entonces, ¿qué asumimos como una fuente predeterminada? Así que, self es siempre predeterminado. Así que, está bien. Luego, si viene de las mismas imágenes de origen, por ejemplo, permitimos todo. Eso podría ser dudoso, pero es solo como un ejemplo aquí. Para fuentes de medios como audio, video, tenemos algunos dominios permitidos y los scripts solo permitimos de los scripts de usuario principales, por ejemplo. Así que, ahora definimos nuestras políticas y el navegador las respetará. Así que, si tenemos un script deshonesto que potencialmente quiere incluir algo más de, no sé, danger.com, no sé, entonces esto no será permitido. Y también solo tener una función que se autoevalúe no será permitido aquí tampoco. Así que, esto es ya bastante bueno.

Genial. La segunda cosa que quiero mencionar antes de concluir es que también puedes mitigar aquí usando un servicio de descubrimiento como vimos antes. Y así, esto también es útil aquí porque lo que el servicio de descubrimiento puede hacer es escanear vulnerabilidades en tu micro. Así que, puede detectar qué paquetes se usan y luego puede trabajar contra las bases de datos con las vulnerabilidades conocidas. Y así, puede informarte cuando una de las dependencias que realmente estás usando tiene una vulnerabilidad. Así que, esto es realmente genial porque a diferencia de los informes de vulnerabilidad que obtienes de NPM, que también incluyen todas tus dependencias de desarrollo y todo, esto realmente trata solo con las dependencias de tiempo de ejecución. Y así, también obtendrás realmente, digamos, grandes informes. Así que, todo bien. Y así es como podría verse en un servicio de descubrimiento. Aquí vemos que todo está bien para, digamos, dependencias. Así que, bueno, bastante bien. Te informan y puedes incluso bloquear que estos micrófonos se desplieguen.

Así que, la conclusión que quiero sacar, lo primero es siempre probar todo. Es lo mismo que para cualquier otra aplicación web. Puedes incluso probar en, digamos, compartimentos más pequeños donde solo dices, probaré solo para este micrófono y hacerlo a través de pruebas de penetración. No será bueno, pero la solución como un todo, eso necesita ser sólido como una roca.

La segunda cosa, como vimos, un aspecto importante es siempre asegurar la autenticidad. Así que, asegúrate de que el micrófono no haya sido manipulado y sigue el principio de privilegio mínimo. Así que, necesitas abrirlo un poco, pero no más allá. Así que, este es el máximo que deberías alcanzar con tu solución.

Finalmente, y esto es algo de lo que no hablé aquí, pero eso, por supuesto, es algo que necesitas hacer, monitorear lo que está sucediendo en el tiempo de ejecución. Así que, todas las soluciones de registro que están ahí para el espacio de JavaScript, especialmente, utiliza tu favorita aquí. Realmente lo necesitas. Dado que esta cosa no está distribuida, es una gran manera también de obtener más información sobre cómo está funcionando tu aplicación en su conjunto. Con esto en mente, espero que aún tengas una gran conferencia y ponte en contacto si quieres saber más. Si quieres revisar el servicio de Discovery, escanea el código QR y de lo contrario, mantente fresco. Adiós.