La primera brecha de seguridad

Hace unos días mientras avanzaba en uno de los proyectos en los que actualmente estamos trabajando, me di cuenta que de la nada algunos recursos dejaron de aparecer. Inicialmente pensé que la Key de la API que estamos consumiendo había caducado, después de comprobar que esta no era la causa de la desaparición de los datos, revise directamente la base de datos y como me lo temía, los datos no estaban, alguien había accedido a funciones de la API que aún ni estaban implementadas en el cliente.

Ya que tenemos la introducción, vayamos a los detalles.

Estructura

Para este proyecto, decidimos hacer una Serverless Web App.

AWS Amplify es el elegido para hacer la función del Backend gracias al bajo costo por el uso y la reducción de los tiempos de desarrollo.

AWS Amplify nos proporciona la implementación de varios servicios de AWS que usamos, como:

• Cognito para la autenticación de los administradores de la aplicación.
• S3 para el almacenamiento de las imagenes.
• DynamoDB para guardar los datos.
• AppSync para la gestión de los datos, ¿ya había mencionado que AppSync te permite crear una GraphQL API en un par de minutos? Bueno, lo hace, tu tarea solo será escribir el Schema y AppSync se encargará de crear todas las Queries, Mutations y Types.

Por la otra parte, en el lado del cliente, utilizamos NextJS, un Framework de ReactJS. Y si se pregunta, ¿Por qué NextJS y no solo ReactJS? Creo que eso da para un artículo completo, así que aquí lo resumire en que NextJS al hacer SSR, reduce los tiempos de carga y nos ayuda con el SEO.

Para que se hagan una mejor idea de como luce la estructura, les dejo el diagrama.

La brecha

Si han usado AWS Amplify, habrán notado que al momento de publicar o actualizar la API, aparece una advertencia diciendoles que en el Schema, al modelo le agreguen un @auth, bueno… no lo agregue.

Y si se preguntan, ¿de que sirve agregar el @auth? Bueno, la respuesta es bastante obvia (a pesar de que no lo agregue). Al momento de agregarlo, estan definiendo las reglas de acceso al modelo completo o a ciertas operaciones, lo puedo resumir en un acrónimo, CRUD.

Al no estar presente, significa que el método de autenticación para realizar cualquier acción será la API Key, esto permite que cualquiera que la posea puede crear, actualizar o borrar entradas de la base de datos… y no, no es tan complicado obtenerla, ya que siempre se encuentra presente para por ejemplo poder traer los datos de los productos de la aplicación.

Ahora que ya sabemos como pudieron eliminar los datos de la base de datos, ¿cúal es la solución?

Solución

Exacto, así como lo acaban de imaginar, es simplemente agregar el @auth para comenzar a definir las reglas de acceso.

Bueno, no es literalmente solo agregar el @auth, también hay que agregar un User Pool de Cognito como método de autorización en AppSync pero eso lo podemos abordar en otro artículo sobre como asegurar AppSync para no dejar de lado ningún detalle.

Lo ideal en la mayoría de los casos es permitir que los usuarios sin sesión únicamente lean datos y que no puedan alterarlos, podría ser más complejo como permitir que solo el usuario que creo el registro sea capaz de modificarlo pero en este caso basta con que los usuarios sin sesión no puedan realizar modificaciones. Las politicas de acceso quedan así:

De esta forma, solo la operación de lectura sera accesible por medio de la API Key, mientras que todas las demás operaciones serán accesibles cuando exista una sesión.

Esta fue la forma en como solucionamos (temporalmente) la brecha de seguridad en la plataforma.

Una última cosa antes de terminar ¿por que puse “temporalmente”? Bueno, siempre podemos contar con que alguien pueda encontrar una nueva brecha, nada es 100% seguro, se pueden prevenir brechas, pero nunca asegurar que el sistema es impenetrable.