IDOR y BOLA

Por Qué Importa

IDOR y BOLA representan la clase de vulnerabilidad de API con mayor impacto. Broken Object Level Authorization ha ocupado la primera posición en el OWASP API Security Top 10 desde su creación en 2019 y mantuvo esa posición en la actualización de 2023.

La razón es simple: las APIs exponen identificadores de objetos en URLs, cuerpos de solicitud y parámetros de consulta. Si el servidor no verifica que el usuario solicitante es propietario del objeto referenciado o tiene permiso para acceder a él, cualquier usuario autenticado puede acceder a los datos de cualquier otro usuario manipulando esos identificadores.

Las vulnerabilidades BOLA en el mundo real han expuesto millones de registros de usuarios en plataformas que van desde servicios financieros hasta redes sociales. La vulnerabilidad es particularmente peligrosa porque:

• No requiere herramientas ni habilidades especiales para explotar
• Una sola vulnerabilidad puede exponer los datos de todos los usuarios
• Frecuentemente elude el cifrado ya que el atacante está autenticado
• La explotación automatizada puede extraer bases de datos completas

Para los pentesters y cazadores de bug bounty, las pruebas de BOLA/IDOR son una de las primeras habilidades a dominar porque producen el mayor número de hallazgos válidos en relación al esfuerzo.

Cómo Funcionan IDOR y BOLA

El Patrón Básico

Una aplicación asigna identificadores a los objetos: perfiles de usuario, pedidos, facturas, archivos, mensajes o cualquier otro recurso. Cuando un usuario solicita un objeto, la API recibe el identificador y devuelve los datos correspondientes. La vulnerabilidad existe cuando la API verifica la autenticación (¿este usuario ha iniciado sesión?) pero omite la autorización (¿este usuario tiene permiso para acceder a este objeto específico?).

Tipos Comunes de Identificadores

• IDs numéricos secuenciales: /api/users/1001 hasta /api/users/9999. Fáciles de enumerar.
• UUIDs: /api/orders/a3f8e2c1-.... Más difíciles de adivinar pero no imposibles si se filtran en otras respuestas.
• Valores codificados: Identificadores en Base64 o hash que a veces se pueden decodificar o predecir.
• Claves compuestas: /api/org/5/user/12. Múltiples identificadores que cada uno necesita verificaciones de autorización.

Metodología de Pruebas

1. Crear dos cuentas con diferentes roles o propiedad
2. Capturar todas las solicitudes de API que contengan identificadores de objetos
3. Intercambiar identificadores entre cuentas
4. Probar todos los métodos HTTP (GET para lectura, PUT/PATCH para actualización, DELETE para eliminación)
5. Verificar tanto el código de estado de la respuesta como el cuerpo de la respuesta

Prevención

La solución requiere verificaciones de autorización del lado del servidor en cada solicitud que acceda a un recurso específico del usuario. El servidor debe verificar que el usuario autenticado tiene permiso para acceder al objeto específico referenciado en la solicitud, no solo que un token de autenticación válido está presente.

• Implementar verificaciones de permisos a nivel de objeto en el middleware de la API o en la capa de acceso a datos
• Nunca depender de la oscuridad (UUIDs) como sustituto de la autorización
• Usar referencias indirectas cuando sea posible (mapear tokens específicos de sesión a IDs reales de base de datos en el lado del servidor)
• Registrar todos los patrones de acceso y alertar sobre acceso horizontal entre los límites de usuarios