Las fallas de autorización suelen ser el resultado de una autorización implementada incorrectamente o mal configurada. Implementar mecanismos de autorización adecuados es una tarea compleja, ya que las aplicaciones modernas pueden contener muchos tipos de roles, grupos y jerarquías de usuarios, como subusuarios y usuarios con más de un rol. Esto se complica aún más con las arquitecturas de aplicaciones distribuidas y el diseño nativo de la nube. La autorización a nivel de función rota (BFLA) comparte algunas similitudes con la autorización a nivel de objeto rota (BOLA) en este sentido.
Los atacantes pueden descubrir estas fallas en las API porque las llamadas a la API son estructuradas y predecibles, incluso en diseños REST. Esto se puede hacer en ausencia de documentación de API o definiciones de esquema mediante ingeniería inversa del código del lado del cliente e interceptando el tráfico de la aplicación. Algunos puntos finales de API también podrían estar expuestos a usuarios regulares y no privilegiados, lo que facilita su descubrimiento por parte de los atacantes.
Estas fallas pueden ser explotadas enviando solicitudes de API legítimas a un punto final de API al que los atacantes no deberían tener acceso o interceptando y manipulando solicitudes de API originadas en aplicaciones cliente. Por ejemplo, un atacante podría cambiar un método HTTP de GET a PUT. Alternativamente, el atacante también podría alterar un parámetro de consulta o una variable del cuerpo del mensaje, como cambiar la cadena "users" a "admins" en una solicitud de API.
¿Cuál es la diferencia entre BOLA y BFLA?
La autorización a nivel de función rota (BFLA) puede considerarse una versión de nivel superior de la autorización a nivel de objeto rota (BOLA). La principal diferencia es que, al explotar una vulnerabilidad BFLA, un atacante se centra en funciones generales de la API en lugar de objetos individuales de la API. La consecuencia de BFLA es que los clientes pueden acceder a funcionalidades más allá de su nivel de acceso previsto, como funciones administrativas.
Los atacantes intentarán explotar ambas vulnerabilidades al atacar API para escalar privilegios horizontal o verticalmente.
Impacto Potencial de un Ataque de Autorización a Nivel de Función Rota
La autorización a nivel de función rota (BFLA) ha sido identificada como la quinta amenaza más crítica para las API en el Top 10 de Seguridad de API de OWASP, y con razón. De hecho, los atacantes que explotan vulnerabilidades de autorización a nivel de función rota pueden obtener acceso a recursos no autorizados, tomar el control de la cuenta de otro usuario, crear/eliminar cuentas o escalar privilegios para obtener acceso administrativo.
Descargue hoy el eBook del Top 10 de Seguridad de API de OWASP
¿Cómo es un ataque BFLA?
Ejemplo del Mundo Real: New Relic Synthetics
En 2018, el investigador de ciberseguridad Jon Bottarini descubrió que un usuario restringido podía realizar cambios en las alertas de New Relic Synthetics monitores sin los permisos adecuados para hacerlo. De hecho, podían realizar cambios sin ningún permiso debido a la debilidad de escalada de privilegios presente en el producto en ese momento. La explotación implicó enviar una solicitud legítima a un endpoint de API que, de otro modo, no era visible para el usuario restringido.
Como parte de su investigación de seguridad, Bottarini capturó el tráfico de una sesión privilegiada utilizando una herramienta de proxy de intercepción, Portswigger Burp Suite. Este tráfico incluía una solicitud POST a un endpoint de API y una función que crea alertas en los monitores de Synthetics. Descubrió que se podía interceptar una solicitud GET de la sesión no privilegiada, retener los tokens y las cookies de ese usuario restringido, y modificar el resto de la solicitud interceptada para que se pareciera a la solicitud POST privilegiada. Esta manipulación del tráfico de la API para acceder a funcionalidades no visibles en la interfaz de usuario (en absoluto o para ese usuario y sus permisos) es una técnica común que los atacantes utilizan para explotar las debilidades de autorización a nivel de función y escalar privilegios.
¿Por qué las herramientas existentes no protegen sus API contra BFLA?
Los controles de seguridad tradicionales como los WAF y las pasarelas de API carecen del contexto de la actividad de la API y, por lo tanto, no saben que el atacante del primer ejemplo no debería poder enviar un método DELETE. Esta llamada a la API se consideraría legítima y pasaría por estos controles de seguridad.
Los WAF y las pasarelas de API a veces admiten filtros de mensajes explícitos y definidos estáticamente, a menudo denominados enfoque de seguridad positivo. Sin embargo, estos enfoques pueden inhibir o romper la funcionalidad empresarial, y la mayoría de las organizaciones encuentran difícil ponerlos en práctica a escala. Restringir los métodos HTTP también es una tarea más fácil que restringir los parámetros y valores de la API, ya que esto último requiere una experiencia más profunda en el diseño de la API.
La actividad del ejemplo de New Relic anterior sería pasada por alto por los WAF y las pasarelas de API por la misma razón. Estos controles de seguridad no sabrían que las aplicaciones de terceros ya no deberían tener acceso a las funciones de API obsoletas o restringidas. Ajustar los controles habría requerido una transferencia de conocimientos adecuada entre los equipos de desarrollo, operaciones y seguridad para implementar un filtro estático apropiado en el proxy correspondiente dentro de la arquitectura empresarial general.
Cómo proteger sus API de las vulnerabilidades de autorización a nivel de función
Las soluciones de seguridad de API deben ser capaces de establecer continuamente una línea base de los patrones de acceso HTTP típicos por endpoint de API y por usuario. Con esta línea base, las soluciones de seguridad de API pueden identificar llamadas con parámetros inesperados o métodos HTTP enviados a endpoints de API específicos, como en el primer ejemplo.
Es fundamental que una herramienta de seguridad de API sea capaz de establecer una línea base de forma continua, ya que las API pueden experimentar una alta tasa de cambios como resultado de las prácticas modernas de desarrollo y lanzamiento. Las soluciones de seguridad de API deben ser capaces de identificar y evitar que atacantes o usuarios no autorizados accedan a capacidades de nivel administrativo o a funcionalidades no autorizadas.
Para obtener más información sobre cómo Salt puede ayudar a defender su organización de los riesgos de las API, puede contactar con un representante o programar una demostración personalizada.