Un dev ataca su propia API en AWS y documenta qué se rompe sin controles
Despliega la misma API de tareas dos veces en una cuenta de AWS, una sin seguridad y otra endurecida, y la ataca desde su terminal. El repositorio trae Terraform y los scripts.
Un desarrollador ha desplegado la misma API de tareas dos veces sobre una única cuenta de AWS: una versión sin ningún control de seguridad y otra endurecida como la entregaría a un cliente. Luego lanzó los ataques contra ambas desde su propio terminal y publicó qué se rompió y qué aguantó. El repositorio incluye el código, los ficheros de Terraform y los scripts de ataque, así que se puede reproducir tal cual.
La lógica de negocio es deliberadamente aburrida: crear una tarea, listarlas, leer una, actualizarla y borrarla. Lo interesante está alrededor. Las dos versiones comparten la misma forma, cliente hacia API Gateway, Lambda y DynamoDB; lo que cambia es qué se coloca entre las piezas y qué puede hacer cada una. El autor apunta al modelo de responsabilidad compartida de AWS: la nube pone los centros de datos, el hipervisor y la red troncal, pero la autenticación de tu API, tus permisos de IAM y tus límites de peticiones son tuyos. Las pruebas se hicieron sobre recursos propios, dentro de lo que permite la política de pentesting de AWS para cuentas que uno controla.
Sin autenticación, la tabla entera
El primer ataque es el más simple y no requiere ninguna habilidad. La ruta de listado de la versión vulnerable ejecuta un scan sobre la tabla completa, sin filtrar por usuario, porque la ruta ni siquiera sabe quién llama y no hay autenticación. Con tareas creadas para dos usuarios ficticios, una petición anónima devolvió todo el conjunto de datos.
En la versión endurecida, un Lambda Authorizer valida un token firmado antes de que la petición llegue al handler. La respuesta es un 401 y la petición no toca la tabla. Cuando llama un usuario autenticado de verdad, el handler consulta únicamente sus propias tareas a través de un índice de DynamoDB, de modo que ni una llamada legítima devuelve datos ajenos.
El script que se queda guardado
El segundo ataque es XSS almacenado. La versión vulnerable escribe lo que recibe sin tocarlo, así que el autor manda <script>alert(document.cookie)</script> como título de la tarea y el payload acaba guardado en DynamoDB tal cual. Hoy ninguna parte de esa API renderiza HTML, de modo que el script está ahí quieto. El problema llegará el día que alguien monte un frontend que pinte ese campo: entonces se ejecutará en el navegador del visitante como si fuera contenido propio de la página. La vulnerabilidad no está en un frontend que todavía no existe, sino en la API que nunca debió aceptar ese texto sin validarlo.
El valor de la pieza no está en ninguna de las dos fallas por separado, que son de manual, sino en el diff entre los dos despliegues sobre la misma cuenta. El documento de lecciones aprendidas recoge el resto y los scripts permiten montarlo en tu propio laboratorio para ver hasta dónde llega cada versión antes de fiarse de la frase de que estar en la nube ya es estar seguro.
