Control de acceso roto

Por qué importa

La autenticación responde a quién eres. La autorización responde a qué tienes permitido hacer. El control de acceso roto es lo que ocurre cuando una aplicación comprueba lo primero y olvida lo segundo. Es el fallo grave más común en la web, y por eso OWASP lo movió al número uno del Top 10 de 2021, y a menudo es la clase más fácil de encontrar para un principiante, porque la explotación puede ser tan simple como cambiar un valor en una petición.

Tipos comunes

• IDOR y BOLA: intercambia el identificador de un objeto y recibe los datos de otro usuario. Consulta IDOR y BOLA.
• Escalada vertical de privilegios: un usuario normal alcanza funcionalidad de administrador que no debería. Consulta escalada de privilegios.
• Navegación forzada: navegar directamente a endpoints ocultos o sin enlazar que nunca debieron ser alcanzables.
• Manipulación de métodos HTTP: un verbo sin vigilar como HEAD u OPTIONS evade un control fijado solo para GET y POST.
• Bypass basado en cabeceras: falsificar X-Forwarded-For: 127.0.0.1 o usar X-Original-URL para derrotar una restricción de IP o de ruta y convertir un 403 en un 200.

Un ejemplo práctico

Una petición a /api/admin/backup devuelve 403 Forbidden con el mensaje "se requiere IP de administrador". Añadir la cabecera X-Forwarded-For: 127.0.0.1 devuelve 200 OK con el archivo de copia de seguridad, porque el servidor confía en una cabecera de IP suministrada por el cliente que nunca validó. Por separado, cambiar userId=123 por userId=124 devuelve el perfil de otro usuario porque el servidor confirmó que la sesión era válida pero nunca comprobó la propiedad del objeto. Ambos son control de acceso roto, encontrados mediante manipulación de parámetros y manipulación de cabeceras en un proxy como Burp Suite.

Cómo probarlo

El método fiable usa dos cuentas. Inicia sesión como Usuario A, captura una petición que alcance uno de sus objetos y luego reenvíala con la sesión del Usuario B, o simplemente intercambia el identificador, y comprueba si vuelven los datos del Usuario A. Prueba cada acción CRUD, no solo las lecturas, ya que la actualización y el borrado suelen estar menos protegidos. Intenta alcanzar endpoints de administración como usuario normal, acceder a la aplicación sin ninguna sesión y combinar los bypasses de método y de cabecera de arriba. Un control que aguanta para un GET puede fallar para un DELETE.

Impacto

Como el control de acceso gobierna cada objeto y cada acción, un solo fallo puede exponer los datos de todos los usuarios, permitir la toma de control de cuentas o conceder el control administrativo. Los incidentes reales van desde leer las facturas de otros clientes hasta la extracción masiva de datos a través de un único identificador enumerable, y por eso los equipos de triaje clasifican estos hallazgos de forma sistemática como muy graves.

Prevención

Deniega por defecto y concede de forma explícita. Impón autorización del lado del servidor en cada petición, verifica la propiedad del objeto en lugar de solo el estado de sesión, aplica controles a todos los métodos y nunca confíes en cabeceras suministradas por el cliente para la identidad ni en URLs ocultas para la protección. Centraliza la lógica, prueba con varias cuentas y alerta sobre los accesos que cruzan los límites entre usuarios.