Insecure Direct Object Reference (IDOR)
Última actualización
Última actualización
Un IDOR (Insecure Direct Object Reference) es un tipo de vulnerabilidad que ocurre cuando una aplicación permite que un atacante acceda a objetos o recursos que no debería.
Para entenderlo mejor, un objeto es cualquier cosa que la aplicación gestiona, como un archivo, una base de datos, un perfil de usuario, una imagen, etc. Cada uno de estos objetos tiene un identificador, que es un número o código único que lo distingue.
Por ejemplo, una URL como /perfil?id=123 hace referencia a un objeto (en este caso, el perfil de un usuario) con el identificador 123. Si la aplicación no verifica adecuadamente que el usuario tiene permiso para ver ese objeto, un atacante podría cambiar el número en la URL (por ejemplo, a /perfil?id=124) y acceder al perfil de otro usuario.
En resumen, un IDOR ocurre cuando la aplicación permite el acceso directo a objetos usando identificadores en la URL o en otros parámetros, sin comprobar si el usuario tiene permiso para acceder a esos objetos.
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.
Los impactos de una vulnerabilidad IDOR dependen de la naturaleza de los datos a los que se puede acceder. Los posibles riesgos incluyen:
Acceso no autorizado a datos sensibles: Esto puede incluir información personal, financiera o médica de otros usuarios.
Modificación de datos: Un atacante podría editar datos de otros usuarios sin permiso, lo que podría afectar la integridad de la información.
Eliminación de datos: El atacante podría borrar información importante de otros usuarios, afectando la operación normal de la aplicación.
Agregado de datos: Un atacante podría insertar datos maliciosos o no autorizados en la base de datos de otros usuarios o la propia aplicación.
Para identificar posibles casos de la vulnerabilidad Insecure Direct Object Reference (IDOR) en las solicitudes HTTP, es importante analizar y examinar cómo se manejan los identificadores o referencias a objetos en dichas solicitudes. Aquí hay algunos ejemplos que ilustran cómo identificar la IDOR en diferentes tipos de solicitudes HTTP.
IDOR a través del método GET:
En una solicitud GET, los identificadores a menudo se pasan a través de los parámetros de la URL. Para identificar posibles casos de IDOR, puedes observar si los identificadores en los parámetros se pueden manipular fácilmente y si hay una falta de validación o control de acceso adecuado.
Ejemplo de URL vulnerable a IDOR en una solicitud GET:
Si el parámetro id se puede modificar fácilmente y acceder a perfiles de otros usuarios sin restricciones, podría indicar una posible vulnerabilidad IDOR.
IDOR a través del método POST:
En una solicitud POST, los identificadores pueden transmitirse en el cuerpo de la solicitud o en los campos de formulario. Al analizar una solicitud POST, puedes verificar si los identificadores se envían como datos no encriptados en el cuerpo de la solicitud y si la validación de control de acceso es insuficiente.
Ejemplo de cuerpo de solicitud POST vulnerable a IDOR:
Si el valor del parámetro user_id se puede modificar y cambiar la contraseña de otros usuarios sin restricciones, podría indicar una posible vulnerabilidad IDOR.
IDOR a través del método PUT/PATCH:
En solicitudes DELETE, donde se eliminan recursos existentes, también es importante verificar si los identificadores utilizados en la solicitud pueden ser manipulados para obtener acceso no autorizado a recursos protegidos.
Ejemplo de solicitud DELETE vulnerable a IDOR:
Si el valor 123 en la URL se puede modificar y acceder o modificar otros productos sin restricciones, podría indicar una posible vulnerabilidad IDOR.
IDOR a través del método DELETE:
Es crucial examinar cómo se manejan los identificadores y referencias a objetos en todas las solicitudes HTTP relevantes y evaluar si existe una falta de validación o control de acceso adecuado en dichos casos. Identificar inconsistencias en la autorización y en la relación entre los identificadores y los permisos de acceso puede ayudarte a detectar posibles casos de IDOR en una aplicación web.
Este caso se me presentó en una auditoría en 2023, era un Mobile Pentest a una Fintech.
En primer lugar, cuando te dirigías a la opción Tarjeta de Débito pasabas a otra sección donde podías ver más información sobre la tarjeta.
Aquí seleccionamos Datos de tarjeta:
Al momento de efectuar esto, se estaba interceptando todo el tráfico HTTP que enviaba la aplicación al servidor de la API, usando la herramienta BurpSuite, en la siguiente imagen tenemos a Burp en la parte izquierda y a la aplicación en la parte derecha:
Como se pudo ver en la imagen anterior, se capturó la siguiente petición HTTP, la cual le solicita al servidor los datos de tarjeta del usuario en sesión, a partir del ID 13981.
Sin embargo, en este punto se identificó que estos identificadores eran continuos (1,2,3,4,5) y que la aplicación no estaba efectuando una validación segura del lado del backend, por lo que cualquier usuario no autorizado podía ver los datos de tarjeta del resto de usuarios de la plataforma. En la siguiente imagen, vemos un ataque de fuerza bruta controlada con el módulo Intruder de Burp Suite donde identificamos varios card_id válidos que nos devuelven información:
Como se observa en la siguiente imagen, en la misma sesión, se logran ver los datos de tarjetas de otro usuario, de manera no autorizada, cambiando el ID a 13984:
En este imagen por ejemplo se coloca el ID 900 en la solicitud, la cual permite ver nuevamente los datos de tarjeta de otro usuario:
De esta forma, un atacante que vaya iterando los identificadores de tarjetas puede ir accediendo a las imágenes de las mismas y utilizarlas a su beneficio propio.
En este caso, al ser una vulnerabilidad bastante crítica fue reportada a la brevedad donde el equipo del cliente lo ha remediado al instante a la vulnerabilidad, informándome que si bien las pruebas estaban en staging (ambiente de pruebas) estaba también presente en producción (ambiente real) y en varios países, por lo que fue un bonito IDOR, sencillo pero con mucho impacto. De aquí la importancia de auditar el código y las aplicaciones, un simple ID puede arruinar a todo un negocio y causar desastres legales y/o financieros.
Siempre que veas un ID en una ruta o parámetro, cambialo por otro a ver que pasa, si no te trae info asegurate de que sea un valor existente porque puede que ese recurso no exista.
Brute Force al identificador con burp, siempre con precaución no le vayas a tirar 10000 solicitudes por segundo (Mi configuración del Resource Pool en Intruder es: concurrent request: 7, request delay: 700, si va muy lento podés adaptarlo mejor).
Siempre preguntarse, ¿qué pasa si cambio este id?, ¿puedo cambiar el id_company y pasarme a otra empresa dentro del aplicativo?
Manipulación del body, manipulación de la url, manipulación de la cookie, pensar siempre en cambiar lo que ves en pantalla.
Aprender a utilizar Auth Analyzer, esta tool está buenísima para encontrar IDORs.
Para prevenir las vulnerabilidades IDOR, es importante seguir buenas prácticas de seguridad:
Implementar un control de acceso adecuado: Asegurarse de que los usuarios solo puedan acceder a los recursos y datos a los que están autorizados. Utilizar mecanismos robustos de autenticación y autorización.
Validar y autorizar las solicitudes: Verificar que el usuario tenga los permisos adecuados para acceder a los recursos solicitados. Realizar validaciones de seguridad en el servidor y asegurarse de que el usuario esté autorizado para realizar la acción solicitada.
Aplicar el principio de privilegio mínimo: Otorgar a los usuarios solo los privilegios necesarios para llevar a cabo sus funciones. Evitar el exceso de privilegios que podrían conducir a una explotación de IDOR.
Como respuesta la API devuelve un campo image en base64, este base64 es la imagen con información de la tarjeta que se renderiza en la aplicación, por lo para ver la imagen tenemos que pasarle el base64 a una herramienta como :
No exponer referencias directas a objetos internos: Evitar revelar identificadores o referencias directas en la interfaz de usuario o en las solicitudes HTTP. Utilizar identificadores opacos o valores aleatorios para asegurarse de que no se puedan adivinar o manipular fácilmente. Para esto son muy útiles los .
Auth Analyzer:
