BOLA y BFLA, autorización en una API

En el Top 10 de APIs de OWASP, BOLA (API1) es la autorización a nivel de objeto rota: el servidor no comprueba que el objeto pedido, identificado por un número o un texto en la ruta, en un parámetro o en el cuerpo, pertenezca a quien lo pide. BFLA (API5) es la autorización a nivel de función rota: el servidor no comprueba que el rol de quien llama pueda ejecutar esa operación, por ejemplo una función administrativa que acepta a un cliente normal.

La pregunta que los separa es sobre qué falla la comprobación. Si el problema es de quién es el dato, es de objeto. Si el problema es de quién puede usar la operación, es de función.

Es habitual que el desarrollador proteja la operación principal y olvide las que cuelgan de ella: la factura, el historial, las notas del envío. El patrón se ve en el registro: la operación hermana responde 403 y la que cuelga de la misma ruta responde 200.

Abre registro_de_pruebas y busca una operación que haya devuelto 200 a una cuenta de cliente sobre un envío de otro cliente, en la misma ruta que otra operación sí bloqueó.

El mismo registro tiene una petición de una cuenta de cliente a una operación de gestión de repartidores. La prueba válida no es sobre el objeto: es sobre el rol. Compara cuentas_de_prueba con el registro y busca la operación que el rol cliente no debería poder ejecutar y que respondió 200.

La corrección de BOLA es comprobar, en el servidor y en cada operación, que el objeto pedido pertenece a quien lo pide o que su rol permite verlo. Usar identificadores aleatorios y largos en lugar de números secuenciales dificulta recorrerlos, pero no sustituye la comprobación: si alguien obtiene un identificador válido, el servidor lo sirve igual. OWASP recomienda ambas cosas, la comprobación y los identificadores impredecibles, y una prueba automática de autorización antes de cada despliegue. La corrección de BFLA es otra: una comprobación de rol por operación, preferiblemente central y con denegación por defecto.

El hallazgo se documenta con lo mínimo que lo demuestra: la cuenta que hizo la petición, la operación y la ruta, el objeto pedido y su dueño, el código de respuesta, la fecha y la hora, y qué se esperaba. Se hace con las cuentas de prueba, sobre una muestra pequeña y sin recorrer series de identificadores; los datos que aparezcan se tapan o se sustituyen en el informe. Nunca se incluyen datos reales de terceros, y si un dato real apareciera, se notifica al contacto del cliente y se deja de probar esa operación.