Ataque IDOR (Referencia Directa Insegura a Objetos)

Cómo Funciona Ataque IDOR (Referencia Directa Insegura a Objetos)

Las vulnerabilidades IDOR surgen cuando los desarrolladores confían en los identificadores proporcionados por el cliente sin verificar que el usuario tiene permiso para acceder al objeto referenciado. Los patrones comunes incluyen IDs secuenciales o predecibles en URLs (por ejemplo, /orders/123), parámetros de API (?userId=456) o campos de formulario. Los atacantes enumeran o adivinan estos identificadores para acceder a los datos de otros usuarios. La vulnerabilidad existe completamente en el lado del servidor — incluso si el frontend restringe el acceso de la interfaz, un atacante determinado puede eludirlo construyendo solicitudes directas.

Ejemplos Reales

Impacto y Evaluación de Riesgo

Los ataques IDOR conducen a acceso no autorizado a datos, violaciones de privacidad, toma de cuentas, fraude y violaciones regulatorias. Los atacantes pueden robar información personal (exposición a GDPR, CCPA), datos financieros, propiedad intelectual o realizar transacciones fraudulentas. El impacto escala con la sensibilidad de la aplicación: las aplicaciones de salud exponen registros médicos, las aplicaciones financieras permiten lavado de dinero, los sistemas gubernamentales revelan información clasificada. Las organizaciones enfrentan responsabilidad legal, daño reputacional y pérdida de confianza de los clientes. IDOR se clasifica consistentemente entre los principales riesgos de seguridad de OWASP debido a su prevalencia y graves consecuencias.

Cómo Detectar Ataque IDOR (Referencia Directa Insegura a Objetos)

Monitorear patrones de acceso anormales: enumeración rápida de IDs secuenciales, solicitudes a objetos que el usuario no debería acceder o intentos de acceso entre múltiples tenants. Registrar todas las verificaciones de control de acceso con identificadores de usuario y objeto. Implementar registros de auditoría para el acceso a datos sensibles. Usar pruebas automatizadas para buscar patrones de IDs predecibles en APIs y endpoints. Realizar pruebas de penetración enfocadas en el control de acceso, particularmente en endpoints REST y parámetros de URL. Las herramientas de análisis estático pueden detectar patrones donde los IDs se usan sin verificaciones de autorización.

Cómo Prevenir Ataque IDOR (Referencia Directa Insegura a Objetos)

Implementar verificaciones de autorización adecuadas para cada referencia directa a objetos. Nunca confiar en los identificadores proporcionados por el cliente — siempre verificar que el usuario tiene permiso para acceder al recurso solicitado. Usar referencias indirectas a objetos: mapear IDs internos a tokens imposibles de adivinar (UUIDs, cadenas aleatorias) y mantener tablas de mapeo en el servidor. Implementar control de acceso basado en roles (RBAC) o control de acceso basado en atributos (ABAC). Para aplicaciones multi-tenant, aplicar aislamiento estricto de tenants en las capas de base de datos y aplicación. Usar autorización a nivel de framework (por ejemplo, Django @login_required, Spring Security @PreAuthorize) en lugar de verificaciones manuales. Realizar revisiones de código de seguridad enfocadas en patrones de control de acceso. Probar los límites de autenticación vs. autorización regularmente.

Ejemplos de Código

@app.route('/orders/<int:order_id>')
def get_order(order_id):
    # VULNERABLE: No check if user owns this order
    order = Order.query.get(order_id)
    if not order:
        return 'Order not found', 404
    return jsonify(order.to_dict())

# Attacker can access any order by changing order_id in URL
# /orders/42, /orders/43, /orders/44, etc.

from flask_login import current_user

@app.route('/orders/<int:order_id>')
def get_order(order_id):
    # SECURE: Verify ownership before returning data
    order = Order.query.get(order_id)
    
    if not order:
        return 'Order not found', 404
    
    if order.user_id != current_user.id:
        # Log unauthorized access attempt
        log_security_event(
            'idor_attempt',
            user=current_user.id,
            attempted_order=order_id
        )
        return 'Access denied', 403
    
    return jsonify(order.to_dict())

const authorizeOwnership = (modelName) => {
  return async (req, res, next) => {
    const resourceId = req.params.id;
    const userId = req.user.id;
    
    try {
      const Model = mongoose.model(modelName);
      const resource = await Model.findById(resourceId);
      
      if (!resource) {
        return res.status(404).json({ error: 'Resource not found' });
      }
      
      // Check if user owns the resource or has admin role
      const hasAccess = resource.userId?.equals(userId) || 
                       req.user.role === 'admin';
      
      if (!hasAccess) {
        // Log the IDOR attempt
        await SecurityLog.create({
          type: 'idor_attempt',
          userId,
          resourceId,
          modelName,
          ip: req.ip
        });
        return res.status(403).json({ error: 'Access denied' });
      }
      
      // Attach resource to request for use in route handler
      req.resource = resource;
      next();
    } catch (error) {
      return res.status(500).json({ error: 'Server error' });
    }
  };
};

// Usage
router.get('/orders/:id', authenticate, authorizeOwnership('Order'), getOrder);

Preguntas Frecuentes

Ataques Relacionados