3,2,1 … Empezamos!

Nueva entrada en el blog continuando la entrada anterior, dónde se explicaba la vulnerabilidad API3:2023 – Broken Object Property Level Authorization.

Se recomienda leer estos artículos antes de continuar con la lectura:

• API REST desde 0
• API1:2023 Broken Object Level Authorization
• API2:2023 Broken Authentication
• API3:2023 Broken Object Property Level Authorization

Tanto esta, como las siguientes publicaciones van a tratar en detalle cada vulnerabilidad que compone el TOP 10 – API 2023.

¡Espero que os resulte útil!

API4:2023 – Unrestricted Resource Consumption

Descripción

La vulnerabilidad API4:2023 – Unrestricted Resource Consumption representa una evolución de la antigua API4:2019 – Lack of Resources & Rate Limiting. Esta actualización refleja cómo ha cambiado el panorama de amenazas en los últimos años, ampliando el foco más allá del control de velocidad y los límites de uso tradicionales.

A diferencia de su predecesora, esta actualización contempla, no solo los recursos de la API, sino también aquellos del sistema subyacente (como CPU, memoria o almacenamiento) y de los proveedores de servicios externos integrados en la arquitectura. Además, introduce un nuevo concepto clave: el límite de gasto en servicios de terceros, que representa un riesgo financiero real si no se controla adecuadamente.

En términos prácticos, esta vulnerabilidad aparece cuando una API carece de mecanismos efectivos para limitar el consumo de recursos, exponiéndose así a:

• Ataques de denegación de servicio (DoS) mediante solicitudes concurrentes maliciosas o abusivas.
• Cargas operativas excesivas que perjudican el rendimiento general del sistema.
• Incremento no controlado de costes derivados de servicios externos.

La explotación de esta vulnerabilidad suele ser sencilla: puede bastar con ejecutar múltiples llamadas API, ya sea desde un único equipo o distribuidas a través de múltiples equipos. Existen herramientas automatizadas que facilitan ataques de DoS a través de grandes volúmenes de tráfico concurrente, colapsando los servicios expuestos.

Una API puede considerarse vulnerable si no impone restricciones adecuadas en, al menos, uno de los siguientes aspectos:

• Tiempo máximo de ejecución por solicitud
• Límite de memoria asignada por petición
• Número máximo de descriptores de archivo abiertos
• Número de procesos simultáneos permitidos
• Tamaño máximo de archivos cargados
• Número de operaciones encadenadas en una sola solicitud (por ejemplo, GraphQL batching)
• Número máximo de resultados por página en respuestas paginadas
• Coste asociado al uso de servicios externos (spending limit)

Como la mejor forma de entender las cosas es con ejemplos, vamos a ver esta vulnerabilidad con una situación que se puede dar:

En este caso, el contexto se centra en una subida de ficheros en una web. Ana quiere subir un fichero llamada «foto01.jpg» de 100MB de tamaño. Procede a subirlo y la API le devuelve el mensaje: «Archivo subido correctamente». Ana continua subiendo ficheros de 100MB hasta que, cuando va subir el fichero «foto33.jpg», la API le devuelve en mensaje «503 Service Unavailable».

¿Qué ha sucedido? Que la web se ha quedado sin espacio de almacenamiento, es decir, por la ausencia de un control de subida de ficheros, se ha generado una denegación de servicio, quedando el servidor inaccesible.

Una correcta implementación de la subida de ficheros a través de la API sería el siguiente caso:

Ana quiere subir el fichero «foto01.jpg» de 100MB de tamaño, cuando lo intenta subir, la API comprueba el tamaño del fichero y le indica que el fichero es demasiado grande. Ana procede a subir el resto de ficheros, esta vez con un tamaño de 10MB y la API lo procesa correctamente.

Cuando Ana intenta subir el fichero llamado «foto33.jpg», es decir, tras subir 32 ficheros anteriormente, la API le indica que la cuota destinada a su usuario ha llegado al máximo, impidiendo superar la cuota de espacio asignada para su usuario.

Impacto

El consumo de recursos sin restricciones puede tener consecuencias críticas para cualquier organización que exponga APIs públicas o internas:

• Denegación de servicio (DoS): Un atacante puede agotar recursos como CPU, RAM, disco o conexiones, dejando la API (o incluso todo el sistema) fuera de servicio.
• Afectación en el rendimiento: Aunque no se llegue a un DoS total, el abuso del servicio puede ralentizar respuestas y afectar negativamente la experiencia de usuario.
• Sobrecoste económico: Cuando se integran servicios de terceros con modelos de pago por uso, como almacenamiento en la nube, servicios de IA o mensajería, un atacante puede provocar facturación excesiva mediante peticiones maliciosas.
• Riesgos colaterales: En entornos compartidos o multiusuario, el uso abusivo de una API puede afectar a otros servicios o clientes alojados en la misma infraestructura.

Recomendaciones

Para mitigar este riesgo, es importante implementar una combinación de mecanismos técnicos y de diseño:

• Establecer límites de uso (rate limiting y throttling):
  • Definir cuántas peticiones puede hacer un cliente por minuto, segundo o día.
  • Utilizar estrategias como token bucket, leaky bucket o fixed window para adaptarlo al tipo de API.

• Restringir el consumo de recursos por petición:
  • Limitar el tamaño máximo de archivos subidos.
  • Controlar el número de registros devueltos por respuesta.
  • Evitar operaciones excesivas por solicitud (por ejemplo, batching masivo en GraphQL o endpoints que realicen múltiples operaciones internas).

• Imponer límites a nivel de sistema:
  • Establecer restricciones por usuario o servicio para memoria, CPU, número de procesos e hilos.
  • Configurar timeouts en el backend para evitar que una solicitud bloquee recursos indefinidamente, generando una denegación de servicio.

• Control de costes en servicios externos:
  • Establecer límites financieros en APIs que interactúan con terceros.
  • Monitorizar el uso con alertas automáticas ante consumos inusuales.

• Autenticación y seguimiento:
  • Obligar a que cada petición venga firmada o autenticada para poder aplicar políticas de control diferenciadas por usuario, rol o aplicación.
  • Registrar y analizar patrones de uso para detectar comportamientos anómalos o abusivos.

• Pruebas específicas en desarrollo y pentesting:
  • Incluir pruebas de consumo de recursos en las fases de QA y test de seguridad.
  • Utilizar herramientas como k6, Locust o OWASP Zap Scripts para simular escenarios de abuso.

Referencias

• https://owasp.org/API-Security/editions/2023/en/0x00-header/
• https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/

En los próximos posts se continuará explicando cada uno de los puntos que quedan por detallar del TOP 10 – API 2023.

¡Nos vemos en el próximo! 😊