A01:2025 Pérdida de Control de Acceso (Broken Access Control)

Antecedentes

Manteniendo su posición en el #1 del Top Ten, se encontró que el 100% de las aplicaciones probadas tenían alguna forma de pérdida de control de acceso. Los CWE notables incluidos son CWE-200: Exposición de Información Sensible a un Actor no Autorizado, CWE-201: Exposición de Información Sensible a Través de Datos Enviados, CWE-918: Falsificación de Solicitud del Lado del Servidor (SSRF), y CWE-352: Falsificación de Solicitud en Sitios Cruzados (CSRF). Esta categoría tiene el mayor número de ocurrencias en los datos aportados y el segundo número más alto de CVE relacionados.

Tabla de puntuación

CWE Mapeados	Tasa de Incidencia Máx.	Tasa de Incidencia Prom.	Cobertura Máx.	Cobertura Prom.	Explotación Ponderada Prom.	Impacto Ponderado Prom.	Ocurrencias Totales	CVE Totales
40	20.15%	3.74%	100.00%	42.93%	7.04	3.84	1,839,701	32,654

Descripción

El control de acceso aplica políticas de tal manera que los usuarios no puedan actuar fuera de sus permisos previstos. Las fallas suelen conducir a la divulgación no autorizada de información, la modificación o destrucción de todos los datos, o la ejecución de una función de negocio fuera de los límites del usuario. Las vulnerabilidades comunes de control de acceso incluyen:

Violación del principio de mínimo privilegio, comúnmente conocido como denegar por defecto, donde el acceso solo debe otorgarse para capacidades, roles o usuarios específicos, pero está disponible para cualquier persona.
Elusión de los controles de acceso mediante la modificación de la URL (manipulación de parámetros o navegación forzada), el estado interno de la aplicación o la página HTML, o mediante el uso de una herramienta de ataque que modifique las solicitudes a la API.
Permitir ver o editar la cuenta de otra persona proporcionando su identificador único (referencias directas inseguras a objetos o Insecure Direct Object References, IDOR).
Una API accesible con falta de controles de acceso para POST, PUT y DELETE.
Elevación de privilegio. Actuar como un usuario sin haber iniciado sesión o ganar privilegios más allá de los esperados para el usuario autenticado (por ejemplo, acceso de administrador).
Manipulación de metadatos, como la repetición o manipulación de un token de control de acceso JSON Web Token (JWT), una cookie o un campo oculto manipulado para elevar privilegios, o el abuso de la invalidación de JWT.
La desconfiguración de CORS permite el acceso a la API desde orígenes no autorizados o no confiables.
Navegación forzada (adivinar URLs) hacia páginas autenticadas como un usuario no autenticado o hacia páginas privilegiadas como un usuario estándar.

Cómo prevenir

El control de acceso solo es efectivo cuando se implementa en código del lado del servidor de confianza o en APIs sin servidor (serverless), donde el atacante no puede modificar la comprobación del control de acceso o los metadatos.

Excepto para recursos públicos, denegar por defecto.
Implementar mecanismos de control de acceso una sola vez y reutilizarlos en toda la aplicación, incluyendo la minimización del uso del Intercambio de Recursos de Origen Cruzado (Cross-Origin Resource Sharing, CORS).
Los controles de acceso del modelo deben imponer la propiedad de los registros en lugar de permitir que los usuarios creen, lean, actualicen o eliminen cualquier registro.
Los requisitos únicos de límites de negocio de la aplicación deben ser aplicados por los modelos de dominio.
Desactivar el listado de directorios del servidor web y asegurarse de que los metadatos de los archivos (por ejemplo, .git) y los archivos de respaldo no estén presentes dentro de las raíces web.
Registrar las fallas de control de acceso, alertar a los administradores cuando sea apropiado (por ejemplo: fallas repetidas).
Implementar límites de tasa (límites de velocidad - rate limits) en el acceso a la API y a los controladores para minimizar el daño de las herramientas de ataque automatizadas.
Los identificadores de sesión con estado deben invalidarse en el servidor tras el cierre de sesión. Los tokens JWT sin estado deben ser de corta duración para minimizar la ventana de oportunidad de un atacante. Para JWT de mayor duración, considere el uso de tokens de actualización (refresh tokens) y siga los estándares de OAuth para revocar el acceso.
Utilizar kits de herramientas o patrones bien establecidos que proporcionen controles de acceso sencillos y declarativos.

Los desarrolladores y el personal de control de calidad (QA) deben incluir el control de acceso funcional en sus pruebas unitarias y de integración.

Escenarios de ejemplo de ataque

Escenario #1: La aplicación utiliza datos no verificados en una llamada SQL que accede a la información de la cuenta:

pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );

Un atacante puede simplemente modificar el parámetro 'acct' del navegador para enviar cualquier número de cuenta deseado. Si no se verifica correctamente, el atacante puede acceder a la cuenta de cualquier usuario.

https://example.com/app/accountInfo?acct=notmyacct

Escenario #2: Un atacante simplemente fuerza a los navegadores a dirigirse a URLs específicas. Se requieren derechos de administrador para acceder a la página de administración.

https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo

Si un usuario no autenticado puede acceder a cualquiera de las páginas, es una falla. Si un usuario que no es administrador puede acceder a la página de administración, esto es una falla.

Escenario #3: Una aplicación pone todo su control de acceso en su front-end. Aunque el atacante no puede llegar a https://example.com/app/admin_getappInfo debido al código JavaScript que se ejecuta en el navegador, simplemente puede ejecutar:

$ curl https://example.com/app/admin_getappInfo

desde la línea de comandos.