Broken Access Control con Burp Suite

El Broken Access Control es el riesgo más crítico del OWASP Top 10, catalogado como A01, y aparece cuando una aplicación permite a un usuario ejecutar acciones fuera de los límites que le corresponden. Si trabajas en desarrollo, pentesting o seguridad de aplicaciones, entender este fallo te ayuda a proteger datos sensibles y evitar escaladas de privilegios.

A continuación verás cómo se manifiesta, qué impacto real ha tenido y cómo detectarlo y corregirlo con una práctica guiada usando Burp Suite.

¿Qué es Broken Access Control y por qué es el riesgo A01?

Es una falla que rompe el principio de mínimo privilegio: un usuario logra hacer algo que su rol no debería permitirle. La filosofía correcta para evitarlo es zero trust, es decir, denegar todo por defecto y habilitar solo lo necesario.

¿Qué significa A01 en OWASP? Es el código que identifica al riesgo número uno del Top 10 de OWASP, el más crítico, y corresponde a Broken Access Control.

¿Cómo se ve este fallo en una aplicación real?

Las formas más comunes en las que aparece son tres y conviene reconocerlas en cualquier auditoría:

• Modificación de URLs: cambiar un ID de curso en la URL para acceder a contenido no autorizado, o manipular una variable como action para crear, editar o eliminar registros.
• APIs sin control de acceso: una petición GET a una orden con un ID numérico (por ejemplo el 10) que puede iterarse y automatizarse para extraer información ajena.
• Violación del mínimo privilegio: permitir más acciones de las necesarias a un rol determinado.

¿Qué impacto tiene un Broken Access Control mal gestionado?

El caso de Confluence Server lo ilustra bien. Los ciberdelincuentes explotaron la vulnerabilidad CVE-2023-22515, asociada justamente a Broken Access Control, y lograron desplegar ransomware dentro de la organización afectada, cifrando información y datos sensibles.

No se trata de un riesgo teórico. Cuando alguien rompe el control de acceso, puede leer datos privados, modificar registros o tomar control administrativo total de la aplicación.

¿Cómo mitigar Broken Access Control en tus aplicaciones?

Los controles que funcionan se aplican en arquitectura, código y monitoreo. Estos son los que conviene implementar:

• Denegación por defecto: permite solo lo estrictamente necesario para cada usuario o rol.
• Políticas de control de acceso por rol o grupo: defínelas desde la arquitectura, no como un parche posterior.
• Evita directorios navegables: una falla recurrente que expone información del web server o servicios internos.
• Monitorea actividad sensible: revisa cuándo se crea, edita o elimina un registro.
• Aplica rate limits en APIs: por ejemplo, 50 requests por minuto y bloqueo automático al superar el umbral.
• Configura expiración de JWT: si dejas tokens sin caducidad, abres la puerta a ataques de suplantación.

¿Qué es zero trust en control de acceso? Es un modelo donde se niega todo acceso por defecto y solo se habilita lo necesario para cada rol, validando cada petición.

¿Cómo detectar Broken Access Control con Burp Suite?

La práctica se hace sobre una aplicación web vulnerable que simula una plataforma de aprendizaje con dos perfiles: administrador y usuario normal. Con Burp Suite interceptando todas las peticiones, el flujo es así:

1. Iniciar sesión como admin y confirmar que ve el listado completo de usuarios (admin, user1, user2).
2. Cerrar sesión e ingresar como user1, un usuario con menos privilegios.
3. Apuntar al endpoint del listado de usuarios. La aplicación responde no autorizado.
4. En Burp, revisar la petición del login exitoso de user1 y encontrar una cadena sospechosa en las cookies.
5. Decodificar esa cadena en Base64: aparece un campo de rol con valor user.
6. Cambiar user por admin, codificar de nuevo en Base64 y reenviar la petición desde Repeater.
7. La aplicación devuelve el listado completo: el usuario normal ahora tiene privilegios de administrador.

Ahí está la falla: el rol se valida a nivel de cookie, algo que el cliente puede manipular.

¿Cómo corregir el fallo desde el código?

La solución es mover la validación del rol al backend. En el archivo users/index.js se ajusta la lógica para consultar el rol directamente desde la tabla de usuarios en base de datos, no desde la cookie enviada por el cliente.

Al reenviar la misma petición manipulada desde Burp, la respuesta cambia a no autorizado. El control quedó aplicado.

¿Por qué validar el rol en base de datos y no en cookie? Porque las cookies viajan en el cliente y pueden modificarse. La base de datos es la fuente confiable que el atacante no controla.

Palabras clave que aparecen en la clase y conviene dominar: zero trust, mínimo privilegio, rate limit, JWT, Base64, Burp Suite, Repeater, CVE-2023-22515 y directorios navegables. Cada una representa una pieza concreta del rompecabezas de seguridad en aplicaciones web.

¿Ya descargaste la aplicación vulnerable para probar estos controles tú mismo? Cuéntame en los comentarios qué fallas encontraste y cómo las corregiste.