Puede que conozcas Cloudflare como la empresa por cuya red pasa aproximadamente el 20 % del tráfico de la web. Pero impulsar y proteger sitios web y contenido estático es solo una parte de lo que hacemos. De hecho, más de la mitad del tráfico dinámico de nuestra red no consiste en páginas web, sino en tráfico de API (interfaz de programación de aplicaciones) — las herramientas que permiten el funcionamiento de la tecnología. Este blog presenta y complementa el informe sobre seguridad de las API 2024, en el que detallamos exactamente cómo protegemos a nuestros clientes, y lo que significa para el futuro de la seguridad de las API. A diferencia de otros informes del sector en este ámbito, nuestro informe no se basa en encuestas a usuarios, sino en datos reales de tráfico.
La moraleja de nuestro informe de este año es que muchas organizaciones carecen de inventarios de API precisos, incluso cuando creen que pueden identificar correctamente el tráfico de API. Cloudflare ayuda a las organizaciones a identificar todas sus API públicas mediante dos enfoques. En primer lugar, los clientes configuran nuestra herramienta de identificación de API para supervisar la detección de tokens presentes en su tráfico de API conocido. A continuación, utilizamos un modelo de aprendizaje automático que analiza no solo estas llamadas API conocidas, sino todas las solicitudes HTTP, e identifica el tráfico API que puede estar pasando desapercibido. La diferencia entre estos enfoques es sorprendente. Identificamos puntos finales de API adicionales a través de modelos de aprendizaje automático, en concreto un 30,7 % más que con el enfoque a través del cual las organizaciones comunican sus API, lo que sugiere que casi un tercio de las API son "API paralelas", que no se han documentado ni protegido correctamente.
Sigue leyendo para saber más y conocer los aspectos destacados de nuestro primer informe sobre la seguridad de las API. En el informe completo encontrarás estadísticas actualizadas sobre las amenazas que vemos y prevenimos, y nuestras previsiones para 2024. Creemos que la falta de atención a la seguridad de las API en las organizaciones conducirá a una mayor complejidad y pérdida de control, y el mayor acceso a la IA generativa elevará los riesgos. También prevemos un aumento de los ataques a la lógica empresarial de las API en 2024. Por último, todos los riesgos anteriores exigirán una gobernanza cada vez mayor en torno a la seguridad de las API.
Superficies de ataque ocultas
¿En qué se diferencian las páginas web y las API? Las API proporcionan una forma rápida y sencilla para que las aplicaciones recuperen datos en segundo plano, o soliciten que se realice un trabajo a otras aplicaciones. Por ejemplo, cualquiera puede escribir una aplicación meteorológica sin ser meteorólogo. Un desarrollador puede escribir la estructura de la página o aplicación móvil y pedir a una API meteorológica la previsión utilizando la ubicación del usuario. Fundamentalmente, la mayoría de los usuarios finales ignoran que los datos los ha proporcionado la API meteorológica y no el propietario de la aplicación.
Aunque las API son las herramientas esenciales de Internet, también conducen a abusos. Los fallos en la autenticación y la autorización de la API en Optus permitieron a un ciberdelincuente poner a la venta 10 millones de registros de usuarios, y las agencias gubernamentales han advertido sobre estos mismos ataques a las API. Los desarrolladores de una organización crearán a menudo API accesibles desde Internet, que sus propias aplicaciones utilizarán para funcionar con mayor eficacia. Sin embargo, corresponde al equipo de seguridad proteger estas nuevas interfaces públicas. Si el proceso de documentar las API y ponerlas en conocimiento del equipo de seguridad no está claro, se convierten en API paralelas, que funcionan en producción, pero sin el conocimiento de la organización. Aquí es donde empieza a surgir el desafío de la seguridad.
Para ayudar a los clientes a resolver este problema, lanzamos API Discovery. Cuando presentamos la última versión de esta función, mencionamos que pocas organizaciones disponen de inventarios exactos de sus API. A veces, los equipos de seguridad se ven obligados a adoptar un enfoque que consiste en "enviar un correo electrónico y preguntar" para elaborar un inventario, y al hacerlo, las respuestas quedan obsoletas inmediatamente tras la siguiente versión de la aplicación, cuando cambian las API. Es mejor hacer un seguimiento de los cambios de API mediante cambios en la base de código, y estar al día con las nuevas versiones. Sin embargo, esta práctica sigue teniendo el inconveniente de que solo se crea el inventario del código que se mantiene de forma activa. Las aplicaciones heredadas pueden no ver las nuevas versiones, a pesar de recibir tráfico de producción.
El enfoque de Cloudflare para la gestión de las API implica la creación de un inventario de API exhaustivo y preciso mediante una combinación de detección de API basada en modelos de aprendizaje automático e inspección del tráfico de red. Este enfoque forma parte integral de nuestro producto API Gateway, con el que los clientes pueden gestionar sus puntos finales accesibles desde Internet y supervisar el estado de las API. API Gateway también permite a los clientes identificar su tráfico de API mediante identificadores de sesión (normalmente un encabezado o cookie), lo que ayuda a identificar específicamente el tráfico de API para el proceso de identificación.
Como hemos señalado antes, nuestro análisis revela que incluso clientes expertos suelen pasar por alto una parte significativa de su tráfico de API. Al comparar la detección de API basada en sesiones (que utiliza sesiones de API para identificar el tráfico) con nuestra detección de API basada en el aprendizaje automático (que analiza todo el tráfico entrante), descubrimos que esta última detecta más puntos finales, ¡de media un 30,7% más! Sin un análisis exhaustivo del tráfico, puedes estar pasando por alto casi un tercio de tu inventario de API.
Aunque no seas cliente de Cloudflare, puedes empezar a crear un inventario de tus API. Las API se suelen clasificar en un formato estandarizado llamado OpenAPI, y muchas herramientas de desarrollo pueden crear archivos de esquema con formato OpenAPI. Si tienes un archivo con ese formato, puedes empezar a crear tú mismo un inventario de API recopilando estos esquemas. A continuación verás un ejemplo de cómo puedes extraer los puntos finales de un archivo de esquema, suponiendo que tengas un archivo con formato OpenAPI v3 llamado `my_schema.json`:
A menos que hayas estado generando esquemas OpenAPI y supervisando el inventario de tus API desde el principio del proceso de desarrollo de tu aplicación, probablemente te falten algunos puntos finales en el inventario de las API de tu aplicación de producción.
import json
import csv
from io import StringIO
# Load the OpenAPI schema from a file
with open("my_schema.json", "r") as file:
schema = json.load(file)
# Prepare CSV output
output = StringIO()
writer = csv.writer(output)
# Write CSV header
writer.writerow(["Server", "Path", "Method"])
# Extract and write data to CSV
servers = schema.get("servers", [])
for server in servers:
url = server['url']
for path, methods in schema['paths'].items():
for method in methods.keys():
writer.writerow([url, path, method])
# Get and print CSV string
csv_output = output.getvalue().strip()
print(csv_output)Los límites de velocidad exactos minimizan el riesgo potencial de ataques
Cuando se trata de detener el abuso, la mayoría de los profesionales piensan primero en limitar la velocidad. La implementación de límites en tu API es una herramienta útil para mantener bajo control el abuso y evitar la sobrecarga accidental del servidor. Pero, ¿cómo sabes si has elegido el enfoque de limitación de velocidad correcto? Los enfoques pueden variar, pero generalmente se reducen al código de error elegido y a la base del propio valor límite.
En el caso de algunas API, los usuarios avanzados configuran errores de limitación de velocidad para que devuelvan un código de error HTTP 403 (prohibido), mientras que otras devolverán un mensaje de error HTTP 429 (demasiadas solicitudes). El uso del código HTTP 403 parece bastante inofensivo hasta que te das cuenta de que otras herramientas de seguridad también devuelven códigos 403. Cuando te están atacando, puede ser difícil descifrar qué herramientas son responsables de qué errores / bloqueos.
Como alternativa, si utilizas el código HTTP 429 para tus límites de velocidad, los atacantes sabrán al instante que se les ha limitado la velocidad y podrán "navegar" justo por debajo del límite sin ser detectados. Esta opción puede estar bien si solo limitas las solicitudes para garantizar que tu backend siga en línea, pero puede descubrir tus cartas ante los atacantes. Además, estos pueden "escalar" a más clientes API para hacer solicitudes por encima del límite de velocidad en la práctica.
Hay pros y contras en ambos enfoques, pero observamos que, de todos los mensajes de error 4xx y 5xx, la mayoría de las API devuelven un código HTTP 429 (casi el 52 %).
¿Qué pasa con la lógica de la propia regla de límite de velocidad, no solo con el código de respuesta? La implementación de límites de solicitud en direcciones IP puede ser tentador, pero te recomendamos que bases el límite en un identificador de sesión como práctica recomendada y que solo recurras a la dirección IP (o huella de JA3 + IP) cuando los identificadores de sesión no estén disponibles. Si estableces los límites de velocidad en las sesiones de usuario en lugar de en las direcciones IP, identificarás de manera fiable a tus usuarios reales y minimizarás los falsos positivos debidos al espacio IP compartido. La limitación de velocidad avanzada de Cloudflare y la protección contra el abuso volumétrico de API Gateway facilitan la aplicación de estos límites mediante la configuración de perfiles de tráfico de sesión en cada punto final de API y ofrecen soluciones de un solo clic para configurar los límites de velocidad por punto final.
Para encontrar valores para tus límites de velocidad, Cloudflare API Gateway calcula las estadísticas de las solicitudes de sesión por ti. Sugerimos establecer un límite observando la distribución de las solicitudes por sesión en todas las sesiones de tu API detectadas por el identificador de sesión de API configurado por el cliente. A continuación, calculamos los valores p, que describen las velocidades de solicitudes para diferentes grupos de tráfico, para p50, p90 y p99 en esta distribución, y utilizamos la variedad de la distribución para obtener un umbral recomendado para cada punto final de tu inventario de API. Puede que la recomendación no coincida con los valores p, lo cual es una distinción importante y una razón para no utilizar solo los valores p. Junto con la recomendación, API Gateway informa a los usuarios de nuestra confianza en la recomendación. Por lo general, cuantas más sesiones API seamos capaces de recopilar, más confianza tendremos en la recomendación.
La activación de un límite de velocidad es muy fácil. Solo tienes que hacer clic en el enlace "crear regla", y API Gateway llevará automáticamente el identificador de tu sesión a la página de creación de reglas de limitación de velocidad avanzada, garantizando que tus reglas tengan una precisión milimétrica para protegerte de los ataques y minimizar los falsos positivos en comparación con los límites tradicionales, que son demasiado amplios.
Las API también son víctimas de los ataques a las aplicaciones web
Las API no son inmunes a los ataques del estilo de las 10 principales vulnerabilidades de OWASP, como la inyección de código SQL. El cuerpo de las solicitudes API también puede encontrar su camino como entrada de una base de datos, igual que la entrada de un formulario de una página web o los parámetros de una URL. Es importante que te asegures de tener un firewall de aplicaciones web (WAF) que también proteja tu tráfico de API para defenderte de este tipo de ataques.
De hecho, cuando examinamos las reglas gestionadas del WAF de Cloudflare, los ataques de inyección fueron el segundo vector de amenaza más común que Cloudflare observó contra las API. La amenaza más común fueron las anomalías HTTP. Algunos ejemplos de anomalías HTTP son los nombres de método incorrectos, los caracteres nulos de bytes en los encabezados, los puertos no estándar o la longitud de contenido de cero con una solicitud POST. A continuación, mostramos las estadísticas de las otras amenazas principales que vimos contra las API:
Los errores de autenticación y autorización no están incluidos en la imagen. Este tipo de errores ocurre cuando una API no comprueba si la entidad que envía solicitudes de información a una API tiene realmente permiso para solicitar esos datos o no. También puede ocurrir cuando los ataques intentan falsificar credenciales e incluir permisos menos restrictivos en sus credenciales existentes (válidas), cuyos permisos son más restrictivos. OWASP clasifica estos ataques de varias formas diferentes, pero las categorías principales son los ataques BOLA (error de autorización a nivel de objeto) y BLFA (error de autorización a nivel de función).
La causa fundamental del éxito de un ataque BOLA / BFLA radica en que una API de servidor no comprueba la propiedad adecuada de los registros de la base de datos con la identidad que solicita dichos registros. El rastreo de estos ataques específicos puede ser difícil, ya que la estructura de permisos puede ser prácticamente inexistente, inadecuada o estar mal implementada. ¿Te das cuentas de que estamos ante el problema del huevo y la gallina? Sería fácil detener estos ataques si conociéramos la estructura de permisos adecuada, pero si nosotros o nuestros clientes la conociéramos o pudiéramos garantizar su aplicación, para empezar, los ataques fracasarían. No te pierdas los próximos lanzamientos de más funciones de API Gateway, en las que utilizaremos nuestro conocimiento de las normas de tráfico de las API para sugerir automáticamente políticas de seguridad que señalen y detengan los ataques BOLA / BFLA.
Aquí tienes cuatro formas de eliminar las lagunas de autenticación que puedan existir en tus API, aunque no dispongas de una política de autorización detallada:
En primer lugar, aplica la autenticación en cada API accesible desde Internet a menos que haya una excepción aprobada por la empresa. Utiliza tecnologías como mTLS y JSON Web Tokens.
Limita la velocidad de las solicitudes de API a tus servidores para impedir el avance de posibles atacantes.
Bloquea los volúmenes anormales de salida de datos confidenciales.
Impide que los atacantes se salten secuencias legítimas de solicitudes API.
Las API se orientan a los usuarios, no a las máquinas
Si llevas en el mundo de tecnología desde antes de la aparición de los teléfonos inteligentes, cuando menos usuarios estaban acostumbrados a estar en línea, puede ser tentador pensar que las API solo se utilizan para la comunicación entre máquinas, en algo así como un proceso de trabajo por lotes nocturno. Sin embargo, nada más lejos de la realidad. Como hemos comentado, muchas aplicaciones web y móviles funcionan con API, que facilitan todo tipo de acciones desde la autenticación hasta las transacciones y el servicio de archivos multimedia. A medida que la gente utiliza estas aplicaciones, se produce el correspondiente aumento del volumen de tráfico de las API.
Podemos explicarlo observando los patrones de tráfico de API durante los días festivos, cuando la gente se reúne con amigos y familiares y pasa más tiempo socializando en persona y menos tiempo en línea. Hemos incluido los días festivos y las promociones más comunes en el siguiente gráfico del tráfico global de las API. Observa cómo el tráfico alcanza picos del +10 % en torno al Black Friday y el Cyber Monday cuando la gente compra por Internet, pero luego el tráfico disminuye durante la Navidad y Año Nuevo.
Este patrón se parece mucho a lo que observamos en el tráfico HTTP normal. Está claro que las API ya no son solo el dominio de los procesos automatizados, sino que están estrechamente vinculadas a los comportamientos humanos y las tendencias sociales.
Recomendaciones
No existe una fórmula mágica para la seguridad integral de las API. Para lograr mejores resultados, Cloudflare recomienda cuatro estrategias para aumentar la postura de seguridad de las API:
Combina el desarrollo, la visibilidad, el rendimiento y la seguridad de las aplicaciones API con un plano de control unificado que pueda mantener un inventario actualizado de las API.
Utiliza herramientas de seguridad que utilicen tecnologías de aprendizaje automático para liberar recursos humanos y reducir costes.
Adopta un modelo de seguridad positivo para tus API (más adelante explicamos los modelos de seguridad positivos y negativos).
Mide y mejora el nivel de madurez de la API de tu organización a lo largo del tiempo (consulta también más abajo una explicación sobre el nivel de madurez de una API).
¿Qué entendemos por modelo de seguridad "positivo" o "negativo"? En un modelo negativo, las herramientas de seguridad buscan señales conocidas de ataques y toman medidas para detenerlos. En un modelo positivo, las herramientas de seguridad buscan solicitudes buenas conocidas que son las que autorizan, bloqueando todo lo demás. Las API suelen estar tan estructuradas que tiene sentido que se adopten modelos de seguridad positivos para los máximos niveles de seguridad. También puedes combinar modelos de seguridad, por ejemplo, utilizando un WAF como parte de un modelo negativo y la validación del esquema de la API como parte de un modelo positivo.
He aquí una forma rápida de medir el nivel de madurez de seguridad de la API de tu organización a lo largo del tiempo. Las organizaciones que estén iniciando su andadura empezarán por elaborar su primer inventario de API, por incompleto que sea. Las organizaciones más maduras se esforzarán por que el inventario de API sea preciso y se actualice de forma automática. Las organizaciones más maduras aplicarán de forma activa comprobaciones de seguridad en un modelo de seguridad positivo en sus API, aplicarán el esquema de la API, la autenticación válida y comprobarán el comportamiento en busca de indicios de abuso.
Previsiones
Por último, estas son nuestras cuatro principales previsiones para 2024 y en adelante:
Mayor pérdida de control y complejidad: tras una encuesta a profesionales del campo de la seguridad y la gestión de las API, el 73 % de los encuestados reconoció que los requisitos de seguridad interfieren en su productividad e innovación. La mayor expansión de las aplicaciones y la inexactitud de los inventarios elevarán los riesgos y la complejidad de las API.
Un acceso más fácil a la IA conlleva más riesgos para las API: el aumento de la IA generativa conlleva riesgos potenciales, como que las API de los modelos de IA sean vulnerables a los ataques, pero también que los desarrolladores envíen código con errores, escrito con IA. Forrester prevé que, en 2024, sin la protección adecuada, "al menos tres fugas de datos se atribuirán públicamente a código poco seguro generado por IA, ya sea debido a fallos de seguridad en el propio código generado o a vulnerabilidades en las dependencias sugeridas por la IA".
Aumento de los ataques a la lógica empresarial: los estafadores profesionales dirigen sus operaciones como una empresa, y tienen costes como cualquier otra. Prevemos que los atacantes ejecutarán bots fraudulentos de forma eficiente contra las API, incluso más que en años anteriores.
Mayor gobernanza: la primera versión del estándar PCI DSS que aborda directamente la seguridad de las API entrará en vigor en marzo de 2024. Consulta los requisitos específicos de tu sector con tu departamento de auditoría para estar preparado para la entrada en vigor de los requisitos.
Si te interesa, puedes descargar aquí el informe completo sobre la seguridad de las API 2024, que incluye todos los detalles de nuestras recomendaciones.
Cloudflare API Gateway es nuestra solución de seguridad de las API, y está disponible para todos los clientes Enterprise. Si no estás suscrito a API Gateway, haz clic aquí para ver los resultados iniciales de API Discovery e inicia una prueba en el panel de control de Cloudflare. Para saber cómo utilizar API Gateway para proteger tu tráfico, haz clic aquí para ver nuestros documentos para desarrolladores y aquí para consultar nuestra guía de inicio.