API REST desde 0 - API2:2023 Broken Authentication
3,2,1 … Empezamos!
Nueva entrada en el blog continuando la entrada anterior, dónde se explicaba la vulnerabilidad API1:2023 - Broken Object Level Authorization.
Se recomienda leer estos artículos antes de continuar con la lectura:
¡Espero que os resulte útil!
API2:2023 - Broken Authentication
Descripción
Broken Authentication (autenticación rota en castellano) se refiere a cualquier debilidad dentro del proceso de autenticación de la API. A menudo, estos se implementan de forma incorrecta permitiendo suplantar la identidad de otro usuario. Como se comentó en el post anterior, la autenticación consiste en proporcionar y validar la identidad (login) de un usuario de la API, ya sea una persona, un dispositivo o un sistema. Este proceso de verificación se realiza normalmente con el uso de un nombre de usuario y contraseña, token, y/o autenticación en dos pasos.
Con respecto al TOP 10 - API 2019, esta vulnerabilidad se mantiene en la misma posición cambiando el nombre de Broken User Authentication a Broken Authentication. En esta actualización de 2023, se ha decidido que el proceso de autenticación de la API se vea como un proceso global y no como algo específico que afecta al usuario.
Como la mejor forma de entender las cosas es con ejemplos, vamos a ver esta vulnerabilidad con diferentes situaciones que se pueden dar.
En la primera imagen, Bob ha introducido unas credenciales válidas en el panel de autenticación pero la plataforma tiene configurado un OTP (One-Time Password o contraseña de un sólo uso) como segundo factor de autenticación, el cual es un código que es enviado por SMS, al correo o en una aplicación de códigos, como puede ser Microsoft Authenticator o Google Authenticator entre otras.
En este caso, Bob desconoce el OTP que se genera aleatoriamente y envía a través de la petición POST /verifyOTP un código de 6 dígitos inventado pero la API le indica que ese código es erróneo con una respuesta 403 Forbidden. Vuelve a intentar otro código de forma aleatoria y la API le vuelve a responder de la misma forma. Bob decide realizar un ataque de fuerza bruta con números hasta que da con el OTP válido que le permite autenticarse en la API y esta le responde un 200 OK, dándole acceso.
En la siguiente imagen, se observa la casuística anterior, Bob tiene acceso a unas credenciales válidas pero no dispone del OTP. Tras realizar dos intentos fallidos, al tercer intento de autenticación erróneo, la API le devuelve un mensaje “El OTP es incorrecto, quedan 2 intentos”.
Esta es una de las múltiples maneras de securizar la autenticación a una API, implementando un mecanismo contra la fuerza bruta de tal forma que si, en este caso, introduce en 5 ocasiones de forma errónea el OTP, el usuario y/o IP quedarían bloqueados por seguridad por un tiempo determinado.
En este tercer caso, el usuario va interactuar contra la funcionalidad “recovery password”. Como se puede observar en la imagen, Bob intenta descubrir usuarios válidos realizando diferentes peticiones POST contra /recoverypassword. En todas ellas, la API le devuelve un 200 OK debido a que la petición se ha realizado correctamente y el resultado es que “El usuario no existe”.
De nuevo, vuelve a realizar un ataque de fuerza bruta para descubrir usuarios válidos en el aplicativo. La API, al no tener implementado ninguna medida de seguridad contra este tipo de ataques, devuelve siempre el mismo mensaje hasta que encuentra un usuario válido y, en este caso, hace un envío de correo de recuperación de contraseña a la cuenta válida.
Como medida mitigadora al ejemplo anterior, se recomienda que en todos los casos se le devuelva al atacante un mensaje genérico 200 OK Correo enviado, de tal forma, que el atacante no sabe si ese usuario existe o no y el correo sólo es enviado en caso de existir el usuario.
Los anteriores ataques descritos son algunos de los múltiples ataques que se pueden realizar.
Impacto
Los atacantes pueden obtener el control parcial o total de las cuentas de otros usuarios en el sistema (de forma temporal o permanente), leer sus datos personales y realizar acciones sensibles en su nombre.
Es poco probable que los sistemas puedan distinguir las acciones de los atacantes de las de los usuarios legítimos.
Recomendaciones
- Implementar la autenticación en dos pasos.
- Conocer todas las opciones de autenticación que dispone la API.
- Implementar mecanismos contra la fuerza bruta con una integración la respuesta del captcha en la petición de la API para mitigar el relleno de credenciales, los ataques de diccionario y los ataques de fuerza bruta en el login o en la recuperación de usuario/contraseñas, entre otros. Bloqueo de IP por exceso de peticiones.
- Generar tokens o almacenamiento de contraseñas para realizar el proceso de autenticación. Emplear los estándares definidos.
- Implementar comprobaciones de contraseñas débiles.
- Las claves de la API no deben utilizarse para la autenticación de usuarios, sino para la autenticación de aplicaciones/proyectos de clientes.
Referencias
- https://owasp.org/API-Security/editions/2023/en/0x00-header/
- https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/
- https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
- https://www.apisecuniversity.com/
En los próximos posts se continuará explicando cada uno de los puntos que quedan por detallar del TOP 10 - API 2023.
¡Nos vemos en el próximo! 😊
