Referencias directas a objetos inseguras: una amenaza importante para las aplicaciones web
Las referencias directas a objetos inseguras (IDOR, por sus siglas en inglés) son una de las vulnerabilidades más comunes y peligrosas en las aplicaciones web. En este artículo, exploraremos qué es una IDOR, cómo funciona, por qué es peligrosa y, sobre todo, cómo prevenirla.
Una IDOR es un tipo de vulnerabilidad subestimada o desconocida por muchos desarrolladores, pero bien conocida por los piratas informáticos y los investigadores de seguridad. De hecho, las IDOR han sido y siguen siendo a menudo la causa de filtraciones de datos (véanse los ejemplos: Uber 2016, Microsoft Teams 2023). Además, aparecieron en el Top 10 de OWASP por primera vez en 2007 («A4 – IDOR»). Desde entonces, las IDOR se fusionaron con la categoría «A7 – Fallo en el control de acceso a nivel de función (2013)» y posteriormente en la categoría «A5 – Fallo en el control de acceso» en 2017.
En 2021, esta categoría ocupó el primer lugar del Top 10 de OWASP, confirmando así su importancia, su criticidad y su alto riesgo de aparición. Finalmente, en 2023, en el Top 10 de OWASP específico para API, esta categoría se dividió en tres:
- API1 – Fallo en la autorización a nivel de objeto
- API3 – Fallo en la autorización a nivel de propiedad de objeto
- API5 – Fallo en la autorización a nivel de función
Definición
Hablamos de referencia directa a un objeto cuando es posible señalar un recurso mediante un identificador o un nombre, por ejemplo. Cuando es posible iterar sobre los identificadores o nombres para acceder a todos los recursos afectados, y las comprobaciones de autorización de acceso a dichos recursos están mal implementadas o directamente ausentes, hablamos de referencia directa a objetos insegura.
En otras palabras, si una aplicación no verifica que el usuario tenga permiso para acceder a un recurso específico, un atacante puede modificar estas referencias para acceder a recursos que no le pertenecen.
Existen varios tipos de IDOR, a menudo divididos en cuatro categorías que permiten:
- Acceso de lectura a recursos;
- Creación, edición o eliminación de recursos;
- Acceso de lectura a documentos;
- Acceso a funcionalidades.
Acceso de lectura a recursos
Parece necesario estar autenticado para poder utilizar una ruta de API como «/api/user/{user_id}/account». Sin embargo, cuando no se ha implementado ninguna restricción para limitar el acceso a la información de otras cuentas, es posible iterar sobre el valor del parámetro «user_id» para recuperar la información de cada usuario.
Creación, edición y eliminación de recursos
El mismo tipo de vulnerabilidad puede afectar a una ruta como «/api/orders/comment»: si no se implementa ninguna restricción para limitar la adición de comentarios en los pedidos de otros usuarios, es posible iterar sobre el valor del parámetro «order_id» para añadir comentarios en cualquier pedido.
Acceso de lectura a documentos
Se trata de un caso particular de la primera categoría aplicado a documentos. Existen varias formas de solicitudes vulnerables en este caso: el acceso a documentos mediante un identificador o el acceso a documentos mediante el nombre del archivo.
Las vulnerabilidades de tipo LFI (Local File Inclusion) son un caso particular de este tipo de IDOR.
Acceso a funcionalidades
Tomemos el caso de una ruta como «/api/employees/?role=rh», que requiere estar autenticado. Si no se ha implementado ninguna restricción para limitar el acceso a las funcionalidades reservadas a ciertos roles en la lista de empleados, es posible iterar sobre el valor del parámetro «role» para acceder a las diferentes vistas y funcionalidades posibles, hasta obtener la vista y las funcionalidades reservadas a un administrador.
Casos específicos
Las IDOR, cuando se aplican a ciertas características de las cuentas de usuario, pueden ser muy críticas para una aplicación.
Modificación del rol del usuario
Cuando una IDOR afecta a la funcionalidad de cambio de rol de un usuario, puede ser posible:
- Modificar el rol de otro usuario
- Modificar el propio rol por uno de mayor nivel
Esto puede permitir reducir o elevar los privilegios de otro usuario, o bien elevar los propios privilegios en la aplicación.
Cambio de contraseña
Cuando una IDOR afecta a la funcionalidad de cambio de contraseña de un usuario, es posible que se pueda modificar la contraseña de otro usuario.
Esto puede permitir el compromiso de las cuentas de otros usuarios y una posible escalada de privilegios en la aplicación.
Remediación: proteja una aplicación contra las vulnerabilidades de tipo IDOR
Para proteger una aplicación contra las vulnerabilidades de tipo IDOR, siga estas recomendaciones:
- Verifique sistemáticamente los derechos de acceso a los recursos, teniendo en cuenta tanto la propiedad individual como los recursos compartidos.
- Asegúrese de que los derechos de acceso a las funcionalidades se gestionen correctamente según los roles de los usuarios.
- Evite las referencias directas en los parámetros, limitando especialmente las entradas del usuario.
- Utilice UUID (identificadores únicos universales) para ocultar los identificadores sensibles; aunque esto no garantiza la ausencia de IDOR, complica su explotación.
- Valide siempre las entradas provenientes de los usuarios para prevenir cualquier manipulación.
Conclusión
Las referencias directas a objetos inseguras (IDOR) representan una amenaza seria para la seguridad de las aplicaciones web, principalmente debido a su facilidad de explotación y a su capacidad para exponer datos sensibles. Sin embargo, al aplicar controles de acceso estrictos, utilizar referencias indirectas y validar correctamente las autorizaciones en el lado del servidor, los desarrolladores pueden prevenir eficazmente estas vulnerabilidades.
