Introducción
Las referencias directas a objetos inseguras (IDOR, por sus siglas en inglés) son un tipo de vulnerabilidad de control de acceso que surge cuando una aplicación utiliza entradas proporcionadas por el usuario para acceder a objetos directamente. Si la aplicación no verifica adecuadamente si el usuario que solicita el objeto tiene autorización para acceder a él, un atacante puede manipular la referencia (como un ID de base de datos, un nombre de archivo o un ID de usuario en una URL) para acceder a los datos confidenciales de otros usuarios.
La distinción importante es que la referencia en sí misma no es la vulnerabilidad. La vulnerabilidad reside en confiar en esa referencia sin comprobar si el usuario actual tiene permiso para seguirla.
En este laboratorio, actuarás como un evaluador de seguridad analizando la API de una aplicación web local. Comenzarás autenticándote como un usuario estándar, analizando cómo la aplicación hace referencia a tu perfil de usuario y, posteriormente, explotarás una vulnerabilidad IDOR para acceder a los datos privados de otros usuarios, incluido un administrador.
Autenticarse como usuario estándar
En este paso, interactuarás con una API web local que se ejecuta en tu máquina en el puerto 5000. Para comenzar a probar la aplicación en busca de vulnerabilidades, primero debes autenticarte como un usuario estándar para obtener un token de sesión válido.
Se nos han proporcionado las credenciales de una usuaria estándar llamada Alice. Su nombre de usuario es alice y su contraseña es password123.
Utilizarás la herramienta de línea de comandos curl para enviar una solicitud HTTP POST al endpoint de inicio de sesión. curl es una herramienta potente utilizada para transferir datos hacia o desde un servidor.
Ejecuta el siguiente comando en tu terminal para iniciar sesión:
curl -X POST http://localhost:5000/api/login \
-H "Content-Type: application/json" \
-d '{"username": "alice", "password": "password123"}'
Analicemos este comando:
-X POSTespecifica que estamos enviando una solicitud POST, la cual se utiliza normalmente para enviar datos como credenciales de inicio de sesión.-H "Content-Type: application/json"le indica al servidor que los datos que estamos enviando tienen formato JSON.-d '...'contiene el payload de datos JSON real con el nombre de usuario y la contraseña.
Si las credenciales son correctas, deberías ver una salida similar a esta:
{"token": "Bearer alice_token", "user_id": "1001"}
Toma nota del token y del user_id. El token (Bearer alice_token) actúa como tu tarjeta de identificación digital. Deberás incluirlo en futuras solicitudes para demostrar que estás autenticado. El user_id (1001) es tu identificador único en la base de datos de la aplicación.
Analizar referencias a objetos (URLs/APIs)
Ahora que estás autenticado como Alice, puedes acceder a su perfil de usuario. En muchas aplicaciones web, los perfiles de usuario se acceden a través de un endpoint de API que requiere tu token de autenticación y una referencia al objeto específico (en este caso, el perfil de usuario) que deseas ver.
Utilizarás curl de nuevo, pero esta vez enviarás una solicitud GET al endpoint /api/profile. Debes incluir el token de autenticación en los encabezados HTTP y especificar tu user_id en la URL.
Este es exactamente el tipo de patrón que aparece en las APIs reales: un token demuestra que la sesión existe, mientras que un parámetro selecciona el objeto a recuperar. Las aplicaciones seguras deben vincular ambas ideas mediante comprobaciones de autorización.
Ejecuta el siguiente comando para ver el perfil de Alice:
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=1001"
En este comando:
-H "Authorization: Bearer alice_token"pasa tu tarjeta de identificación digital al servidor.?user_id=1001es un parámetro de consulta añadido a la URL. Esta es la Referencia Directa a Objeto. Le indica al servidor exactamente qué registro de la base de datos debe recuperar.
Deberías recibir una respuesta JSON que contiene la información del perfil de Alice:
{"name": "Alice", "role": "user", "email": "alice@example.com", "secret": "alice_secret_123"}
Observa cómo la aplicación depende del parámetro user_id=1001 en la URL para decidir qué datos devolver. Una aplicación segura verificaría que el usuario asociado con el Bearer alice_token realmente tiene permiso para ver los datos del user_id=1001. Si la aplicación no realiza esta comprobación de autorización, es vulnerable a IDOR.
Manipular IDs de usuario
En este paso, probarás si la aplicación aplica correctamente los controles de acceso. Actualmente estás autenticado como Alice, pero ¿qué sucede si solicitas al servidor los datos de otro usuario?
Esa es la pregunta central de la autorización. "¿He iniciado sesión?" y "¿Tengo permiso para leer este objeto?" son comprobaciones diferentes, y confundirlas conduce directamente a IDOR.
Supongamos que hay otro usuario estándar llamado Bob, y su ID de usuario es 1002. Si la aplicación es vulnerable a IDOR, confiará ciegamente en el parámetro user_id de la URL sin comprobar si Alice tiene permiso para ver el perfil de Bob.
Modifica el parámetro user_id en tu comando anterior de 1001 a 1002. Ejecuta el siguiente comando:
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=1002"
Observa la salida devuelta por el servidor:
{"name": "Bob", "role": "user", "email": "bob@example.com", "secret": "bob_secret_456"}
¡Has recuperado con éxito la información privada de Bob, incluyendo su correo electrónico y su clave secreta, mientras seguías autenticado como Alice!
Esto confirma la presencia de una vulnerabilidad de Referencia Directa a Objeto Insegura (IDOR). El servidor comprobó que habías iniciado sesión (validando el token), pero no comprobó si estabas autorizado para acceder al objeto específico (el perfil de Bob) que solicitaste.
Acceder a datos no autorizados
Una vez confirmada la vulnerabilidad IDOR, ahora puedes escalar el ataque para acceder a información altamente confidencial. En muchos sistemas, los usuarios administrativos tienen IDs predecibles, como 1, 0 o 9999.
Para esta aplicación, el ID de usuario del administrador es 9999. Al explotar la misma vulnerabilidad IDOR, puedes intentar extraer el perfil del administrador, el cual contiene una bandera (flag) secreta.
Para documentar tu hallazgo, redirigirás la salida de tu comando curl a un archivo llamado flag.txt dentro de tu directorio de trabajo actual (~/project).
Ejecuta el siguiente comando para obtener el perfil del administrador y guardarlo:
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=9999" > ~/project/flag.txt
El símbolo > redirige la salida que normalmente se imprimiría en tu pantalla hacia el archivo especificado.
Para verificar que has capturado con éxito los datos del administrador, lee el contenido del archivo usando el comando cat:
cat ~/project/flag.txt
Deberías ver los datos del perfil del administrador, incluyendo la bandera secreta:
{"name": "Admin", "role": "admin", "email": "admin@example.com", "secret": "FLAG{IDOR_VULN_EXPLOITED}"}
¡Felicidades! Has explotado con éxito una vulnerabilidad IDOR para eludir los controles de acceso y recuperar datos administrativos confidenciales.
Resumen
En este laboratorio, exploraste la mecánica de las Referencias Directas a Objetos Inseguras (IDOR), una falla crítica de control de acceso. Comenzaste autenticándote como un usuario estándar y analizando cómo la aplicación hacía referencia a los datos del usuario a través de parámetros de URL. Al manipular estos parámetros, eludiste con éxito las comprobaciones de autorización para ver los perfiles privados de otros usuarios. Finalmente, escalaste el ataque para extraer datos administrativos confidenciales.
Este ejercicio destaca la importancia de implementar comprobaciones de autorización robustas en el lado del servidor. Las aplicaciones nunca deben confiar únicamente en la entrada proporcionada por el usuario para conceder acceso a los objetos; siempre deben verificar que el usuario autenticado tenga el derecho explícito de acceder al recurso solicitado.
