Los programadores conquistan la seguridad Serie API Top 10 de OWASP: falta de recursos y limitación de tasas

Con la falta de recursos y la limitación de la tasa, la vulnerabilidad de la API actúa casi exactamente como se describe en el título. Cada API tiene recursos y potencia de cálculo limitados a su disposición, dependiendo de su entorno. Además, la mayoría tiene que atender las peticiones de los usuarios u otros programas que le piden que realice su función deseada. Esta vulnerabilidad se produce cuando llegan demasiadas peticiones al mismo tiempo y la API no tiene suficientes recursos informáticos para atenderlas. La API puede entonces dejar de estar disponible o no responder a nuevas peticiones.

Las APIs se vuelven vulnerables a este problema si sus límites de velocidad o recursos no se establecen correctamente, o si los límites se dejan sin definir en el código. Una API puede entonces sobrecargarse si, por ejemplo, una empresa experimenta un periodo de especial actividad. Pero también es una vulnerabilidad de seguridad, porque los actores de amenazas pueden sobrecargar a propósito las APIs desprotegidas con peticiones 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 en el manejo de una vulnerabilidad que limita la velocidad ahora mismo, entra en la arena:

Ahora, profundicemos un poco más.

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

Hay dos maneras en que esta vulnerabilidad puede colarse en una API. La primera es cuando un codificador simplemente no define cuáles deben ser las tasas de aceleración para una API. Puede haber una configuración por defecto para las tasas de aceleración en algún lugar de la infraestructura, pero confiar en eso no es una buena política. En su lugar, cada API debería tener sus tasas establecidas individualmente. Esto es especialmente cierto porque las APIs pueden tener funciones muy diferentes así como recursos disponibles.

Por ejemplo, una API interna diseñada para servir a unos pocos usuarios podría tener una tasa de aceleración muy baja y funcionar bien. Pero una API de cara al público que forme parte de un sitio de comercio electrónico en vivo probablemente necesitaría una tasa excepcionalmente alta definida para compensar la posibilidad de un aumento de usuarios simultáneos. En ambos casos, las tasas de estrangulamiento deben definirse en función de las necesidades previstas, el número de usuarios potenciales y la potencia de cálculo disponible.

Puede ser tentador, especialmente con las APIs que probablemente estarán muy ocupadas, establecer las tasas como ilimitadas para tratar de maximizar el rendimiento. Esto podría lograrse con un simple trozo de código (como ejemplo, utilizaremos 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 ponerse en contacto con la API un número ilimitado de veces sin tener en cuenta el número de solicitudes a lo largo del tiempo. Esto es una mala idea porque no importa cuántos recursos informáticos tenga disponible una API, los atacantes pueden desplegar cosas como botnets para eventualmente ralentizarla o posiblemente dejarla fuera de servicio por completo. Cuando esto ocurra, se negará el acceso a los usuarios válidos y el ataque tendrá éxito.

Eliminación de la falta de recursos y de los problemas de limitación de velocidad

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

A partir del ejemplo anterior, en lugar de dejar las tasas de estrangulamiento totalmente abiertas, podrían definirse estrictamente con tasas diferentes para los usuarios anónimos y los 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. Los usuarios conocidos que ya han sido investigados por el sistema tienen más margen de maniobra, con 5.000 solicitudes por hora. Pero incluso ellos están limitados para evitar una sobrecarga accidental en las horas punta o para compensar si una cuenta de usuario está 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 estrangulamiento junto con una explicación de cuándo se restablecerán dichos límites. De esta manera, los usuarios válidos sabrán por qué una aplicación está rechazando sus solicitudes. Esto también puede ser ú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 el estrangulamiento.

Consulte las páginas del Secure Code Warrior páginas del 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 otros fallos de seguridad. También puede probar una demostración de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.