Las Referencias Directas Inseguras a Objetos, comúnmente conocidas como IDORs, siguen siendo una de las clases de vulnerabilidades de aplicaciones más comunes y perjudiciales. A pesar de estar bien documentadas y ampliamente comprendidas a nivel conceptual, continúan apareciendo en sistemas de producción reales, particularmente en aplicaciones modernas impulsadas por API.
Una vulnerabilidad IDOR ocurre cuando una aplicación utiliza un identificador proporcionado por el usuario para acceder a un objeto interno sin verificar que el usuario actual esté autorizado para acceder a ese objeto específico. Este problema se enmarca en la categoría más amplia de control de acceso roto, pero es distinto en cómo se manifiesta y por qué es difícil de eliminar por completo.
Las IDORs persisten no porque los equipos las desconozcan, sino porque surgen de la forma en que evolucionan los sistemas reales. A menudo se introducen en los límites de los flujos de trabajo, durante las refactorizaciones o cuando se reutilizan suposiciones de propiedad en pasos que no fueron diseñados originalmente para estar conectados. Este artículo explica cómo se ven las IDORs en la práctica, por qué los enfoques comunes de pruebas de seguridad tienen dificultades para detectarlas de manera fiable y cómo las técnicas de prueba modernas validan los fallos de propiedad en sistemas en ejecución.
¿Qué es una Referencia Directa Insegura a Objetos en la Práctica?
Una vulnerabilidad IDOR ocurre cuando una aplicación acepta un identificador que hace referencia a un objeto interno, como un registro, documento o cuenta, y lo utiliza directamente sin aplicar de forma consistente la autorización para dicho objeto.
Los identificadores suelen aparecer como:
- IDs de usuario en rutas URL
- IDs de pedido o factura en parámetros de consulta
- Identificadores de recursos en cuerpos de solicitud
La vulnerabilidad no es el identificador en sí. La vulnerabilidad es la suposición de que el identificador pertenece al usuario autenticado, sin revalidar esa suposición en el servidor.
En las aplicaciones modernas, esta suposición a menudo se cumple en la mayoría de los lugares, pero no en todos. Esa inconsistencia es donde existen las IDORs.
Por qué las Vulnerabilidades IDOR son Especialmente Peligrosas en las API
En la literatura sobre seguridad de API, las IDORs a menudo se denominan Broken Object Level Authorization (BOLA), el principal riesgo en el Top 10 de Seguridad de API de OWASP. OWASP adoptó el término BOLA para adaptarse al diseño moderno de API.
Las API exponen la funcionalidad y los datos centrales de las aplicaciones. Cuando existe una IDOR en una API, los atacantes a menudo pueden explotarla a gran escala.
Los impactos comunes incluyen:
- Acceso a datos sensibles pertenecientes a otros usuarios
- Modificar o eliminar recursos propiedad de otros
- Eludir las reglas de negocio vinculadas a la propiedad o el rol
- Socavar flujos de trabajo como aprobaciones, facturación o gestión de cuentas
Dado que las API están diseñadas para la automatización, una única comprobación de propiedad ausente puede comprometer grandes partes de un sistema.
Tipos comunes de vulnerabilidades IDOR
IDOR es un término paraguas. En la práctica, los equipos se encuentran con varios patrones recurrentes:
- IDOR horizontal: Un usuario accede a objetos de otro usuario con el mismo nivel de privilegio
- IDOR vertical: Los identificadores permiten el acceso a objetos privilegiados o administrativos
- IDOR ciego: La respuesta no expone datos, pero la acción se realiza con éxito sobre el objeto de otra persona
Los IDOR ciegos son especialmente fáciles de pasar por alto con herramientas que se centran en la exposición obvia de datos. A menudo requieren una validación explícita para confirmar el impacto.
Cómo se prueban tradicionalmente las vulnerabilidades IDOR en la práctica
Durante una prueba de penetración, las pruebas de IDOR se realizan típicamente mediante una cuidadosa repetición y comparación de solicitudes.
En la práctica, esto implica:
- Autenticarse como un usuario legítimo
- Ejecutar flujos de trabajo a través de la interfaz de usuario
- Capturar las solicitudes enviadas por el navegador o cliente
- Repetir esas solicitudes con un usuario autenticado diferente
- Comparar las respuestas para ver si el comportamiento cambia
Por ejemplo, si una solicitud que solo debería devolver datos para el Usuario A devuelve los mismos datos cuando se repite como Usuario B, esto indica un control de acceso roto.
Este enfoque es eficaz y ampliamente utilizado. Se basa en la comprensión del probador sobre la intención de la aplicación y su capacidad para discernir qué solicitudes son sensibles a la seguridad.
Sin embargo, también es inherentemente manual y consume mucho tiempo. Cada flujo de trabajo, rol o transición de estado adicional multiplica el número de solicitudes que deben ser capturadas, repetidas e interpretadas. A medida que las aplicaciones se vuelven más complejas, resulta poco práctico aplicar esta comparación de forma exhaustiva en todas las rutas posibles.
Por eso, las pruebas manuales a menudo encuentran IDOR en áreas que reciben mucha atención, pero no pueden garantizar una cobertura exhaustiva.
Por qué las herramientas DAST pasan por alto vulnerabilidades IDOR reales
Las herramientas de Pruebas de seguridad de aplicaciones dinámicas (DAST) operan a nivel de solicitud. Rastran los endpoints, realizan fuzzing en las entradas y buscan respuestas anómalas. Lo que no entienden es la intención. Un escáner no sabe si una factura determinada pertenece al Usuario A o al Usuario B. No razona sobre la propiedad, el contexto del flujo de trabajo o si una respuesta es apropiada para la identidad autenticada. Mientras la aplicación responda limpiamente, a menudo con un 200 OK, un escáner puede considerar la interacción como exitosa incluso cuando se exponen datos sensibles al usuario incorrecto.
Esto hace que DAST sea útil para problemas superficiales, pero fundamentalmente limitado cuando se trata de IDOR y otros fallos de autorización que dependen de la propiedad y el contexto del objeto. Esta limitación no es específica de una herramienta en particular. Refleja el hecho de que el escaneo a nivel de solicitud, incluso cuando está bien implementado, no tiene suficiente contexto para razonar sobre la propiedad del objeto y la intención del flujo de trabajo.
¿Por qué el análisis estático genera ruido en torno a los IDOR?
Muchos equipos confían en herramientas de análisis estático para señalar posibles problemas de IDOR. Estas herramientas suelen buscar patrones donde los identificadores se pasan a manejadores o controladores sin comprobaciones de autorización evidentes en las proximidades.
Esto suele generar un gran número de hallazgos.
En la práctica, la mayoría de estos son falsos positivos. Las comprobaciones de autorización suelen existir en otras partes de la cadena de llamadas, en middleware compartido o a nivel de framework. El análisis estático no puede determinar de forma fiable si un identificador es explotable en tiempo de ejecución.
Este problema se amplifica cuando la autorización se implementa implícitamente o se distribuye a través de capas, incluyendo:
- Control de acceso aplicado por middleware o decoradores
- Comprobaciones implementadas en servicios compartidos o métodos de modelo
- Lógica de permisos distribuida en múltiples archivos y rutas de llamada
En estos casos, las herramientas estáticas ven un identificador y una ruta de acceso a datos, pero omiten el contexto completo de autorización. El resultado es un alto volumen de hallazgos aparentemente plausibles con baja confianza.
Esta es una limitación fundamental del análisis estático. Sin el estado en tiempo de ejecución y el contexto de identidad, ningún análisis a nivel de código puede determinar de forma fiable si una referencia de objeto es explotable en la práctica.
Incluso las herramientas de análisis estático asistidas por IA siguen siendo predictivas. Razonan sobre la estructura del código, pero no pueden confirmar el comportamiento en tiempo de ejecución. Como resultado, los hallazgos similares a IDOR a menudo presentan tasas de falsos positivos que superan el cincuenta por ciento, lo que obliga a los equipos a priorizar problemas teóricos mientras que los fallos reales de propiedad corren el riesgo de quedar ocultos.
El problema principal: la propiedad es contextual
Los IDOR no son simplemente comprobaciones faltantes. Son fallos de autorización contextual vinculados a la propiedad del objeto.
La propiedad se establece a través de una combinación de:
- Estado de autenticación
- Modelos de roles y permisos
- Progresión del flujo de trabajo
- Estado del lado del servidor creado anteriormente en un proceso
Si alguna parte de ese contexto se asume en lugar de revalidarse, puede surgir un IDOR.
Algunos IDOR son de segundo orden. Un identificador se acepta en un paso, se almacena y solo se utiliza más tarde cuando el control de acceso ya no se verifica. Estos problemas son particularmente difíciles de detectar porque la explotación se separa en el tiempo y en los pasos.
Probar los IDOR de forma fiable requiere hacer repetidamente una pregunta sencilla: ¿qué sucede si este identificador pertenece a otra persona?
Los UUIDs no previenen las vulnerabilidades IDOR
Es un error común pensar que cambiar de identificadores secuenciales a UUIDs elimina el riesgo de IDOR.
Los identificadores impredecibles reducen los ataques de fuerza bruta. No impiden el acceso no autorizado si faltan las comprobaciones de propiedad.
En sistemas reales, los atacantes obtienen identificadores a través del comportamiento normal de la aplicación, incluyendo:
- Referencias devueltas por otros endpoints
- Enlaces y URL compartidos
- Mensajes y notificaciones en la aplicación
- Registros, exportaciones e historial del navegador
Si un atacante puede obtener un identificador válido y el backend no aplica la propiedad, todavía existe un IDOR.
Cómo el pentesting de IA encuentra vulnerabilidades IDOR que otros pasan por alto
El pentesting de IA adopta un enfoque diferente para identificar fallos de autorización.
En lugar de detenerse en la detección, prueba activamente hipótesis sobre la propiedad y el control de acceso en una aplicación en ejecución.
Dentro de Aikido, este enfoque se implementa a través de Aikido Attack, pruebas de penetración autónomas que combinan la creatividad humana con la velocidad de la máquina. Está diseñado para evaluar fallos de autorización y propiedad en entornos reales. Aikido Attack opera utilizando identidades reales, ejecuta flujos de trabajo de principio a fin y valida la explotabilidad antes de informar los hallazgos.
Para los IDOR, este proceso implica:
- Autenticarse como usuarios reales
- Ejecutar flujos de trabajo completos de principio a fin
- Reutilizar identificadores de objeto entre roles y contextos
- Intentar acceder o modificar recursos propiedad de otros usuarios
- Validar si el comportamiento es explotable y reproducible
Solo se informan los problemas que pueden explotarse en la práctica. El resto se descarta automáticamente.
Esto reduce los falsos positivos y asegura que los hallazgos reportados representan fallos de autorización reales. En situaciones donde la intención no está clara, un tester humano normalmente necesitaría consultar con el propietario de la aplicación. La validación en tiempo de ejecución resuelve esto directamente.
Pruebas focalizadas de supuestos de propiedad
El pentesting de IA dedica un esfuerzo específico a evaluar los supuestos de propiedad vinculados a identificadores de objeto en toda una aplicación.
En lugar de tratar los IDOR como un efecto secundario de las pruebas genéricas, se centra explícitamente en:
- Identificadores vinculados a recursos propiedad del usuario
- Transiciones de flujo de trabajo que reutilizan referencias de objeto
- Endpoints de backend que dependen de supuestos de propiedad del frontend
Esto asegura una cobertura consistente de las partes de un sistema donde los IDOR realmente ocurren.
Ejemplo: IDOR en un flujo de trabajo de aprobación de varios pasos
Este ejemplo ilustra cómo un IDOR puede surgir a través de múltiples pasos de un flujo de trabajo, incluso cuando los endpoints individuales parecen aplicar correctamente el control de acceso.
Contexto de la aplicación
La aplicación incluye un flujo de trabajo de aprobación en varios pasos para acciones sensibles. Un usuario crea una solicitud que debe ser revisada y aprobada posteriormente. Cada solicitud está vinculada al usuario que la creó y se referencia mediante un identificador utilizado en múltiples llamadas a la API.
Solo el propietario de una solicitud está autorizado a verla o modificarla antes de su aprobación.
Lo que el sistema observó
El pentesting de IA se autenticó como un usuario estándar y ejecutó el flujo de creación de solicitudes. Durante este proceso, el sistema almacenó el estado intermedio del flujo de trabajo en el servidor y lo reutilizó en pasos posteriores.
Las comprobaciones iniciales de propiedad se aplicaron correctamente cuando se creó la solicitud.
Pruebas de propiedad a lo largo del flujo de trabajo
Pruebas adicionales evaluaron cómo se utilizaba el identificador de la solicitud en etapas posteriores. Se observó que:
- El identificador se reutilizó al reanudar una solicitud pendiente
- Las llamadas posteriores a la API asumieron la propiedad basándose en una validación previa
- La propiedad no se revalidó cuando se reanudó el flujo de trabajo
Al reproducir la acción de reanudación con un usuario autenticado diferente y sustituyendo el identificador de la solicitud, el sistema pudo acceder y actuar sobre una solicitud que no le pertenecía.
Por qué esto era una vulnerabilidad IDOR
El problema no se originó por una única comprobación faltante.
Resultó de la suposición de que la propiedad ya había sido validada anteriormente en el flujo de trabajo y no necesitaba ser verificada de nuevo al reanudar la solicitud. Esa suposición falló una vez que los identificadores de objeto se reutilizaron entre usuarios.
Validación y reproducibilidad
Antes de informar del problema, el sistema:
- Reprodujo la secuencia completa varias veces
- Confirmó un comportamiento consistente
- Capturó evidencia de acceso no autorizado
Solo después de confirmar la reproducibilidad y el impacto se informó del problema.
Por qué esto pasaría desapercibido para otros enfoques
Cada endpoint individual se comportaba correctamente de forma aislada. La vulnerabilidad solo surgió cuando:
- Un flujo de trabajo se completó parcialmente
- Se reutilizó el estado del lado del servidor
- Se invocó un paso posterior fuera del contexto de usuario original
Esto dificultó la detección del problema mediante pruebas manuales y lo hizo invisible para las herramientas de escaneo basadas en solicitudes.
Por qué las pruebas continuas son importantes para las vulnerabilidades IDOR
Las IDORs a menudo se introducen por cambios.
Comúnmente aparecen cuando:
- Nuevas funcionalidades reutilizan modelos de datos existentes
- La lógica de autorización se añade en un lugar pero no en otro
- Las refactorizaciones eluden involuntariamente los controles de propiedad anteriores
Una prueba puntual puede confirmar que la propiedad se aplica hoy, pero esa garantía se degrada a medida que la aplicación evoluciona.
Las pruebas continuas impulsadas por IA mantienen la confianza al reevaluar las suposiciones de propiedad a medida que el software cambia. Las herramientas de pentesting continuo respaldan esto al probar continuamente flujos de trabajo nuevos y modificados en busca de acceso no autorizado a objetos.
Vulnerabilidades IDOR como síntoma de la complejidad del sistema
Las IDORs no son casos extremos. Son un resultado natural de sistemas complejos que evolucionan con el tiempo.
A medida que las aplicaciones crecen, la lógica de propiedad se extiende a través de servicios, flujos de trabajo y capas. Las suposiciones se acumulan y el razonamiento sobre el acceso a nivel de objeto se vuelve cada vez más difícil.
El pentesting de IA no elimina esta complejidad, pero la hace testeable.
Al ejercitar sistemáticamente los flujos de trabajo, rastrear el estado y validar la propiedad en contexto, convierte una de las clases de vulnerabilidad más persistentes en algo que puede detectarse antes, de manera más consistente y con mayor confianza.
Los equipos de seguridad priorizan cada vez más las IDORs y otros fallos de autorización porque son específicos del sistema, propensos a regresiones y difíciles de validar sin pruebas en tiempo de ejecución y conscientes del flujo de trabajo.
También te puede interesar:
