IDOR (Insecure Direct Object Reference)

¿Qué es IDOR?

IDOR (Insecure Direct Object Reference, o Referencia Directa a Objetos Insegura) es una vulnerabilidad de control de acceso que ocurre cuando una aplicación web expone referencias directas a objetos internos del sistema sin validar adecuadamente si el usuario tiene permisos para acceder a ellos.

Ejemplo simple

# Usuario legítimo accede a su perfil
https://ejemplo.com/perfil?id=1234

# Atacante simplemente cambia el ID
https://ejemplo.com/perfil?id=5678
                              ↑
                   ID de otro usuario

# Si no hay control de acceso... ¡bingo!
# El atacante ve datos del usuario 5678

Cómo funciona un ataque IDOR

1. Identificación de referencias

El atacante busca parámetros que referencien objetos internos:

2. Manipulación sistemática

# Script simple para enumerar usuarios
for user_id in range(1, 10000):
    url = f"https://ejemplo.com/api/user?id={user_id}"
    response = requests.get(url)

    if response.status_code == 200:
        print(f"✓ Usuario {user_id}: {response.json()}")
        # Guardar datos...

3. Exfiltración masiva

En el caso de Hacienda (alerta feb 2026), el supuesto atacante habría:

# Enumeración secuencial de DNI/NIE
12345678A → petición → datos fiscal completo
12345679B → petición → datos fiscal completo
12345680C → petición → datos fiscal completo
...
# 47.300.000 registros después...

¿Por qué es tan peligrosa?

1. Extremadamente simple de explotar

No requiere:

• ❌ Conocimientos avanzados de hacking
• ❌ Herramientas sofisticadas
• ❌ Vulnerabilidades complejas como SQLi o XSS

Solo requiere:

• ✅ Un navegador web (o script básico)
• ✅ Capacidad de modificar URLs
• ✅ Paciencia para enumerar

2. Difícil de detectar automáticamente

# Herramientas automáticas ven esto como "funcionando correctamente"
GET /user?id=123 → 200 OK ✓
GET /user?id=124 → 200 OK ✓
GET /user?id=125 → 200 OK ✓

# Pero no detectan que el usuario NO debería poder
# acceder a IDs 124 y 125

Los escáneres de vulnerabilidades estándar no pueden identificar IDOR porque:

• Respuestas HTTP son “normales” (200 OK)
• No hay errores de base de datos
• No hay alertas en logs
• Funciona “como se diseñó” (mal)

3. Impacto devastador

4. Clasificación OWASP Top 10

IDOR pertenece a Broken Access Control (#1 en OWASP Top 10 2021), la categoría más crítica de vulnerabilidades web.

Casos reales documentados

1. Hacienda España (alerta 2026)

Fecha: Febrero 2026 Afectados: 47,3 millones de ciudadanos (supuestamente) Método: IDOR + credenciales filtradas Estado: Hacienda descarta el ataque, investigación continúa

Análisis completo del caso

2. IDOR en plataformas educativas

Problema común: Profesores pueden ver notas de cualquier estudiante cambiando ?student_id=

# Profesor ve a su alumno
/grades?student_id=123&teacher_id=456

# Profesor cambia student_id
/grades?student_id=999&teacher_id=456
           ↑
    Alumno de otro profesor

# Acceso concedido → IDOR

3. IDOR en sistemas de salud

Caso hipotético: Paciente accede a su historial médico:

# Mi historial
https://hospital.com/historial?paciente=12345

# Cambio el número
https://hospital.com/historial?paciente=12346
                                          ↑
                              Historial de otra persona

# Si funciona → RGPD violation + IDOR

Cómo detectar IDOR como perito forense

1. Análisis de logs del servidor

Busco patrones de enumeración secuencial:

# Ejemplo de análisis forense
cat access.log | \
  grep "declaracion?id=" | \
  awk '{print $1, $7}' | \
  sort | uniq -c | sort -rn

# Resultado sospechoso:
# 47.300.000 requests desde 185.220.101.42
# IDs: 12345678A, 12345679B, 12345680C...
# Tiempo: 72 horas
# Conclusión: IDOR automatizado

Indicadores de ataque IDOR:

• ✅ Volumen anómalo de peticiones (millones en poco tiempo)
• ✅ Enumeración secuencial de identificadores
• ✅ Todas las respuestas HTTP 200 (sin rechazos)
• ✅ Misma IP o rango IP sospechoso
• ✅ Tiempo de respuesta constante (no hay validación)

2. Revisión de código fuente

# VULNERABLE ❌
@app.route('/declaracion')
def get_declaracion():
    dni = request.args.get('dni')

    # Consulta directa sin validación
    data = db.query(
        "SELECT * FROM declaraciones WHERE dni = ?",
        dni
    )

    return jsonify(data)  # Cualquiera puede ver cualquier DNI


# SEGURO ✅
@app.route('/declaracion')
@require_authentication
def get_declaracion():
    dni = request.args.get('dni')
    user_dni = get_authenticated_user_dni()

    # Validación: solo puedes ver TU declaración
    if dni != user_dni and not is_admin():
        log_security_event(
            "IDOR attempt",
            user_dni,
            dni,
            request.remote_addr
        )
        return jsonify({"error": "Unauthorized"}), 403

    data = db.query(
        "SELECT * FROM declaraciones WHERE dni = ?",
        dni
    )

    return jsonify(data)

3. Análisis de tráfico de red

Con herramientas EDR/SIEM:

-- Detectar enumeración IDOR en SIEM
SELECT
  source_ip,
  COUNT(*) as requests,
  MIN(timestamp) as first_seen,
  MAX(timestamp) as last_seen
FROM http_logs
WHERE url LIKE '%?id=%'
GROUP BY source_ip
HAVING COUNT(*) > 1000
ORDER BY requests DESC;

-- Si una IP hace >1000 requests a endpoints con ?id=
-- → Investigar posible IDOR

4. Forensic artifacts

Si sospecho exfiltración masiva:

# 1. Imagen forense del servidor
dd if=/dev/sda of=server.dd bs=4M
sha256sum server.dd > evidence.hash

# 2. Extracción de logs
tar czf logs_$(date +%F).tar.gz /var/log/apache2/*.log
sha256sum logs_*.tar.gz >> evidence.hash

# 3. Análisis de tráfico saliente (¿exfiltración?)
tcpdump -r capture.pcap 'tcp port 443' | \
  grep -E "(POST|GET)" | \
  awk '{print $3, $5}' | sort | uniq -c

# 4. Búsqueda en dark web
# ¿Aparecen los datos en foros clandestinos?

Cómo prevenir IDOR

1. Implementar control de acceso adecuado

# REGLA DE ORO: NUNCA confíes en IDs proporcionados por el usuario

def get_user_profile(user_id_from_url):
    authenticated_user = get_current_user()

    # Verificación OBLIGATORIA
    if user_id_from_url != authenticated_user.id:
        if not authenticated_user.has_role('admin'):
            raise Unauthorized("Cannot access other user's profile")

    return database.get_user(user_id_from_url)

2. Usar referencias indirectas

En lugar de exponer IDs directos:

# MAL: ID directo en URL ❌
/invoice?id=12345

# BIEN: Token aleatorio no predecible ✅
/invoice?token=7f3a9c2e-5b1d-4e8f-9a3c-2d1f5e8a9c7b

# Mapeo interno:
# token → invoice_id + user_id
# Validar: invoice pertenece a user_id autenticado

3. Validación en cada petición

# Middleware de validación
@app.before_request
def validate_access():
    endpoint = request.endpoint
    resource_id = request.args.get('id') or request.view_args.get('id')

    if resource_id and not can_access(current_user, resource_id):
        log_security_event(
            event="access_denied",
            user=current_user.id,
            resource=resource_id,
            ip=request.remote_addr
        )
        abort(403)

4. Rate limiting

# Limitar requests por usuario
@limiter.limit("100 per minute")
@app.route('/api/user')
def get_user():
    # Si excede límite → 429 Too Many Requests
    pass

# Esto previene enumeración masiva

5. Logging y alertas

# Detectar patrones sospechosos
if user_accessed_resources > 100 in last_hour:
    alert_security_team(
        "Possible IDOR enumeration",
        user_id,
        resources_accessed
    )

Desde la perspectiva legal

RGPD y IDOR

Una vulnerabilidad IDOR que exponga datos personales constituye:

1. Brecha de seguridad (Art. 33 RGPD)

   • Obligación de notificar a AEPD en 72 horas
   • Notificar a afectados si hay “alto riesgo”

2. Medidas técnicas insuficientes (Art. 32 RGPD)

   • Posible sanción: hasta 10M€ o 2% facturación global
   • Control de acceso es medida técnica básica

3. Responsabilidad del responsable del tratamiento

   • No es culpa del usuario que “descubrió” la vuln
   • Es responsabilidad de quien no implementó controles

Como perito informático

En casos judiciales relacionados con IDOR, mi informe pericial documenta:

✅ Existencia de la vulnerabilidad ✅ Alcance del acceso no autorizado ✅ Análisis de logs (quién, cuándo, qué) ✅ Evaluación de medidas de seguridad ✅ Estimación de datos comprometidos ✅ Cadena de custodia de evidencias

Herramientas para testing de IDOR

Herramientas profesionales

Ejemplo de script de testing

import requests

def test_idor(base_url, my_id, test_ids):
    """
    Prueba IDOR en un endpoint
    """
    headers = {"Authorization": "Bearer MY_TOKEN"}

    results = []

    for test_id in test_ids:
        url = f"{base_url}?id={test_id}"
        response = requests.get(url, headers=headers)

        if response.status_code == 200:
            results.append({
                "id": test_id,
                "vulnerable": test_id != my_id,
                "data": response.json()
            })

    return results

# Ejemplo de uso
vulnerable = test_idor(
    "https://api.example.com/user",
    my_id=1234,
    test_ids=[1235, 1236, 1237, 1238]  # IDs ajenos
)

if any(r['vulnerable'] for r in vulnerable):
    print("⚠️  IDOR VULNERABILITY DETECTED")

Checklist de seguridad para desarrolladores

Si eres desarrollador, verifica:

• Cada endpoint valida que el usuario autenticado tiene permiso para acceder al recurso solicitado
• No expones IDs secuenciales predecibles en URLs
• Usas referencias indirectas (UUIDs, tokens) cuando es posible
• Implementas rate limiting para prevenir enumeración
• Logs registran todos los accesos a recursos sensibles
• Alertas automáticas ante patrones de enumeración
• Tests de seguridad incluyen casos de IDOR
• Code review específico para control de acceso

Cuándo necesitas un perito informático

Contacta conmigo si:

✅ Sospechas que tu aplicación tiene vulnerabilidad IDOR ✅ Has detectado accesos no autorizados en logs ✅ Necesitas auditoría de seguridad de control de acceso ✅ Requieres informe pericial para proceso legal ✅ Has sufrido exfiltración de datos vía IDOR ✅ Necesitas análisis forense post-incidente

Como perito informático forense, realizo:

• 🔍 Análisis técnico de vulnerabilidades IDOR
• 📊 Revisión de logs y detección de exfiltración
• 🛡️ Auditorías de control de acceso
• 📄 Informes periciales con validez judicial
• 🔐 Recomendaciones de remediación
• ⚖️ Testimonio experto en juicio si es necesario

Referencias técnicas

• OWASP: Insecure Direct Object Reference Prevention
• OWASP Top 10 2021: A01 Broken Access Control
• PortSwigger: IDOR Vulnerabilities
• CWE-639: Authorization Bypass Through User-Controlled Key

Nota del perito: IDOR es una de las vulnerabilidades más subestimadas pero más explotadas en aplicaciones web. Su simplicidad de explotación combinada con su dificultad de detección la convierte en un vector de ataque preferido por atacantes de todos los niveles.