La categoría de Autorización a nivel de propiedad de objeto rota combina ataques que ocurren al obtener acceso no autorizado a información confidencial mediante Exposición excesiva de datos (anteriormente listada como número 3 en el Top 10 de seguridad de API de OWASP de 2019) o Asignación masiva (anteriormente en sexto lugar).
Ambas técnicas se basan en la manipulación de puntos finales de API para obtener acceso a datos confidenciales.
Esta nueva categoría trata sobre la autorización a nivel de propiedades de objeto, a diferencia de la autorización a nivel de objeto (número 1 en la lista desde 2019).
La razón principal para introducir esta nueva amenaza en la lista es que, incluso si una API puede aplicar medidas de seguridad de autorización a nivel de objeto suficientes, esto podría no ser suficiente para protegerla. A menudo se requiere una autorización más específica que cubra los objetos y sus características. También se deben tener en cuenta los distintos niveles de acceso dentro de un objeto de API, ya que un objeto de API a menudo tiene tanto una propiedad pública como una privada.
Impacto potencial de la autorización a nivel de propiedad de objeto rota
Las API a menudo envían más información de la necesaria en una respuesta de API y dejan que la aplicación cliente filtre los datos y renderice una vista para el usuario. Un atacante puede interceptar el tráfico enviado al cliente para obtener acceso a datos potencialmente confidenciales que pueden incluir información como números de cuenta, direcciones de correo electrónico, números de teléfono y tokens de acceso.
Además, un atacante que explote este tipo de vulnerabilidad puede actualizar propiedades de objetos a las que no debería tener acceso, lo que le permite escalar privilegios, manipular datos y eludir los mecanismos de seguridad.
¿Cómo es un ataque de autorización a nivel de propiedad de objeto rota?
En el ejemplo anterior, el código del lado del cliente que se ejecuta en el navegador web del usuario envía una solicitud POST a una API de backend para recuperar información de pago almacenada. En este caso, la API está recuperando información de tarjeta de crédito almacenada, específicamente el número de cuenta principal (PAN) y el código de valor de verificación de tarjeta (CVV). Dentro del mundo del manejo de tarjetas de crédito y el procesamiento de pagos, este tipo de datos se considera confidencial como parte de PCI-DSS y debe protegerse adecuadamente. El alcance de lo que es necesario para la protección varía según la exposición del entorno de datos del titular de la tarjeta, o dónde se almacenan, procesan o transmiten los datos.
Este intercambio de datos confidenciales puede ser intencional como parte del diseño o necesario para la funcionalidad. Como resultado, las organizaciones aumentan la seguridad con controles adicionales, como una autenticación más sólida o transporte cifrado, para garantizar que los datos estén suficientemente protegidos. En el ejemplo, puede ver encabezados de seguridad HTTP adicionales para ayudar a proteger los datos, como x-frame-options para mitigar ataques de cross-frame scripting y x-xss-protection para mitigar ataques de cross-site scripting. Algunas organizaciones también pueden enmascarar los datos que se devuelven a un cliente para evitar casos en los que alguien intercepte el tráfico o vea datos fuera de la aplicación cliente prevista. Confiar en el código del lado del cliente para filtrar u ocultar dichos datos confidenciales generalmente no es apropiado, ya que los atacantes suelen eludir el código de la aplicación web y móvil del lado del cliente y llamar a las API directamente.
En el segundo ejemplo anterior, el atacante ha cambiado la llamada a la API para actualizar su cuenta, escalar su rol y privilegios a un rol de "administrador" y eludir el inicio de sesión único (SSO). Si tiene éxito, el atacante puede realizar acciones dentro de la aplicación como administrador.
Ejemplo del mundo real: los usuarios de Twitter ven sus datos comprometidos
Según un declaración publicada por Twitter en agosto de 2022, una vulnerabilidad de autorización de nivel de propiedad de objeto rota fue detectada inicialmente por su programa de recompensas por errores en enero de 2022. Como resultado de este fallo, si alguien enviaba una dirección de correo electrónico o un número de teléfono a los sistemas de Twitter, se le informaba con qué cuenta de Twitter estaba asociada dicha información, si es que existía alguna. El problema fue investigado y solucionado por Twitter en ese momento, sin evidencia que sugiriera que hubiera sido explotado en el mundo real. Sin embargo, en julio de 2022, salió a la luz que un actor malintencionado se había aprovechado del problema antes de que la empresa lo solucionara y ahora estaba ofreciendo vender los datos que recopiló.
Este incidente tan público puso de manifiesto el riesgo que puede suponer este tipo de vulnerabilidad de seguridad, incluso para una marca bien establecida con vastos recursos y programas de seguridad supuestamente sólidos.
Por qué las herramientas existentes no logran protegerle contra las vulnerabilidades de autorización de nivel de propiedad de objeto
Los controles de seguridad tradicionales como los WAF y las puertas de enlace de API no tienen contexto sobre la actividad de la API ni sobre la lógica empresarial y, por lo tanto, no logran identificar los datos confidenciales que se envían a través de una API ni comprender el riesgo de exposición de dichos datos. Tampoco pueden saber si el emisor de la llamada a la API en el ejemplo anterior debería poder enviar una solicitud utilizando el método PUT con parámetros adicionales, fallando al diferenciar entre una llamada legítima y una actividad maliciosa. Para estos controles tradicionales, esta llamada a la API parece normal. En el mejor de los casos, un WAF o una puerta de enlace de API pueden ofrecer mecanismos básicos de filtrado de mensajes para bloquear este tipo de solicitud por completo. Sin embargo, es posible que se necesiten parámetros adicionales para otros usuarios y otros casos de uso. También requeriría un conocimiento detallado previo por parte de los equipos de desarrollo sobre el diseño y el uso previsto de la API para que los equipos operativos puedan implementar incluso filtros de mensajes básicos.
Normalmente, las puertas de enlace de API y los WAF emplean coincidencia de patrones básica y filtrado de mensajes para identificar tipos de datos confidenciales, también conocidos como patrones de expresiones regulares (regex). Si bien estos tipos de filtros pueden detectar tipos de datos confidenciales bien definidos, como números de tarjetas de pago (PAN) o números de seguridad social (SSN), no comprenden el contexto de la API ni los flujos de lógica empresarial. Marcarán cualquier dato que coincida con el patrón, independientemente de si es necesario bloquear la solicitud, cifrar las cargas útiles u ocultar los datos. Las puertas de enlace de API se utilizan a menudo para mediar en llamadas a la API que contienen datos confidenciales, y esto puede ser necesario como parte de una arquitectura empresarial, un diseño de aplicación o una integración de sistemas generales. Bloquear o enmascarar datos confidenciales por completo a menudo interrumpe la funcionalidad, lo que hace que los equipos de seguridad se muestren reacios a utilizar estas capacidades de forma agresiva en los proxies, prefiriendo confiar en la capa de API/aplicación para controlar la exposición.
Cómo proteger sus API contra la vulnerabilidad de autorización de nivel de propiedad de objeto
Una solución de seguridad de API debe ser capaz de identificar e informar sobre la gran variedad de tipos de datos confidenciales que pueden enviarse en las solicitudes y respuestas de la API, así como sobre cualquier actividad anómala en la que los atacantes envíen solicitudes de API manipuladas con parámetros no autorizados.
Estas soluciones también deben ser capaces de establecer una línea base y realizar un seguimiento del acceso a la API por punto final y por usuario para identificar el consumo excesivo de datos confidenciales y detectar aquellos casos en los que se pasan parámetros adicionales en las llamadas a la API que quedan fuera del comportamiento típico. Las soluciones de seguridad de API también deberían ser capaces de identificar a los atacantes mientras sondean la API durante su fase de reconocimiento para comprender la estructura y la lógica empresarial de la misma.
Para obtener más información sobre cómo Salt puede ayudar a defender a su organización de los riesgos de las API, puede contactar con un representante o programar una demostración personalizada.