Mitigación de IDOR: guía de remediación

Mitigación de IDOR mediante controles de autorización en aplicaciones web.
Guía de remediación

La mitigación de IDOR busca impedir que un usuario autenticado acceda, modifique o elimine objetos que pertenecen a otras personas mediante la manipulación de identificadores. Esta guía presenta controles de autorización en backend, ejemplos en PHP/PDO y Node.js/Express, y una validación posterior basada en una matriz de acceso.

Ficha de la remediación

ID01 de Referencia

SEC-BAC-01

CWE

CWE-639 (Authorization Bypass Through User-Controlled Key) / CWE-284 (Improper Access Control)

Severidad

Alta / Crítica

A01:2025 – Broken Access Control Control de Acceso

Descripción del fallo

Una vulnerabilidad IDOR (Insecure Direct Object Reference) ocurre cuando una aplicación utiliza una entrada provista por el usuario para acceder directamente a un objeto o recurso en la base de datos (por ejemplo, /api/invoice?id=1024 o /user/profile/55) sin validar si el usuario autenticado tiene permisos legítimos para acceder a dicho recurso.

Un atacante puede simplemente modificar el parámetro numérico o el identificador en la petición para leer, editar o eliminar registros pertenecientes a otros usuarios del sistema.

Alcance y prerrequisitos

Gestión de identidades y sesiones

Implementación de un sistema de gestión de identidades y sesiones (tokens JWT, cookies de sesión).

Acceso requerido

Acceso al código fuente backend donde se procesan las consultas a la base de datos y la lógica de negocio.

Impacto técnico y de negocio

Impacto técnico

La falta de autorización a nivel de objeto puede permitir la lectura, edición o eliminación de registros ajenos, aunque el atacante tenga una sesión válida con privilegios limitados.

Impacto de negocio

El acceso indebido a facturas, perfiles, órdenes o documentos puede comprometer la confidencialidad y la integridad de la información, afectar la confianza y generar impactos operativos, reputacionales o de cumplimiento.

Cómo implementar la mitigación de IDOR

La solución requiere implementar controles de acceso basados en el contexto de la sesión activa y no confiar únicamente en los parámetros enviados por el cliente. opcionalmente, se pueden utilizar identificadores no predecibles (UUIDs).

1

Remediación Principal: Validación de Pertenencia/Permisos en Backend

❌ Código Vulnerable (PHP / PDO):

// Consulta directa usando el ID enviado por el usuario sin verificar propiedad
$invoice_id = $_GET['id'];
$stmt = $pdo->prepare("SELECT * FROM invoices WHERE id = :id");
$stmt->execute(['id' => $invoice_id]);
$invoice = $stmt->fetch(); // Retorna la factura de CUALQUIER usuario

✅ Código Remediado (PHP / PDO):

// Validar que el objeto pertenezca al usuario autenticado en la sesión
$user_id = $_SESSION['user_id'];
$invoice_id = $_GET['id'];

$stmt = $pdo->prepare("SELECT * FROM invoices WHERE id = :invoice_id AND user_id = :user_id");
$stmt->execute(['invoice_id' => $invoice_id, 'user_id' => $user_id]);
$invoice = $stmt->fetch();

if (!$invoice) {
    http_response_code(403);
    echo json_encode(["error" => "Acceso denegado o recurso no encontrado"]);
    exit();
}
2

Remediación en Frameworks Modernos (Uso de Políticas/Middleware)

Ejemplo en Node.js / Express (Con verificación explicita):

app.get('/api/orders/:orderId', async (req, res) => {
 const { orderId } = req.params;
 const currentUserId = req.user.id; // Obtenido del JWT/Sesión validada

 const order = await Order.findOne({ _id: orderId });

 // Verificación de autorización explícita
 if (!order || order.userId !== currentUserId) {
   return res.status(403).json({ error: 'No tiene permisos para ver esta orden' });
 }

  res.json(order);
});
3

Medida Complementaria: Uso de UUIDs (Identificadores Unívocos Aleatorios)

En lugar de exponer IDs secuenciales (1, 2, 3), utiliza UUIDv4 (e43f1122-38a6-4b88-b219-91896a848a31). Aunque no reemplaza la validación de autorización en el servidor, dificulta la enumeración masiva por fuerza bruta.

Verificación posterior a la remediación

1

Pruebas de Control de Acceso (Matriz de Autorización)

  1. Inicia sesión con el Usuario A y solicita un recurso propio (ej. /api/documents/101).
  2. Inicia sesión con el Usuario B y anota su ID de recurso (ej. /api/documents/102).
  3. Con la sesión del Usuario A, intenta acceder a /api/documents/102.
EstadoComportamiento observado o esperado
Comportamiento VulnerableEl Usuario A puede ver el documento 102 del Usuario B (Respuesta 200 OK).
Comportamiento RemediadoLa aplicación retorna un código de error 403 Forbidden o 404 Not Found.

Riesgos residuales y limitaciones

Los UUIDs no sustituyen la autorización

El documento establece que los identificadores no predecibles dificultan la enumeración, pero no reemplazan la validación de permisos en el servidor.

Rollback no suministrado

El documento fuente no incluye un procedimiento de reversión. Cualquier rollback debe definirse y probarse de acuerdo con la arquitectura, el modelo de autorización y el proceso de despliegue de la aplicación.

Recomendaciones complementarias

La mitigación de IDOR debe aplicarse en cada operación sobre objetos —consulta, creación, actualización, descarga y eliminación— y no solo en las rutas usadas como ejemplo.

Centralizar las políticas

Use políticas, middleware o funciones de autorización reutilizables para reducir diferencias de implementación entre endpoints y operaciones.

Ampliar la matriz de pruebas

Incluya distintos roles, organizaciones, estados del recurso y métodos HTTP, y compruebe tanto accesos horizontales como escalamiento vertical de privilegios.

Registrar intentos denegados

Monitoree patrones de enumeración y accesos rechazados sin revelar en la respuesta si un objeto ajeno existe o cuáles son sus atributos.

¿Cómo puede apoyar Password?

Password Consulting Services puede acompañar la identificación y validación de fallas IDOR mediante Pentesting Avanzado y pruebas de código SAST/DAST. El objetivo es evaluar la autorización a nivel de objeto, verificar la eficacia de los controles implementados y fortalecer el ciclo de desarrollo seguro. También puede consultar otras guías de remediación relacionadas con el control de acceso.

Valide los controles de acceso de sus aplicaciones

Conozca cómo Password puede acompañar la evaluación técnica de autorizaciones y la validación posterior de la remediación.

Solicitar diagnóstico

Preguntas frecuentes

¿Qué diferencia existe entre autenticación y autorización frente a IDOR?

La autenticación confirma quién es el usuario; la autorización determina qué objetos y acciones puede utilizar. Una sesión válida no debe permitir acceso automático a cualquier identificador recibido por la aplicación.

¿Cambiar identificadores secuenciales por UUID elimina IDOR?

No. Los UUID dificultan la enumeración, pero cada solicitud debe validar en el servidor que el usuario autenticado tenga permisos sobre el objeto solicitado.

¿Es preferible responder 403 Forbidden o 404 Not Found?

El documento contempla ambos resultados como comportamiento remediado. La elección debe ser consistente con la política de respuestas de la aplicación y evitar revelar innecesariamente la existencia de recursos ajenos.

¿Cómo comprobar que la mitigación de IDOR quedó aplicada?

Construya una matriz con al menos dos usuarios y recursos distintos, intente acceder al objeto ajeno desde la sesión incorrecta y confirme que la aplicación responda 403 o 404 sin entregar el contenido.

Scroll to top
Llamar Llamar