Las API a menudo exponen puntos finales que manejan identificadores de objetos, creando una amplia superficie de ataque potencial. La autorización a nivel de objeto es un mecanismo de control de acceso generalmente implementado a nivel de código para validar la capacidad de un usuario para acceder a un objeto determinado. Los mecanismos de autorización y control de acceso en las aplicaciones modernas son complejos y están muy extendidos. Incluso si una aplicación implementa una infraestructura adecuada para las comprobaciones de autorización, los desarrolladores a menudo olvidan aplicar estas comprobaciones antes de acceder a un objeto.
Los atacantes pueden explotar fácilmente los puntos finales de API que son vulnerables a la autorización a nivel de objeto rota (BOLA) manipulando el ID de un objeto que se envía dentro de una solicitud de API. Esto se debe a que el componente del servidor generalmente no rastrea completamente el estado del cliente. En cambio, el componente del servidor generalmente se basa en parámetros como los ID de objeto enviados desde el cliente para decidir a qué objetos se puede acceder.
Las vulnerabilidades BOLA están presentes en alrededor del 40% de todos los ataques a API y se enumeran como la amenaza número uno para la seguridad de las API en el OWASP API Security Top 10. Cualquier acceso a datos no autorizados es grave, independientemente de su clasificación o sensibilidad de datos. Desafortunadamente, este tipo de fallos de autorización no son fácilmente detectables con pruebas estáticas o dinámicas automatizadas.
Cada punto final de API que recibe un ID de un objeto y realiza cualquier tipo de acción sobre el objeto debe implementar comprobaciones de autorización a nivel de objeto. Estas comprobaciones deben realizarse continuamente a lo largo de una sesión determinada para validar que el usuario que ha iniciado sesión tiene acceso para realizar la acción solicitada sobre un objeto solicitado.
¿Cuál es el impacto potencial de un ataque BOLA?
La falta de aplicación de la autorización a nivel de objeto puede llevar a la exfiltración de datos, así como a la visualización, modificación o destrucción no autorizada de datos. BOLA también puede llevar a una completa toma de control de cuenta como en los casos en que un atacante puede comprometer un flujo de restablecimiento de contraseña y restablecer las credenciales de una cuenta a la que no está autorizado.
En el ejemplo anterior, la lógica de backend de la aplicación consulta la base de datos con el userId en el parámetro de consulta mientras verifica la autorización con el userId en la cookie. En condiciones normales, estos dos valores deberían coincidir. Sin embargo, un atacante podría simplemente modificar el valor del userId en el parámetro de consulta para acceder a datos no autorizados.
Si los userIds son secuenciales, el atacante puede simplemente enumerar el valor del userId del parámetro de consulta para extraer, o exfiltrar, grandes cantidades de datos, particularmente si no se aplican límites de velocidad.
Ejemplos del mundo real de vulnerabilidades de autorización a nivel de objeto rota (BOLA)
Cómo un hacker podría haber tomado el control de tu cuenta de Uber
En 2019, un investigador de seguridad reveló una vulnerabilidad BOLA que habría permitido a un atacante tomar el control de cualquier cuenta de usuario en Uber. Al explotar la vulnerabilidad, el atacante podría acceder a la cuenta de otro usuario para rastrear la ubicación del usuario objetivo, tomar viajes y más. El atacante también podría explotar la vulnerabilidad BOLA para recolectar tokens de acceso de la aplicación móvil de Uber y luego usar esos tokens de acceso para tomar el control de las cuentas de Uber Driver y Uber Eats. El userId de la aplicación de Uber podría enumerarse fácilmente proporcionando el número de teléfono o la dirección de correo electrónico de un usuario en otra solicitud de API.
El ataque BOLA al Banco Central de Rusia
Un ejemplo destacado de un ataque BOLA exitoso ocurrió en el banco central de Rusia en 2016, donde los atacantes lograron cambiar un ID de cuenta y realizar transferencias no autorizadas a otras cuentas a través de un Sistema de Pagos Rápidos, logrando robar alrededor de 2 mil millones de rublos.
En este caso, los atacantes lograron obtener datos de cuentas de clientes aprovechando la vulnerabilidad BOLA, luego lanzaron la aplicación móvil del banco en modo de depuración, iniciaron sesión como un cliente real y transfirieron fondos a otro banco. Antes de realizar la transferencia, el atacante cambió el ID de la cuenta por el ID de otro cliente, lo que permitió que la transferencia se procesara sin la verificación de ID adecuada.
Por qué las herramientas existentes no logran protegerle contra las vulnerabilidades BOLA
Los controles de seguridad tradicionales como los WAF y las pasarelas API pasan por alto este tipo de ataques porque no comprenden el contexto de la API y no establecen una línea base del uso normal de la API.
En cuanto a las vulnerabilidades BOLA, estas herramientas no saben que el userId en el parámetro de consulta y el userId en la cookie deben coincidir. Además, dado que este no es un patrón de ataque conocido y predecible como una inyección de código donde se pueden emplear la coincidencia de patrones básica y el filtrado de mensajes, un ataque BOLA no puede ser identificado por las firmas utilizadas por un WAF o una pasarela API.
Cómo proteger las API contra ataques de autorización a nivel de objeto roto (BOLA)
Para prevenir ataques BOLA, una solución de seguridad de API debe ser capaz de aprender la lógica de negocio de una API y detectar cuándo un usuario autenticado intenta obtener acceso no autorizado a los datos de otro usuario. En efecto, la herramienta de seguridad de API necesita poder reconocer que los dos objetos deben coincidir y que el usuario autenticado está autorizado para acceder al objeto solicitado. Este tipo de detección requiere el análisis de grandes cantidades de tráfico de API para obtener contexto y comprender el comportamiento normal de cada API.
Solo una solución que proporcione una línea base de uso normal puede identificar comportamientos anómalos como un atacante manipulando el userId en un parámetro de consulta en solicitudes GET, o una variable userId dentro del cuerpo de un mensaje de solicitudes POST.
Para ver cómo la plataforma Salt puede ayudarle a prevenir ataques BOLA, solicite una demostración hoy mismo.