Las referencias directas a objetos inseguras, comúnmente conocidas como IDOR, siguen siendo una de las clases de vulnerabilidades de aplicaciones más comunes y perjudiciales. A pesar de estar bien documentadas y ser ampliamente comprendidas a nivel conceptual, siguen apareciendo en sistemas de producción reales, especialmente en aplicaciones modernas basadas en API.
Una vulnerabilidad IDOR se produce 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 dentro de la categoría más amplia de control de acceso roto, pero se distingue por cómo se manifiesta y por qué es difícil de eliminar por completo.
Los IDOR persisten no porque los equipos no los conozcan, sino porque surgen de la forma en que evolucionan los sistemas reales. A menudo se introducen en los extremos de los flujos de trabajo, durante las refactorizaciones o cuando las suposiciones de propiedad se reutilizan en pasos que no fueron diseñados originalmente para estar conectados. Este artículo explica cómo son los IDOR en la práctica, por qué los enfoques comunes de pruebas de seguridad tienen dificultades para detectarlos de forma fiable y cómo las técnicas de pruebas modernas validan los fallos de propiedad en los sistemas en funcionamiento.
¿Qué es una referencia directa a un objeto inseguro en la práctica?
Una vulnerabilidad IDOR se produce cuando una aplicación acepta un identificador que hace referencia a un objeto interno, como un registro, un documento o una cuenta, y lo utiliza directamente sin aplicar de forma coherente la autorización para ese objeto.
Los identificadores suelen aparecer como:
- Identificadores de usuario en rutas URL
- ID de pedido o factura en los parámetros de consulta
- Identificadores de recursos en los cuerpos de las solicitudes
La vulnerabilidad no es el identificador en sí mismo. 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 suele ser válida en la mayoría de los casos, pero no en todos. Esa inconsistencia es donde existen los IDOR.
Por qué las vulnerabilidades IDOR son especialmente peligrosas en las API
En seguridad de API , los IDOR suelen denominarse «autorización de nivel de objeto rota» (BOLA), el riesgo principal en el seguridad de API 10 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 básicos de las aplicaciones. Cuando existe un IDOR en una API, los atacantes suelen poder explotarlo a gran escala.
Entre los impactos comunes se incluyen:
- Acceso a datos confidenciales pertenecientes a otros usuarios
- Modificar o eliminar recursos que pertenecen a otros
- Eludir las reglas empresariales vinculadas a la propiedad o al cargo
- Socavar los flujos de trabajo, como las aprobaciones, la facturación o la gestión de cuentas.
Dado que las API están diseñadas para la automatización, una sola comprobación de propiedad omitida puede comprometer gran parte de un sistema.
Tipos comunes de vulnerabilidades IDOR
IDOR es un término genérico. En la práctica, los equipos se encuentran con varios patrones recurrentes:
- IDOR horizontal: un usuario accede a los objetos de otro usuario con el mismo nivel de privilegios.
- Identificadores verticales IDOR: los identificadores permiten el acceso a objetos privilegiados o administrativos.
- Blind IDOR: La respuesta no expone datos, pero la acción se lleva a cabo con éxito en 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 su impacto.
Cómo se prueban tradicionalmente las vulnerabilidades IDOR en la práctica
Durante una prueba de penetración, las pruebas IDOR se suelen realizar mediante una reproducción y comparación cuidadosa de las solicitudes.
En la práctica, esto implica:
- Autenticación como usuario legítimo
- Ejecución de flujos de trabajo a través de la interfaz de usuario
- Captura de solicitudes enviadas por el navegador o el cliente
- Repetir esas solicitudes con un usuario autenticado diferente.
- Comparar las respuestas para ver si cambia el comportamiento.
Por ejemplo, si una solicitud que solo debería devolver datos para el usuario A devuelve los mismos datos cuando se reproduce como usuario B, esto indica control de acceso roto.
Este enfoque es eficaz y se utiliza ampliamente. Se basa en la comprensión que tiene el evaluador de la finalidad de la aplicación y en su capacidad para razonar sobre qué solicitudes son sensibles desde el punto de vista de la seguridad.
Sin embargo, también es intrínsecamente manual y requiere mucho tiempo. Cada flujo de trabajo, función o transición de estado adicional multiplica el número de solicitudes que deben capturarse, reproducirse e interpretarse. 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 suelen detectar IDOR en áreas que reciben mucha atención, pero no pueden garantizar una cobertura completa.
¿Por qué DAST pasan por alto las vulnerabilidades IDOR reales?
Pruebas de seguridad de aplicaciones dinámicas operan a nivel de solicitud. Rastrean los puntos finales, realizan pruebas de fuzzing en las entradas y buscan respuestas anómalas. Lo que no comprenden 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 adecuada para la identidad autenticada. Siempre que la aplicación responda correctamente, a menudo con un 200 OK, un escáner puede considerar que la interacción ha sido satisfactoria, incluso cuando los datos confidenciales se exponen al usuario equivocado.
Esto hace que DAST para problemas a nivel superficial, pero fundamentalmente limitado cuando se trata de IDOR y otros fallos de autorización que dependen de la propiedad de los objetos y el contexto. Esta limitación no es específica de ninguna herramienta en concreto. Refleja el hecho de que el escaneo a nivel de solicitud, incluso cuando se implementa correctamente, no tiene suficiente contexto para razonar sobre la propiedad de los objetos 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 detectar posibles problemas de IDOR. Estas herramientas suelen buscar patrones en los que los identificadores se pasan a controladores o gestores sin comprobaciones de autorización evidentes cerca.
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 otros lugares de la cadena de llamadas, en el middleware compartido o a nivel de marco. 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 de forma implícita o se distribuye entre capas, incluyendo:
- Control de acceso aplicado por middleware o decoradores
- Comprobaciones implementadas en servicios compartidos o métodos modelo
- Lógica de permisos distribuida en varios archivos y rutas de llamada
En estos casos, las herramientas estáticas ven un identificador y una ruta de acceso a los datos, pero no detectan el contexto completo de la autorización. El resultado es un gran volumen de hallazgos aparentemente plausibles, pero con un bajo nivel de confianza.
Esta es una limitación fundamental del análisis estático. Sin el estado de tiempo de ejecución y el contexto de identidad, ningún análisis a nivel de código puede determinar de manera 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 suelen tener tasas de falsos positivos que superan el cincuenta por ciento, lo que obliga a los equipos a clasificar los problemas teóricos, mientras que los fallos reales de propiedad corren el riesgo de quedar ocultos.
El problema fundamental: la propiedad es contextual
Los IDOR no son simplemente comprobaciones que faltan. Son fallos de autorización contextual vinculados a la propiedad de objetos.
La propiedad se establece mediante 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 da por sentada 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 ya no se comprueba el control de acceso. Estos problemas son especialmente difíciles de detectar porque el exploit se divide en diferentes momentos y pasos.
Para comprobar la fiabilidad de los IDOR es necesario plantearse repetidamente una pregunta sencilla: ¿qué ocurre si este identificador pertenece a otra persona?
Los UUID no evitan las vulnerabilidades IDOR
Es un error común pensar que cambiar de identificadores secuenciales a UUID elimina el riesgo de IDOR.
Los identificadores impredecibles reducen los ataques de fuerza bruta. No impiden el acceso no autorizado si no se realizan comprobaciones de propiedad.
En los sistemas reales, los atacantes obtienen identificadores a través del comportamiento normal de las aplicaciones, incluyendo:
- Referencias devueltas por otros puntos finales
- Enlaces y URL compartidos
- Mensajes y notificaciones dentro de la aplicación
- Registros, exportaciones e historial del navegador
Si un atacante puede obtener un identificador válido y el backend no impone la propiedad, sigue existiendo un IDOR.
Cómo pentesting de IA vulnerabilidades IDOR que otros pasan por alto
pentesting de IA adopta un enfoque diferente para identificar fallos de autorización.
En lugar de limitarse a la detección, comprueba activamente hipótesis sobre la propiedad y el control de acceso en una aplicación en ejecución.
Dentro del 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 las máquinas. 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 de los resultados.
Para los IDOR, este proceso implica:
- Autenticación como usuarios reales
- Ejercicio de flujos de trabajo completos de principio a fin
- Reutilización de identificadores de objetos en diferentes roles y contextos
- Intentar acceder o modificar recursos que son 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 descartan automáticamente.
Esto reduce los falsos positivos y garantiza que los resultados notificados representen fallos de autorización reales. En situaciones en las que la intención no está clara, un evaluador humano normalmente tendría que consultar con el propietario de la aplicación. La validación en tiempo de ejecución resuelve esto directamente.
Pruebas específicas de las hipótesis sobre la propiedad
pentesting de IA esfuerzos específicos a evaluar las suposiciones de propiedad vinculadas a los identificadores de objetos 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 a objetos
- Puntos finales del backend que dependen de supuestos de propiedad del frontend
Esto garantiza una cobertura coherente de las partes de un sistema en las que realmente se producen los IDOR.
Ejemplo: IDOR en un flujo de trabajo de aprobación de varios pasos
Este ejemplo ilustra cómo puede surgir un IDOR en varios pasos del flujo de trabajo, incluso cuando los puntos finales individuales parecen aplicar correctamente el control de acceso.
Contexto de la aplicación
La aplicación incluye un flujo de trabajo de aprobación de varios pasos para acciones sensibles. Un usuario crea una solicitud que posteriormente debe ser revisada y aprobada. Cada solicitud está vinculada al usuario que la ha creado y se identifica mediante un identificador que se utiliza en varias llamadas a la API.
Solo el propietario de una solicitud puede verla o modificarla antes de su aprobación.
Lo que observó el sistema
pentesting de IA como 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 en todo el flujo de trabajo
En pruebas posteriores se evaluó cómo se utilizaba el identificador de solicitud en etapas posteriores. Se observó que:
- El identificador se reutilizó al reanudar una solicitud pendiente.
- Las llamadas API posteriores asumieron la propiedad basándose en la validación anterior.
- La propiedad no se revalidó cuando se reanudó el flujo de trabajo.
Al reproducir la acción de reanudar con un usuario autenticado diferente y sustituir el identificador de la solicitud, el sistema pudo acceder y actuar sobre una solicitud que no le pertenecía.
Por qué se trataba de una vulnerabilidad IDOR
El problema no se originó por un solo cheque perdido.
Esto se debió a la suposición de que la propiedad ya se había validado anteriormente en el flujo de trabajo y no era necesario volver a comprobarla cuando se reanudó la solicitud. Esa suposición falló cuando se reutilizaron los identificadores de objetos entre los usuarios.
Validación y reproducibilidad
Antes de informar del problema, el sistema:
- Reproduje la secuencia completa varias veces.
- Comportamiento coherente confirmado
- Pruebas capturadas de acceso no autorizado
Solo después de confirmar la reproducibilidad y el impacto se informó del problema.
Por qué otros enfoques pasarían esto por alto
Cada punto final individual funcionaba correctamente de forma aislada. La vulnerabilidad solo aparecía cuando:
- Se completó parcialmente un flujo de trabajo.
- Se reutilizó el estado del lado del servidor.
- Se invocó un paso posterior fuera del contexto de usuario original.
Esto dificultaba la detección del problema mediante pruebas manuales y lo hacía invisible para las herramientas de análisis basadas en solicitudes.
Por qué las pruebas continuas son importantes para las vulnerabilidades IDOR
Los IDOR suelen introducirse mediante cambios.
Suelen aparecer cuando:
- Las nuevas funciones reutilizan los modelos de datos existentes.
- La lógica de autorización se añade en un lugar, pero no en otro.
- Las refactoraciones omiten involuntariamente las comprobaciones de propiedad anteriores.
Una prueba puntual puede confirmar que la propiedad se aplica en la actualidad, 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 cambia el software. pentesting continuo respaldan esto mediante la comprobación continua de flujos de trabajo nuevos y modificados en busca de accesos no autorizados a objetos.
Las vulnerabilidades IDOR como síntoma de la complejidad del sistema
Los IDOR no son casos extremos. Son el resultado natural de sistemas complejos que evolucionan con el tiempo.
A medida que las aplicaciones crecen, la lógica de propiedad se extiende por los servicios, los flujos de trabajo y las capas. Las suposiciones se acumulan y el razonamiento sobre el acceso a nivel de objeto se vuelve cada vez más difícil.
pentesting de IA eliminan esta complejidad, pero la hacen comprobable.
Al ejercer sistemáticamente los flujos de trabajo, realizar un seguimiento del estado y validar la propiedad en contexto, convierte una de las clases de vulnerabilidad más persistentes en algo que se puede detectar antes, de forma más coherente y con mayor confianza.
Los equipos de seguridad dan cada vez más prioridad a los IDOR y otros fallos de autorización porque son específicos del sistema, propensos a la regresión y difíciles de validar sin pruebas de tiempo de ejecución que tengan en cuenta el flujo de trabajo.
También te puede interesar:
- Las mejores herramientas de pruebas de penetración con IA
- DAST pruebas de penetración con IA frente a pruebas de penetración manuales
- ¿Qué es el pentesting con IA?
Realice hoy mismo una prueba de penetración con Aikido Attack.
Protege tu software ahora.
.avif)
