IDOR — Un solo if faltó para exponer 900.000 registros

Al finalizar este tema

Podrás explicar qué es una vulnerabilidad IDOR y conocerás los patrones para prevenirla en el código del servidor.

Lo ocurrido en la Universidad Nacional Abierta de Corea

Al consultar una solicitud de admisión en el sitio web de la Universidad Nacional Abierta de Corea, la URL tiene este aspecto:

text

https://www.knou.ac.kr/application?id=12345

Alguien cambió este número por 12346. Como resultado, se abrió directamente la solicitud de otra persona. Se mostraron todos los datos: nombre, fecha de nacimiento, correo electrónico, número de teléfono, número de cuenta bancaria y universidad de origen.

Si incrementas el número de uno en uno repetidamente, ¿qué ocurre? Pudiste extraer aproximadamente 900.000 solicitudes correspondientes a 10 años. No se requirieron conocimientos avanzados de hacking; bastaba con cambiar un solo número en la URL.

Causa: El servidor no preguntó "¿quién eres?"

Es probable que el código del servidor fuera algo así:

javascript

// ❌ Código peligroso
app.get('/application', async (req, res) => {
  const id = req.query.id;
  const app = await db.findOne({ id });
  res.json(app);  // No comprueba quién hizo la solicitud
});

Solo mirando el número en la URL (id=12345), extrae los datos directamente. No verifica en absoluto si quien envía esta solicitud es el propietario de la solicitud de empleo número 12345.

Esta vulnerabilidad se conoce como IDOR (Referencia Directa a Objetos Insegura). La traducción literal es "Referencia Directa a Objetos Insegura": se trata de usar directamente un ID presente en la URL o parámetros para extraer datos sin validación alguna.

Solución: Una sola línea

javascript

// ✅ Código seguro
app.get('/application', async (req, res) => {
  const id = req.query.id;
  const app = await db.findOne({ id });

  if (app.userId !== req.user.id) {       // ← Esta línea
    return res.status(403).send('Sin autorización');
  }

  res.json(app);
});

Es un único condicional if que compara si la persona que realiza la solicitud es el mismo que el "propietario de los datos". Eso es todo. La ausencia de esta sola línea provocó la filtración de 900.000 registros.

Lecciones de este incidente

IDOR no es una técnica de hacking avanzada. Basta con cambiar un número en la URL, por lo que cualquier persona sin conocimientos de desarrollo puede explotarla. Por ello, su frecuencia de aparición es alta.

Al escribir el código del servidor, siempre se debe asumir esta premisa:

Todo lo que envía el usuario puede ser falsificado.

URLs, cookies, datos de formularios, encabezados — todos los valores provenientes del cliente pueden ser manipulados. Por lo tanto, el servidor debe verificar obligatoriamente: "¿Tiene esta persona autorización para acceder a estos datos?"

Este principio es la base de toda la seguridad del servidor, no solo para IDOR.

Lugares donde suele ocurrir IDOR

IDOR puede ocurrir en cualquier lugar donde el servidor omita la verificación de permisos. Los patrones comunes son:

Descarga de archivos — /download?file=report_001.pdf → Al cambiar el nombre del archivo, se descargan informes ajenos
Configuración de cuentas — /api/user/42/settings → Al cambiar el ID por 43, se ven las configuraciones de otros usuarios
Historial de pedidos — /order/12345 → Al cambiar el número de pedido, se ven los detalles de pedidos ajenos
Restablecimiento de contraseña — /reset?token=abc&user_id=42 → Al cambiar el user_id, se puede restablecer la contraseña de otros usuarios

El punto común es que todos ellos exponen identificadores (IDs) en la URL o parámetros. El hecho de que el ID esté expuesto no es un problema en sí mismo; basta con que el servidor verifique "¿Tiene esta persona autorización para acceder a este ID?". Si falta esta verificación, se trata de IDOR.

"Broken Access Control" (Control de acceso roto), la categoría superior a la que pertenece IDOR, ocupa el primer lugar en el Top 10 de vulnerabilidades publicado anualmente por OWASP (organismo estándar de seguridad web) desde 2021. Esto refleja su alta frecuencia de aparición y lo fácil que es mitigarla.

Para prevenirlo, resumiendo: asegúrese de que todas las APIs de acceso a datos pasen obligatoriamente por dos pasos: (1) Verificación de inicio de sesión → (2) Verificación de coincidencia entre el solicitante y el propietario de los datos. Con estas dos líneas, IDOR se bloquea de raíz.

Clave

IDOR es una vulnerabilidad donde al cambiar el ID en la URL se pueden ver los datos de otros usuarios. La causa es que el servidor no verificó si "solicitante = propietario de los datos", y La solución es una sola línea if. Asuma siempre que las entradas del usuario pueden ser falsificadas.

BioPlayground

IDOR: un solo `if` faltante provocó la filtración de 900.000 registros