Broken Access Control (BAC)
Última actualización
Última actualización
Esta falla ocurre cuando los mecanismos que restringen lo que un usuario puede o no puede hacer dentro del sistema están mal diseñados, mal implementados o simplemente ausentes. El resultado: usuarios no autorizados pueden acceder a recursos sensibles o realizar acciones que deberían estar fuera de su alcance.
El ejemplo más sencillo es: "un usuario de bajos privilegios puede ejecutar tareas administrativas que no debería"
En esencia, los controles de acceso rotos permiten que un atacante salte las restricciones de seguridad y obtenga acceso no autorizado a datos, funciones o configuraciones que deberían estar protegidas.
Disclaimer Los casos y ejemplos mostrados en esta sección forman parte de auditorías y evaluaciones de seguridad realizadas en el contexto de proyectos profesionales con . No se divulga información sensible, interna o específica de ningún cliente, y se ha tenido especial cuidado en proteger su confidencialidad. Además, cualquier vulnerabilidad mencionada o ilustrada en estos ejemplos ya ha sido corregida de manera responsable, siguiendo los procesos adecuados de remediación y comunicación con los respectivos equipos. Este contenido es compartido únicamente con fines educativos y de mejora continua en prácticas de seguridad.
Cabe destacar que el Broken Access Control se considera un conjunto amplio de vulnerabilidades relacionadas con los problemas de control de acceso. En base a esto, se puede decir que un también es un Broken Access Control, sin embargo, dada su forma de explotación, a través de identificadores de objetos, se le conoce más bien con otro nombre.
Según el OWASP Top 10 2021, Broken Access Control es la categoría más alta en el ranking, y puedo dar fé que es de las vulnerabilidades que más se detectan en auditorías, esto también incluye al .
Cuando esta vulnerabilidad es explotada exitosamente, puede tener consecuencias catastróficas:
Acceso no autorizado: Visualización o modificación de datos confidenciales, como información de usuarios, archivos internos o configuraciones críticas.
Escalada de privilegios: Usuarios comunes que obtienen accesos administrativos o privilegios elevados, comprometiendo la integridad de todo el sistema.
Robo y exposición de datos: Información sensible puede ser extraída y vendida, filtrada o utilizada para otros ataques.
En este caso tenía una aplicación Web, la cual al iniciar sesión con un usuario de bajos privilegios observaba lo siguiente:
Por detrás, lo que ocurre a la hora de consultar los permisos es lo siguiente:
HTTP Request:
HTTP Response:
Como se aprecia, la mayoría de los "módulos" son controlados por un booleano "false/true", y ahí es donde automáticamente tenés que preguntarte, ¿Y si cambio a true esto?.
Para ello hacemos uso de Match And Replace, un módulo de Burp Suite súper útil para estas cosas y configuramos una regla para que la palabra false se cambie por true en los body de respuestas:
Luego, recargando la página nuevamente el Match And Replace entra en juego y reemplaza todo lo que estaba en false por true:
Una vez que esto se aplique, cuando cargamos de nuevo la página tendremos la vista de un administrador:
Desde aquí ya podemos acceder a la sección de Usuarios y crearnos un nuevo usuario administrador y tener acceso completo a la plataforma.
Es importante mencionar que en algunos casos, solo veremos el template base de ciertas funcionalidades, pero si se controlan los permisos por backend no podremos realizar acciones con lo que no existiría la vulnerabilidad como tal a menos que podamos ver información y ejecutar acciones.
Siempre ver la respuesta de las solicitudes y ver si hay opciones por cambiar, por ejemplo, is_admin=false, ¿qué pasa si lo cambio?
Match And Replace tiene que ser tu mejor amigo. Si vemos que una página devuelve 401 Unauthorized ¿qué pasa si lo cambio por 200 OK?
Intentar acceder directamente a las rutas, ¿qué pasa si como usuario de bajos privilegios accedo a /api/admin/list_users?
Siempre pensar en la escalada de privilegios a través de funcionalidades, como cambiar el rol, cambiar el correo, el username, cambiar un id_tenant (cross-tenant).
Analizar todas las funcionalidades posibles y preguntarnos “¿qué debería y qué no debería hacer mi usuario actual?”
Diseñar e implementar controles de acceso efectivos: Es crucial asegurarse de que cada usuario pueda acceder únicamente a los recursos y datos que le corresponden. Esto implica aplicar mecanismos sólidos de autenticación y, sobre todo, de autorización que verifiquen los permisos de cada acción solicitada.
Validar y autorizar todas las solicitudes del lado del servidor: Cada solicitud debe pasar por un control estricto que valide si el usuario tiene permisos para ejecutar la acción. Aunque pueden aplicarse validaciones del lado del cliente para mejorar la experiencia de usuario, la validación del lado del servidor es imprescindible. La ausencia de esta validación representa una puerta abierta a accesos no autorizados.
Aplicar el principio de privilegio mínimo: Asigna a cada usuario únicamente los permisos necesarios para desempeñar su rol. Esta estrategia minimiza el impacto en caso de que una cuenta se vea comprometida, y previene accesos indebidos que podrían explotarse mediante vulnerabilidades como IDOR.
