Serie de OWASP Top 10 API: Coders Conquer Security - Falta de recursos y limitación de tasa

Debido a la falta de recursos y de limitación de tasa, la vulnerabilidad de la API actúa exactamente como indica su nombre. Cada API dispone de recursos y potencia de procesamiento limitados según su entorno. La mayoría también debe atender solicitudes de usuarios u otros programas que requieren que realice su función. Esta vulnerabilidad ocurre cuando se reciben demasiadas solicitudes al mismo tiempo y la API no cuenta con suficientes recursos informáticos para procesarlas. Como resultado, la API puede quedar fuera de servicio o dejar de responder a nuevas solicitudes.

Las API se vuelven vulnerables a este problema si sus límites de tasa o de recursos no están configurados correctamente, o si se dejan indefinidos en el código. Una API puede sobrecargarse si, por ejemplo, una empresa atraviesa un periodo de mucha actividad. Pero también es una vulnerabilidad de seguridad, ya que los atacantes pueden sobrecargar intencionadamente las API desprotegidas con solicitudes para llevar a cabo ataques de denegación de servicio (DDoS).

Por cierto, ¿cómo vas con los desafíos gamificados de API hasta ahora? Si quieres poner a prueba tus habilidades para gestionar una vulnerabilidad de limitación de tasa ahora mismo, entra en la arena:

Ahora, profundicemos un poco más.

¿Cuáles son algunos ejemplos de la vulnerabilidad de API por falta de recursos y limitación de tasa?

Existen dos formas en las que esta vulnerabilidad puede infiltrarse en una API. La primera es cuando el programador simplemente no define cuáles deberían ser las tasas de limitación (throttle rates) para la API. Puede que exista una configuración predeterminada en la infraestructura, pero confiar en ella no es una buena política. En su lugar, cada API debe tener sus tasas configuradas individualmente. Esto es especialmente importante porque las API pueden tener funciones muy distintas, así como diferentes recursos disponibles.

Por ejemplo, una API interna diseñada para servir a unos pocos usuarios podría tener una tasa de limitación muy baja y funcionar perfectamente. Pero una API pública que forma parte de un sitio de comercio electrónico en vivo probablemente necesitaría una tasa excepcionalmente alta para compensar la posibilidad de un aumento repentino de usuarios simultáneos. En ambos casos, las tasas de limitación deben definirse en función de las necesidades esperadas, el número de usuarios potenciales y la potencia de procesamiento disponible.

Puede resultar tentador, especialmente con API que probablemente tengan mucha actividad, establecer las tasas como ilimitadas para intentar maximizar el rendimiento. Esto podría lograrse con un poco de código (como ejemplo, usaremos el framework Django REST de Python):

"DEFAULT_THROTTLE_RATES: {
       "anon: None,
       "user: None

En ese ejemplo, tanto los usuarios anónimos como los conocidos por el sistema pueden contactar a la API un número ilimitado de veces, sin importar la cantidad de solicitudes a lo largo del tiempo. Esto es una mala idea porque, sin importar cuántos recursos informáticos tenga una API, los atacantes pueden desplegar redes de bots para ralentizarla hasta dejarla inoperativa o incluso desconectarla por completo. Cuando eso sucede, se deniega el acceso a los usuarios legítimos y el ataque tiene éxito.

Eliminación de los problemas de falta de recursos y limitación de tasa

Toda API desplegada por una organización debe tener sus tasas de limitación definidas en su código. Esto puede incluir elementos como tiempos de espera de ejecución, memoria máxima permitida, número de registros por página que se pueden devolver a un usuario o número de procesos permitidos dentro de un marco de tiempo definido.

En el ejemplo anterior, en lugar de dejar las tasas de limitación totalmente abiertas, podrían definirse estrictamente con tasas diferentes para usuarios anónimos y conocidos.

"DEFAULT_THROTTLE_RATES: {
       "anon: config("THROTTLE_ANON, default=200/hour),
       "user: config("THROTTLE_USER, default=5000/hour)

En el nuevo ejemplo, la API limitaría a los usuarios anónimos a realizar 200 solicitudes por hora. A los usuarios conocidos, ya validados por el sistema, se les da más margen con 5000 solicitudes por hora. Pero incluso ellos están limitados para evitar una sobrecarga accidental en momentos de máxima demanda o para compensar si una cuenta de usuario es comprometida y utilizada para un ataque de denegación de servicio.

Como última buena práctica a considerar, es recomendable mostrar una notificación a los usuarios cuando hayan alcanzado los límites de tasa, junto con una explicación de cuándo se restablecerán dichos límites. De esta manera, los usuarios legítimos sabrán por qué una aplicación está rechazando sus solicitudes. Esto también puede ser útil si se deniega el acceso a usuarios legítimos que realizan tareas aprobadas, ya que puede indicar al personal de operaciones que es necesario aumentar los límites.

Consulte las páginas del blog de Secure Code Warrior para obtener más información sobre esta vulnerabilidad y cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede probar una demostración de la plataforma de formación de Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.