IDOR (Insecure Direct Object Reference)
Practica de explotación IDOR
IDOR
Vamos a poner que tenemos la siguiente pagina web:
reset_password.php
send_password.php
Vemos que en estos 2
archivos no valida que el usuario sea el legitimo a nivel de peticion, por lo que si se modifica alguna peticion con otra informacion, el servidor no lo valida y confia en lo que le llegue por lo que podremos cambiar la password
del usuario admin
.
Estando dentro de la pagina le daremos a ¿Olvidaste tu contraseña?
con las credenciales por defecto que viene en la pagina user:user
poniendo eso, veremos que entraremos en una apartado en el que tendremos que poner la nueva contraseña para dicho usuario, pero en esta parte abriremos BurpSuite
y capturaremos la peticion del cambio de contraseña, viendo algo asi:
Veremos que hay 2
campos, uno que es para el usuario y otro para la contraseña, el que nos interesa es el del usuario, cambiaremos user
por admin
para que se le cambie la contraseña a admin
, enviaremos dicha peticion modificada y si volvemos a la pagina veremos lo siguiente:
Ahora si probamos a iniciar sesion con el usuario admin
veremos que nos deja, por lo que habremos aprovechado dicha vulnerabilidad.
Explicación detallada IDOR
IDOR
Vulnerabilidad IDOR (Insecure Direct Object Reference)
¿Qué es IDOR?
IDOR (Insecure Direct Object Reference) es una vulnerabilidad de control de acceso que ocurre cuando un usuario puede acceder directamente a recursos o datos que no deberían estar disponibles para él, debido a la falta de validación adecuada en el backend.
El problema surge cuando una aplicación expone identificadores de objetos en la URL o en los parámetros de solicitud, permitiendo que un atacante modifique estos valores y acceda a información de otros usuarios sin la autorización adecuada.
Ejemplo de IDOR
Escenario Vulnerable
Imagina un sistema de tickets de soporte donde cada usuario puede ver sus propias solicitudes de ayuda accediendo a una URL como esta:
Si el usuario cambia manualmente el ID en la URL por otro número, como:
Y obtiene acceso a un ticket que no le pertenece, entonces la aplicación es vulnerable a IDOR porque no verifica si el usuario tiene permisos para ver ese recurso.
Impactos de la vulnerabilidad IDOR
Fuga de información confidencial: Un atacante puede acceder a datos privados de otros usuarios, como correos electrónicos, direcciones, facturas o documentos sensibles.
Modificación de datos ajenos: Si el IDOR no solo permite leer información, sino también modificarla, un atacante podría cambiar contraseñas, modificar registros o eliminar información crítica.
Escalada de privilegios: En algunos casos, si el atacante tiene acceso a identificadores de recursos administrativos, podría modificar su cuenta y obtener privilegios más altos.
Robo de identidad y fraude: Al acceder a datos personales, un atacante podría suplantar la identidad de otros usuarios o cometer fraudes financieros.
Payloads y Bypasses para IDOR
Aquí tienes una tabla con ejemplos de payloads y técnicas de bypass utilizadas para explotar esta vulnerabilidad:
Descripción
Payload/Bypass
Explicación
Cambio de ID en la URL
https://web.com/perfil?id=1000
→ id=1001
Se cambia el ID manualmente en la URL para acceder a la cuenta de otro usuario.
Manipulación en parámetros POST
id=1000
→ id=1001
en el cuerpo de una petición POST
Si el ID es enviado en una solicitud POST, se puede modificar en el request.
Cambio de ID en encabezados HTTP
X-User-ID: 1000
→ X-User-ID: 1001
Algunas aplicaciones usan encabezados personalizados para identificar usuarios.
Uso de técnicas de enumeración
id=1
, id=2
, id=3
, id=4
...
Se prueban IDs secuenciales para encontrar datos expuestos.
ID codificado en Base64
id=MTIzNA==
(Base64 de 1234) → MTIzNQ==
(1235)
Si los IDs están en Base64, se pueden decodificar, modificar y volver a codificar.
Uso de parámetros secundarios
id=1000&role=admin
Algunos sistemas permiten modificar roles o permisos mediante parámetros.
Cambio de método HTTP
GET /user/1000
→ POST /user/1000
Si la API no valida correctamente el método HTTP, un atacante podría modificar datos.
Sustitución de token de usuario
Authorization: Bearer TOKEN1234
→ TOKEN1235
Si el token se basa en un identificador predecible, puede ser reemplazado.
Cambio en cookies
userID=1000
→ userID=1001
Algunas aplicaciones guardan el ID del usuario en cookies sin validación.
Uso de GraphQL
{ user(id: "1000") { name, email } }
→ { user(id: "1001") { name, email } }
GraphQL puede permitir acceso a datos no autorizados si no se valida correctamente.
Cómo prevenir la vulnerabilidad IDOR
Para evitar esta vulnerabilidad, se deben implementar controles de acceso adecuados en el backend y evitar confiar en los datos enviados por el cliente.
1. Validación de permisos en el servidor
Nunca confíes en los datos proporcionados por el usuario. Antes de devolver información, verifica si el usuario tiene permiso para acceder a ese recurso.
Ejemplo en PHP:
2. Uso de identificadores aleatorios y UUIDs
Evita usar identificadores predecibles como números secuenciales. En su lugar, utiliza identificadores aleatorios o UUIDs:
3. Autenticación y autorización adecuadas
Implementa control de acceso basado en roles (RBAC).
Usa tokens de sesión seguros para identificar usuarios.
Restringe el acceso a recursos mediante políticas en el backend.
4. Registros y monitoreo
Registra intentos sospechosos de acceso a recursos.
Implementa alertas cuando un usuario acceda a demasiados recursos en un corto periodo de tiempo.
5. Protección en API REST y GraphQL
Usa middleware de autenticación para verificar cada solicitud.
Implementa reglas de acceso a nivel de API para cada endpoint.
Conclusión
La vulnerabilidad IDOR es una de las fallas más comunes y peligrosas en aplicaciones web. Si una aplicación no valida correctamente los permisos antes de otorgar acceso a un recurso, un atacante puede aprovecharse de esta falla para obtener información sensible, modificar datos o incluso escalar privilegios.
Para mitigar esta vulnerabilidad, es crucial validar los permisos en el servidor, utilizar identificadores aleatorios, implementar controles de acceso y monitorear actividades sospechosas.
Last updated