BOLA/IdOR en APIs

BOLA significa Broken Object Level Authorization (Autorización Rota a Nivel de Objeto), también conocido como Insecure Direct Object Reference (IDOR). Esta vulnerabilidad ocurre cuando una API falla al verificar adecuadamente si un usuario está autorizado para acceder a un objeto específico (registro de datos) según su identidad y permisos.

La vulnerabilidad obtiene su nombre del patrón de ataque típico: un atacante modifica el identificador del objeto en una solicitud API para acceder a recursos que pertenecen a otros usuarios. Por ejemplo, cambiando un ID de usuario o documento en la URL o cuerpo de la solicitud para acceder a los datos de otra persona.

Considera este patrón vulnerable:

GET /api/users/123/profile HTTP/1.1
Authorization: Bearer valid.token

Si la API solo valida que el token es válido pero no verifica si el usuario '123' pertenece al usuario autenticado, un atacante puede simplemente cambiar '123' por cualquier otro ID de usuario y acceder a su perfil.

Según OWASP API Top 10, BOLA es el #1 riesgo de seguridad API más crítico porque es generalizado, fácil de explotar y puede llevar a brechas completas de datos.

Las vulnerabilidades BOLA pueden tener consecuencias graves dependiendo de qué datos exponga la API. Escenarios de ataque comunes incluyen:

• Robo de Datos: Acceder a la información personal, registros financieros, datos de salud o información comercial confidencial de otros usuarios
• Escalada de Privilegios: Modificar o eliminar recursos que pertenecen a otros usuarios
• Abuso de Lógica de Negocio: Explotar flujos de trabajo que dependen de la propiedad de objetos (como sistemas de pago, gestión de pedidos)

Ejemplos de impacto en el mundo real:

GET /api/orders/456/details HTTP/1.1
Authorization: Bearer valid.token

Un atacante podría enumerar IDs de pedidos para ver todos los pedidos de clientes, direcciones de envío e información de pago. En una API de salud:

GET /api/patients/789/records HTTP/1.1
Authorization: Bearer valid.token

Esto podría exponer registros médicos sensibles si la API no verifica la relación paciente-médico.

BOLA a menudo aparece en APIs RESTful donde los IDs de recursos son predecibles (números secuenciales, UUIDs, direcciones de correo). La vulnerabilidad es particularmente peligrosa porque no requiere eludir la autenticación—el atacante usa sus propias credenciales válidas pero accede a los datos equivocados.

Detectar BOLA requiere pruebas sistemáticas de autorización de objetos en todos los endpoints de la API. Aquí está lo que debes buscar:

• Enumeración de Recursos: ¿Puedes acceder a los recursos de otros usuarios cambiando IDs en las solicitudes?
• Límites de Permisos: ¿La API verifica que el usuario autenticado es propietario o tiene permiso para acceder al objeto solicitado?
• Acceso entre Tenants: En sistemas multi-tenant, ¿puede un tenant acceder a los datos de otro tenant?

Enfoque de prueba manual:

# Solicitud original (tus datos)
GET /api/documents/123 HTTP/1.1
Authorization: Bearer your-token

# Solicitud de prueba (datos de otro usuario)
GET /api/documents/124 HTTP/1.1
Authorization: Bearer your-token

Si ambas solicitudes tienen éxito y devuelven datos diferentes, tienes una vulnerabilidad BOLA.

Escaneo automatizado con middleBrick prueba BOLA modificando sistemáticamente los identificadores de objetos en solicitudes API y verificando los controles de autorización. El escáner intenta acceder a recursos usando patrones de ID predecibles (números secuenciales, variaciones de UUID) mientras está autenticado con las credenciales de un solo usuario. Si la API devuelve datos para IDs modificados sin verificación de autorización adecuada, middleBrick marca esto como un hallazgo crítico de BOLA.

La detección de BOLA de middleBrick se ejecuta en paralelo en los 12 controles de seguridad, probando endpoints con diferentes estados de autenticación y modificaciones de identificadores de objetos. El escáner proporciona hallazgos específicos que incluyen el endpoint vulnerable, el parámetro modificado y el nivel de severidad basado en la sensibilidad de los datos expuestos.

Prevenir BOLA requiere implementar controles de autorización adecuados a nivel de objeto. Aquí hay estrategias concretas de remediación:

1. Implementar Autorización a Nivel de Objeto

// Código vulnerable
const userId = req.params.userId;
const userProfile = await db.getUserProfile(userId);
res.json(userProfile);

// Código seguro
const authenticatedUserId = getUserIdFromToken(req);
const requestedUserId = req.params.userId;

if (authenticatedUserId !== requestedUserId) {
    return res.status(403).json({ error: 'Access denied' });
}

const userProfile = await db.getUserProfile(requestedUserId);
res.json(userProfile);

2. Usar Autorización Basada en Políticas

const policies = {
    canAccessUserProfile: (authUserId, targetUserId) => {
        return authUserId === targetUserId;
    },
    canAccessDocument: (authUser, document) => {
        return authUser.role === 'admin' || document.ownerId === authUser.id;
    }
};

// En tu manejador de ruta
const document = await db.getDocument(req.params.docId);
if (!policies.canAccessDocument(authUser, document)) {
    return res.status(403).json({ error: 'Forbidden' });
}

3. Implementar Seguimiento de Propiedad de Recursos

// Esquema de base de datos con propiedad
users:
  id: UUID
  email: string

documents:
  id: UUID
  ownerId: UUID (references users.id)
  content: text

// Consulta con autorización
const document = await db.query(
    'SELECT * FROM documents WHERE id = $1 AND ownerId = $2',
    [req.params.docId, authUserId]
);
if (!document) {
    return res.status(404).json({ error: 'Not found or access denied' });
}

4. Usar UUIDs en lugar de IDs Predecibles

Aunque los UUIDs no previenen BOLA por sí mismos, hacen que los ataques de enumeración sean más difíciles:

// Generar UUIDs seguros
import { v4 as uuidv4 } from 'uuid';

// Almacenar y referenciar usando UUIDs
const docId = uuidv4(); // e.g., 'f47ac10b-58cc-4372-a567-0e02b2c3d479'

El principio clave: nunca asumas que tener un token válido significa que el usuario debería acceder a cualquier recurso específico. Siempre verifica la propiedad del recurso o permisos a nivel de objeto.

Las vulnerabilidades BOLA han causado algunas de las brechas de datos más significativas en los últimos años. Ejemplos notables incluyen:

• CVE-2021-39174: Un popular sistema CRM permitía a los usuarios acceder a los datos de otras organizaciones simplemente cambiando el ID de organización en solicitudes API. Los atacantes podían ver y modificar datos de clientes entre diferentes empresas usando la misma instancia de software.
• Búsqueda por Número de Teléfono de Facebook: Una vulnerabilidad BOLA permitía a los atacantes vincular números de teléfono a cuentas de Facebook enumerando IDs de usuario, exponiendo la configuración de privacidad de millones de usuarios.
• Sistemas Internos de Uber: Los atacantes explotaron BOLA en aplicaciones internas de Uber para acceder a herramientas y datos internos sensibles, lo que llevó a una brecha importante en 2022.

Estos incidentes demuestran que BOLA afecta a empresas de todos los tamaños e industrias. La vulnerabilidad es particularmente común en:

• Aplicaciones SaaS multi-tenant
• APIs de salud y servicios financieros
• Plataformas de e-commerce con cuentas de usuario
• Software empresarial con acceso basado en roles

El costo de las vulnerabilidades BOLA va más allá de las brechas de datos. Las empresas enfrentan multas regulatorias (GDPR, HIPAA), pérdida de confianza del cliente, desventaja competitiva y costosas respuestas a incidentes. OWASP estima que las vulnerabilidades BOLA aparecen en el 40-50% de las APIs probadas, convirtiéndola en el problema de seguridad API más prevalente.

El escaneo de seguridad regular con herramientas como middleBrick puede ayudar a identificar vulnerabilidades BOLA antes de que lo hagan los atacantes. El enfoque sistemático del escáner prueba la autorización de objetos en todos los endpoints, proporcionando a los desarrolladores hallazgos específicos y orientación de remediación para solucionar estas vulnerabilidades críticas.