Intro to IDOR
Las vulnerabilidades de Insecure Direct Object References (IDOR) son de las más comunes en aplicaciones web y pueden impactar significativamente en la aplicación vulnerable. Las vulnerabilidades IDOR ocurren cuando una aplicación web expone una referencia directa a un objeto, como un archivo o un recurso de base de datos, que el usuario final puede controlar directamente para obtener acceso a otros objetos similares. Si cualquier usuario puede acceder a cualquier recurso debido a la falta de un sistema de control de acceso sólido, el sistema se considera vulnerable.
Construir un sistema de control de acceso sólido es muy desafiante, por lo que las vulnerabilidades IDOR son tan comunes. Además, automatizar el proceso de identificación de debilidades en los sistemas de control de acceso también es bastante difícil, lo que puede llevar a que estas vulnerabilidades no se identifiquen hasta que lleguen a producción.
Por ejemplo, si los usuarios solicitan acceso a un archivo que subieron recientemente, pueden obtener un enlace como (download.php?file_id=123). Entonces, como el enlace hace referencia directa al archivo con (file_id=123), ¿qué pasaría si intentáramos acceder a otro archivo (que puede que no nos pertenezca) con (download.php?file_id=124)? Si la aplicación web no tiene un sistema de control de acceso adecuado en el back-end, podríamos acceder a cualquier archivo enviando una solicitud con su file_id. En muchos casos, podemos encontrar que el id es fácilmente adivinable, lo que hace posible recuperar muchos archivos o recursos a los que no deberíamos tener acceso según nuestros permisos.
What Makes an IDOR Vulnerability
Exponer una referencia directa a un objeto o recurso interno no es una vulnerabilidad en sí misma. Sin embargo, esto puede hacer posible explotar otra vulnerabilidad: un weak access control system. Muchas aplicaciones web restringen a los usuarios el acceso a recursos restringiéndolos de acceder a las páginas, funciones y APIs que pueden recuperar estos recursos. Sin embargo, ¿qué pasaría si un usuario de alguna manera obtuviera acceso a estas páginas (por ejemplo, a través de un enlace compartido/adivinado)? ¿Podrían seguir accediendo a los mismos recursos simplemente teniendo el enlace para acceder a ellos? Si la aplicación web no tuviera un sistema de control de acceso en el back-end que comparara la autenticación del usuario con la lista de acceso del recurso, podrían hacerlo.
Hay muchas maneras de implementar un sistema de control de acceso sólido para aplicaciones web, como tener un sistema de Role-Based Access Control (RBAC). La conclusión principal es que una vulnerabilidad IDOR existe principalmente debido a la falta de control de acceso en el back-end. Si un usuario tuviera referencias directas a objetos en una aplicación web que carece de control de acceso, sería posible que los atacantes vean o modifiquen los datos de otros usuarios.
Muchos desarrolladores ignoran la construcción de un sistema de control de acceso; por lo tanto, la mayoría de las aplicaciones web y móviles quedan desprotegidas en el back-end. En tales aplicaciones, todos los usuarios pueden tener acceso arbitrario a los datos de otros usuarios en el back-end. Lo único que impide a los usuarios acceder a los datos de otros usuarios sería la implementación del front-end de la aplicación, que está diseñada para mostrar solo los datos del usuario. En tales casos, manipular manualmente las solicitudes HTTP puede revelar que todos los usuarios tienen acceso completo a todos los datos, lo que lleva a un ataque exitoso.
Todo esto hace que las vulnerabilidades IDOR estén entre las más críticas para cualquier aplicación web o móvil, no solo debido a la exposición de referencias directas a objetos, sino principalmente debido a la falta de un sistema de control de acceso sólido. Incluso un sistema básico de control de acceso puede ser difícil de desarrollar. Un sistema de control de acceso integral que cubra toda la aplicación web sin interferir con sus funciones puede ser una tarea aún más difícil. Es por eso que las vulnerabilidades IDOR/Access Control se encuentran incluso en aplicaciones web muy grandes, como Facebook, Instagram y Twitter.
Impact of IDOR Vulnerabilities
Como se mencionó anteriormente, las vulnerabilidades IDOR pueden tener un impacto significativo en las aplicaciones web. El ejemplo más básico de una vulnerabilidad IDOR es acceder a archivos y recursos privados de otros usuarios que no deberían estar accesibles para nosotros, como archivos personales o datos de tarjetas de crédito, lo que se conoce como IDOR Information Disclosure Vulnerabilities. Dependiendo de la naturaleza de la referencia directa expuesta, la vulnerabilidad puede incluso permitir la modificación o eliminación de los datos de otros usuarios, lo que puede llevar a una toma de cuenta completa.
Una vez que un atacante identifica las referencias directas, que pueden ser IDs de base de datos o parámetros de URL, pueden comenzar a probar patrones específicos para ver si pueden obtener acceso a cualquier dato y eventualmente entender cómo extraer o modificar datos para cualquier usuario arbitrario.
Las vulnerabilidades IDOR también pueden llevar a la elevación de privilegios de usuario de un usuario estándar a un usuario administrador, con IDOR Insecure Function Calls. Por ejemplo, muchas aplicaciones web exponen parámetros de URL o APIs para funciones solo de administrador en el código front-end de la aplicación web y deshabilitan estas funciones para usuarios no administradores. Sin embargo, si tuviéramos acceso a tales parámetros o APIs, podríamos llamarlas con nuestros privilegios de usuario estándar. Supongamos que el back-end no negó explícitamente a los usuarios no administradores la llamada a estas funciones. En ese caso, podríamos realizar operaciones administrativas no autorizadas, como cambiar las contraseñas de los usuarios o otorgarles ciertos roles, lo que podría eventualmente llevar a una toma total de la aplicación web.