IDOR

Existen vulnerabilidades que, pese a su aparente sencillez, siguen representando una amenaza constante para aplicaciones modernas. Una de las más comunes y peligrosas es el IDOR (Insecure Direct Object Reference), o “Referencia Directa a Objetos Insegura”. Este tipo de falla permite a un atacante acceder, modificar o eliminar información de otros usuarios simplemente manipulando identificadores en las solicitudes que envía al servidor.

A diferencia de ataques más complejos que requieren malware o ingeniería avanzada, un IDOR suele surgir por errores de lógica y control de acceso insuficiente. En muchos casos, basta con cambiar un número o una cadena en una URL para obtener acceso no autorizado a datos privados. Esa simplicidad lo convierte en uno de los errores más frecuentes y explotados en entornos web, APIs y aplicaciones móviles.

¿Qué es un IDOR?

Un IDOR ocurre cuando una aplicación expone referencias directas a objetos internos —como identificadores de usuarios, documentos o transacciones— sin verificar si el solicitante tiene permiso para acceder a ellos. Por ejemplo:

Si la aplicación no valida adecuadamente que el usuario autenticado solo puede ver su propio registro, un atacante podría cambiar el parámetro id=123 por id=124 y acceder a los datos de otro usuario. Esta es la esencia del IDOR: la falta de verificación en la relación entre el usuario autenticado y el recurso solicitado.

Cómo se explota una vulnerabilidad IDOR

Explotar un IDOR no requiere herramientas sofisticadas, sino observación, lógica y pruebas metódicas. El procedimiento básico que un atacante seguiría es el siguiente:

1. Enumerar o crear cuentas. Si la aplicación lo permite, el atacante puede registrar múltiples usuarios o buscar patrones en los identificadores.

2. Analizar los endpoints. Observa si existen parámetros como id, user, account, profile, order o similares en las solicitudes.

3. Modificar los valores. Cambia el identificador propio por el de otro usuario o un número consecutivo y observa si la aplicación devuelve información ajena.

4. Confirmar la explotación. Si obtiene acceso, modifica o borra información que no debería poder manipular, la vulnerabilidad está confirmada.

Este proceso puede aplicarse tanto a interfaces web como a APIs REST, GraphQL o SOAP, y puede ser automatizado mediante herramientas como Burp Suite, ParamMiner, Arjun o scripts personalizados.

Ejemplos de manipulación en endpoints

Durante un test de penetración, es común probar distintos escenarios. Algunos ejemplos ilustrativos incluyen:

• Cambio de método HTTP:
  A veces un endpoint bloquea un método pero no otro.

  GET /users/delete/123 -> 403 (Prohibido)
POST /users/delete/123 -> 200 (Permitido)


  Esto puede indicar una falta de control de acceso a nivel de función.

• Parámetros alternativos:
  Sustituir el nombre del parámetro por otros similares puede producir resultados inesperados.

  GET /api/albums?album_id=12
GET /api/albums?account_id=12


• Uso de caracteres especiales o rutas relativas:
  Manipular rutas con secuencias como ../ puede eludir validaciones.

  POST /users/delete/my_id/..victim_id


• Cambio de tipo de contenido:
  Modificar el encabezado Content-Type puede alterar la lógica de validación.

  Content-Type: application/xml
Content-Type: application/json


• IDs numéricos vs. alfanuméricos:
  Algunas aplicaciones aceptan tanto números como cadenas.

  GET /file?id=302
GET /file?id=ab12cd34


• Versiones antiguas de API:
  En sistemas con versiones múltiples, las antiguas pueden carecer de controles.

  GET /v3/users_data/123 -> 401
GET /v1/users_data/123 -> 200


Variantes avanzadas y técnicas complementarias

Los atacantes más experimentados aplican variantes del ataque para burlar controles superficiales. Entre ellas se encuentran:

• Cambio de mayúsculas/minúsculas en rutas:
  Algunos servidores diferencian entre /admin y /Admin, lo que puede abrir brechas.

• Uso de comodines (*) en URLs:
  Sustituir un identificador por un asterisco puede devolver todos los registros.

• Pollution de parámetros:
  Enviar múltiples valores para el mismo parámetro puede confundir al backend:

  GET /api/messages?user_id=1&user_id=2


• Envoltorios en JSON:
  A veces, envolver el ID dentro de un array u objeto anidado evita los filtros:

  {"userid": [123]}
{"userid": {"userid": 123}}


• Cambio de formato de archivo:
  Intentar con extensiones como .json, .xml, .txt o .config puede exponer datos adicionales.

Detección y herramientas útiles

La detección de IDOR requiere una mentalidad inquisitiva y el uso de herramientas que faciliten la observación del tráfico. Algunas recomendaciones son:

• Burp Suite Professional: Ideal para interceptar y modificar solicitudes HTTP/HTTPS en tiempo real.

• Paramalyzer: Extensión de Burp que recuerda los parámetros usados para identificar patrones.

• Arjun y ParamMiner: Herramientas para descubrir parámetros ocultos o no documentados.

• GraphQL Playground / Insomnia: Útiles para explorar APIs GraphQL que podrían ser vulnerables.

Además, Google Dorking puede ayudar a identificar endpoints públicos con parámetros id, user, account, etc., indexados por motores de búsqueda.

Cómo prevenir vulnerabilidades IDOR

La prevención de este tipo de fallas depende, en gran medida, de implementar controles de acceso robustos y de no confiar únicamente en los datos proporcionados por el cliente. Algunas prácticas esenciales incluyen:

1. Validar la autorización en el servidor.
   Cada solicitud debe verificar si el usuario autenticado tiene permiso para acceder al recurso solicitado.

2. Usar identificadores indirectos.
   En lugar de usar IDs incrementales, utilizar UUIDs o identificadores aleatorios que no puedan predecirse.

3. Implementar controles a nivel de función.
   Verificar permisos no solo a nivel de recurso, sino también en las operaciones permitidas (lectura, edición, eliminación).

4. Evitar exponer información sensible.
   No incluir en las respuestas datos como user_id, email o rutas internas innecesarias.

5. Auditorías y pruebas continuas.
   Los test de penetración periódicos y revisiones de código ayudan a detectar fallas antes de que lo hagan los atacantes.

El IDOR es una vulnerabilidad tan sencilla como devastadora. Su eficacia radica en la confianza implícita que muchas aplicaciones depositan en el cliente, asumiendo que el usuario no alterará los parámetros enviados. Esa suposición es precisamente la grieta que los atacantes explotan.

Mitigar este riesgo no requiere tecnologías costosas, sino disciplina en el desarrollo seguro, controles de acceso bien diseñados y una mentalidad proactiva frente a la seguridad. En última instancia, un sistema es tan fuerte como su eslabón más débil, y los IDOR han demostrado ser ese punto débil una y otra vez.