Las 10 mejores API de la serie OWASP de Coders Conquer Security: falta de recursos y limitación de velocidad

Con la falta de recursos y la limitación de velocidad, la vulnerabilidad de la API actúa casi exactamente como se describe en el título. Cada API dispone de recursos y potencia informática limitados en función de su entorno. La mayoría también deben responder a las solicitudes de los usuarios u otros programas pidiéndoles que realicen la función deseada. Esta vulnerabilidad se produce cuando se reciben demasiadas solicitudes al mismo tiempo y la API no tiene suficientes recursos informáticos para gestionar esas solicitudes. En ese caso, la API puede dejar de estar disponible o dejar de responder a las nuevas solicitudes.

Las API se vuelven vulnerables a este problema si sus límites de velocidad o recursos no se establecen correctamente, o si los límites no se definen en el código. En ese caso, una API puede sobrecargarse si, por ejemplo, una empresa pasa por un período especialmente ajetreado. Pero también es una vulnerabilidad de seguridad, ya que los atacantes pueden sobrecargar deliberadamente las API desprotegidas con solicitudes para realizar ataques de denegación de servicio (DDoS).

Por cierto, ¿cómo te va con los desafíos gamificados de la API hasta ahora? Si quieres poner a prueba tus habilidades para gestionar una vulnerabilidad que limita la velocidad ahora mismo, sal a la arena:

Ahora, profundicemos un poco más.

¿Cuáles son algunos ejemplos de la falta de recursos y la vulnerabilidad de la API que limita la velocidad?

Hay dos maneras en las que esta vulnerabilidad puede colarse en una API. La primera es cuando un programador simplemente no define cuáles deberían ser las velocidades de aceleración de una API. Es posible que haya una configuración predeterminada para las tasas de aceleración en alguna parte de la infraestructura, pero confiar en esa configuración no es una buena política. En su lugar, cada API debería tener sus tarifas establecidas de forma individual. Esto es especialmente cierto porque las API pueden tener funciones y recursos disponibles muy diferentes.

Por ejemplo, una API interna diseñada para atender solo a unos pocos usuarios podría tener una velocidad de aceleración muy baja y funcionar perfectamente. Sin embargo, una API pública que forme parte de un sitio de comercio electrónico activo probablemente necesite definir una tasa excepcionalmente alta para compensar la posibilidad de que aumente el número de usuarios simultáneos. En ambos casos, las tasas de limitación deben definirse en función de las necesidades esperadas, la cantidad de usuarios potenciales y la potencia informática disponible.

Puede resultar tentador, especialmente en el caso de las API que probablemente estén muy ocupadas, establecer las tarifas en ilimitadas para intentar maximizar el rendimiento. Esto podría lograrse con un simple fragmento de código (por ejemplo, usaremos el Marco REST Python Django):

«TARIFAS_ACELERADOR_PREDETERMINADAS: {
«Anon: Ninguna,
«usuario: Ninguno

En ese ejemplo, tanto los usuarios anónimos como los conocidos del sistema pueden contactar con la API un número ilimitado de veces sin importar la cantidad de solicitudes a lo largo del tiempo. Esta es una mala idea porque, independientemente de la cantidad de recursos informáticos de la que disponga una API, los atacantes pueden implementar sistemas como redes de bots para ralentizarla o, incluso, dejarla sin conexión por completo. Cuando eso suceda, se negará el acceso a los usuarios válidos y el ataque tendrá éxito.

Eliminar la falta de recursos y los problemas de limitación de tasas

Todas las API que implementa una organización deben tener sus tasas de aceleración definidas en su código. Esto puede incluir factores como los tiempos de espera de ejecución, la memoria máxima permitida, la cantidad de registros por página que se pueden devolver a un usuario o la cantidad de procesos permitidos dentro de un período de tiempo definido.

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

«TARIFAS_ACELERADOR_PREDETERMINADAS: {
«anon: config («THROTTLE_ANON, predeterminado = 200/hora),
«user: config («THROTTLE_USER, predeterminado = 5000/hora)

En el nuevo ejemplo, la API limitaría a los usuarios anónimos a realizar 200 solicitudes por hora. Los usuarios conocidos que ya han sido examinados por el sistema tienen más margen de maniobra: 5000 solicitudes por hora. Pero incluso se limitan a evitar una sobrecarga accidental en las horas punta o a compensar si una cuenta de usuario se ve comprometida y se utiliza para un ataque de denegación de servicio.

Como última buena práctica a tener en cuenta, es una buena idea mostrar una notificación a los usuarios cuando hayan alcanzado los límites de limitación, junto con una explicación sobre cuándo se restablecerán esos límites. De esta forma, los usuarios válidos sabrán por qué una aplicación rechaza sus solicitudes. Esto también puede resultar útil si a los usuarios válidos que realizan tareas aprobadas se les niega el acceso a una API, ya que puede indicar al personal de operaciones que es necesario aumentar la limitación.

Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.