Cambia un número en la URL y accedes a la cuenta de otro

Lo que necesitas: un navegador. Nada más.

---

¿Qué es IDOR?

Cuando inicias sesión en una web y vas a ver tu perfil, la URL suele tener un número que te identifica:

https://web.com/perfil?id=1042

Ese número es tu ID de usuario. El servidor recibe ese número, busca al usuario con ese ID en la base de datos, y te muestra su perfil.

El problema: hay webs que no comprueban si el usuario que hace la petición tiene permiso para ver ese perfil. Solo cogen el número que les llega y devuelven los datos. Si cambias el 1042 por 1041, puede que veas el perfil de otra persona. Si cambias a 1, puede que veas el del administrador.

Eso es IDOR — el servidor confía ciegamente en el número que le mandas sin verificar que eres tú quien debería verlo.

---

¿Cómo se explota?

Paso 1 — encuentra un ID en la URL

Busca cualquier número en la URL mientras navegas por la web:

/perfil?id=1042
/pedido?order=8821
/factura/download/334
/mensaje?thread=77

Cualquier número que identifique un recurso (un pedido, un mensaje, un documento, un usuario) es un candidato.

Paso 2 — cámbialo

Modifica el número directamente en la barra de direcciones del navegador. Prueba con el número anterior, el siguiente, o números pequeños como 1, 2, 3 (los primeros registros suelen ser los más interesantes — admins, usuarios de prueba, datos de configuración).

/perfil?id=1041   ← usuario anterior
/perfil?id=1      ← primer usuario creado (probablemente admin)
/perfil?id=9999   ← un número al azar

Paso 3 — observa la respuesta

Si ves información que no es tuya sin que el servidor te haya pedido autorización, el fallo existe. Si ves un error o te redirige al login, está protegido.

Paso 4 — prueba otros recursos

El mismo fallo puede existir en más sitios de la misma web. Si funciona con perfiles, prueba con pedidos, facturas, mensajes privados, o cualquier otro recurso que tenga un ID en la URL.

---

¿Por qué es peligroso?

IDOR no es un fallo técnico complejo — es simplemente que el servidor no comprueba “¿tiene este usuario permiso para ver este recurso?”. Con este fallo se pueden robar:

• Datos personales de cualquier usuario (nombre, dirección, teléfono)
• Historial de pedidos y facturas
• Mensajes privados
• Documentos confidenciales
• Contraseñas si están guardadas sin hash

En 2019, una vulnerabilidad IDOR en Facebook permitía ver los números de teléfono de cualquier usuario. En 2021, Parler expuso 70 millones de posts de usuarios privados por exactamente este fallo. Es uno de los fallos más comunes en aplicaciones reales.

---

🎯 Tu reto

El laboratorio tiene una sección de pedidos. Inicia sesión con las credenciales de prueba y encuentra los pedidos de otros usuarios accediendo a IDs que no son los tuyos.

---

🛡️ Cómo se protege

La solución es siempre la misma: en el servidor, antes de devolver cualquier recurso, comprobar que el usuario que pide tiene permiso para verlo.

# ❌ Vulnerable — devuelve el pedido solo con el ID
@app.route('/pedido')
def pedido():
    order_id = request.args.get('id')
    order = db.get_order(order_id)
    return render(order)

# ✅ Seguro — comprueba que el pedido pertenece al usuario actual
@app.route('/pedido')
def pedido():
    order_id = request.args.get('id')
    order = db.get_order(order_id)
    if order.user_id != current_user.id:
        abort(403)  # Prohibido
    return render(order)

También se pueden usar IDs no predecibles (UUIDs en vez de números secuenciales):

/pedido?id=f47ac10b-58cc-4372-a567-0e02b2c3d479

Un UUID aleatorio es imposible de adivinar, lo que hace mucho más difícil acceder a recursos ajenos incluso si la comprobación de permisos falla. Pero ojo: esto es una capa extra de seguridad, no un sustituto de la comprobación real.

---