La vulnerabilidad de Consumo de Recursos sin Restricciones ha reemplazado a la Falta de Recursos y Limitación de Tasa en el Top 10 de Seguridad de API de OWASP, pero, aunque el nombre cambió, la vulnerabilidad sigue siendo la misma en esencia.
Las solicitudes de API consumen recursos como red, CPU, memoria y almacenamiento. La cantidad de recursos necesarios para satisfacer una solicitud depende en gran medida de la entrada del usuario y de la lógica de negocio del endpoint.
Las API no siempre imponen restricciones sobre el tamaño o la cantidad de recursos que puede solicitar el cliente o usuario, lo que crea vulnerabilidades de seguridad que no solo pueden afectar el rendimiento del servidor de API, provocando una Denegación de Servicio (DoS), sino que también dejan la puerta abierta a ataques de fuerza bruta y enumeración contra API que proporcionan funciones de autenticación y obtención de datos. Esto incluye amenazas automatizadas como el descifrado de credenciales y de tokens, entre otras.
Impacto potencial del consumo de recursos sin restricciones
Al determinar el impacto potencial del Consumo de Recursos sin Restricciones —el número cuatro en el Top 10 de Seguridad de API de OWASP —, lo mejor es desglosar el impacto de este problema en dos subcomponentes:
- Con respecto a la falta de limitación de recursos, un atacante puede diseñar una única llamada a la API capaz de abrumar una aplicación, afectando su rendimiento y capacidad de respuesta o provocando que deje de responder. Este tipo de ataque a veces se denomina DoS a nivel de aplicación. Sin embargo, estos ataques no solo afectan la disponibilidad; también pueden exponer el sistema, la aplicación o la API a ataques de autenticación y a una filtración excesiva de datos.
- Con respecto a la falta de limitación de tasa, un atacante puede diseñar y enviar grandes volúmenes de solicitudes de API para abrumar los recursos del sistema, realizar ataques de fuerza bruta a las credenciales de inicio de sesión, enumerar rápidamente grandes conjuntos de datos o exfiltrar grandes cantidades de información.
¿Cómo se manifiesta el consumo de recursos sin restricciones?
En el ejemplo anterior de falta de límite de recursos, el atacante ha aumentado los valores de max_return y page_size para el filtro de búsqueda de 250 a 20,000. Este aumento provocaría que la aplicación devolviera un número excesivo de elementos en respuesta a una consulta. También podría causar que la aplicación se ralentice o deje de responder para todos los usuarios.
Ejemplo real: el ataque DDoS al portal tributario de Polonia
Un ejemplo muy conocido de este tipo de ataque son los ataques distribuidos de denegación de servicio (DDoS) dirigidos a API. Un ejemplo reciente muestra cómo el portal tributario principal de Polonia quedó inaccesible para los ciudadanos polacos debido a un ataque de esta categoría, donde los hackers pudieron explotar los recursos que soportan las API detrás del servicio tributario central y dejarlo fuera de servicio durante varias horas.
Con los funcionarios del gobierno polaco señalando rápidamente a los hackers rusos, a la luz de la guerra en Ucrania, este ataque demuestra cómo el panorama social y político actual hace que la ciberseguridad, y la seguridad de las API en particular, sea aún más crucial tanto para las empresas como para las instituciones gubernamentales.
Por qué las herramientas existentes no logran protegerle contra ataques de consumo de recursos sin restricciones
Los controles de seguridad tradicionales como los WAF, las puertas de enlace de API, y otros mecanismos de proxy suelen ofrecer una limitación de tasa básica o estática que resulta difícil de aplicar a gran escala. Es posible que los equipos de seguridad no conozcan lo suficiente el diseño de la aplicación como para determinar qué es lo "normal" y así aplicar límites que frustren a los atacantes sin afectar a la funcionalidad del negocio. Los WAF y las puertas de enlace de API carecen del contexto necesario para informar a los equipos de seguridad sobre cuál debería ser un valor normal para un parámetro de API, y pasarán por alto los ataques en los que un atacante manipula el valor de un solo parámetro de API para sobrecargar la aplicación. Estos proxies también pueden cubrir solo el tráfico de entrada (ingress), en lugar del tráfico de salida (egress), es decir, las solicitudes y respuestas salientes.
Cómo proteger sus API contra amenazas de consumo ilimitado de recursos
Una solución de seguridad de API debe ser capaz de identificar las llamadas a los puntos finales de la API y las alteraciones en los valores de los parámetros de la API que se salen del uso normal. Esto se lograría analizando todo el tráfico de la API para crear una línea base del comportamiento típico e identificando las desviaciones que quedan fuera de esa línea base.
En el ejemplo anterior, una solución de seguridad de API habrá creado una línea base de valores para los parámetros max_return y page_size, e identificará que un valor de 20.000 es anormal. La solución podría entonces alertar y bloquear a un atacante que elabore solicitudes de API que se desvíen de la línea base.
Para obtener más información sobre cómo Salt puede ayudar a proteger a su organización frente a los riesgos de las API, puede contactar con un representante o programar una demostración personalizada.