Cuatro suposiciones que impiden una protección eficaz de las APIs
This post is also available in:
Inglés 
Francés 
Alemán 
Italiano 
Portugués, Brasil
No es un secreto para nadie que todas las aplicaciones modernas utilizan APIs para interactuar con sus diferentes componentes, sus usuarios y, a veces, con servicios externos. De hecho, el uso de las APIs aumentó durante 2021. Según una investigación de mercado, el tráfico de ataques triplicó su crecimiento comparado con el tráfico total de las APIs. Como si esto fuera poco, Gartner estimó que, en 2021, más del 50% de los incidentes de robos de datos se rastrearon hasta las APIs inseguras.
Entonces, ¿por qué la protección de las APIs no ha seguido el ritmo de su uso? Según lo que escuchamos de las empresas sobre sus estrategias de protección, aparentemente muchas están haciendo suposiciones falsas que dejan a sus APIs vulnerables y expuestas a amenazas.
Suposición n.º 1: Mi WAF protege mis aplicaciones y sus APIs
Si bien esta suposición es correcta hasta cierto punto, las APIs están expuestas a muchos vectores de amenazas que la mayoría de los firewalls de las aplicaciones web (WAF) no pueden proteger.
En primer lugar, la mayoría de las soluciones WAF se diseñaron para proteger las vulnerabilidades de las aplicaciones web. Las APIs, por otro lado, requieren un análisis específico, como la capacidad de analizar su contenido y compararlo con el diseño específico de la API. Los WAFs estándar no suelen incluir este tipo de capacidades.
En segundo lugar, la mayoría de las soluciones WAF (en especial los servicios gestionados de WAF en la nube) solo implementan modelos de seguridad negativos. Esto limita la protección que pueden brindar estas soluciones contra los ataques de día cero, que son ataques desconocidos, para los cuales aún no existe una firma. La lista de los diez principales vectores de amenazas de OWASP API incluye muchos tipos de ataques que simplemente no se pueden cubrir a través de un modelo de seguridad negativo. Requieren un análisis de seguridad y del comportamiento positivo para identificar si la llamada a la API es maliciosa o no —una función que la mayoría de los WAFs simplemente no tienen.
Finalmente, también existen las amenazas automatizadas, que incluyen bots maliciosos, y que pueden plantear un gran problema para las APIs. ¿Cómo podemos distinguir entre un bot malicioso y una llamada máquina a máquina legítima? Las soluciones de gestión de bots avanzadas, que también pueden analizar las llamadas a las API, son necesarias para protegerse contra los ataques de bots maliciosos, como la toma de control de cuentas (ATO), el raspado de datos y otros tipos de ataques de Dos a las aplicaciones. Actualmente, ningún WAF ofrece esta funcionalidad.
Suposición n.º 2: La puerta de enlace gestiona y protege mis APIs
Las puertas de enlace de las APIs siempre se diseñaron para gestionar el ciclo de vida de las APIs, traducir protocolos, enrutar las llamadas a las APIs al destino correcto y administrar las cuotas para garantizar que los recursos del servidor que manejan las llamadas no se agoten ni estén sometidos a abusos.
Además, las puertas de enlace a las APIs autentifican a la entidad que hace la llamada para comprobar que tenga la autorización para ejecutar dicha llamada específica. Algunas puertas de enlace a las APIs también tienen un motor integrado basado en las firmas, que proporciona protección adicional a las llamadas a las APIs que procesa. Si bien todas estas son funciones importantes, no alcanzan para proporcionar una protección efectiva a las APIs. Hasta hoy, no existe una solución de puerta de enlace a las APIs que incluya su protección con un motor de modelo de seguridad positiva, capacidades de protección de bots, análisis del comportamiento y protección contra DoS de las aplicaciones.
¿Sabías que todas las llamadas a las APIs se centralizan para pasar a través de las puertas de enlace? Esto solo es verdad en el caso de las APIs conocidas y gestionadas. En consecuencia, en muchas organizaciones, hay muchas APIs no documentadas ni gestionadas que no se abordan, y es imposible proteger lo que no sabes que existe.
Es más, la mayoría de las puertas de enlace a las APIs incluye enlaces para la integración con soluciones de protección de APIs de terceros. Esta es una afirmación clara de los proveedores de APIs, que comprenden la limitación de su puerta de enlace para proteger a las mismas APIs que ellos gestionan.
Suposición n.º 3: Mis APIs están bien documentadas, lo que permite una protección efectiva
En efecto, para proteger de manera efectiva una API, necesitas tener un conocimiento profundo de su estructura, sus posibles parámetros, el tipo y rango de valores y el contenido esperado en el cuerpo de la API. Las APIs bien documentadas, combinadas con una buena solución de protección, pueden incrementar la protección drásticamente.
No obstante, en la mayoría de los casos, no todas las APIs que se usan en una organización están documentadas. E incluso si lo están, las APIs cambian con más frecuencia que las aplicaciones. Como resultado, su documentación y la política de seguridad deben actualizarse regularmente; una tarea que no sucede con la frecuencia que debería. Y si les preguntas a los arquitectos de la seguridad, la mayoría te dirán que no confían en la documentación de la API.
Cualquier solución de protección efectiva debe incluir descubrimiento automático de las APIs. Esto incluye descubrir, no solo su existencia sino también su estructura (es decir, diseño), sus parámetros, tipo de parámetros y sus rangos de valores. Un buen motor de descubrimiento también puede generar y aplicar de manera automática una política de seguridad personalizada que coincida con las APIs descubiertas para protegerlas de manera efectiva. Esta es la mejor manera de proteger una API a lo largo de todo su ciclo de vida.
Suposición n.º 4: Tengo una solución de protección de las APIs dedicada: estoy cubierto
Tener una buena protección de las APIs que cubra las recomendaciones mencionadas en este blog es un gran comienzo. Pero es solo eso, un comienzo, y no es suficiente para proteger por completo tu aplicación. Las APIs no existen por sí mismas. Son parte de una aplicación. La aplicación se implementa en una infraestructura. Los hackers que no puedan encontrar su camino a través de las APIs buscarán la forma de entrar a través de una vulnerabilidad de la aplicación que no tiene relación con la API. Podrían lanzar un ataque de bots o simplemente atacar la infraestructura con un ataque de DDoS.
La protección de las aplicaciones debería verse de manera holística. Esto significa que se deberían cubrir todas las bases. Tu protección es solo tan fuerte como tu enlace más débil.
La protección de la API es solo uno de los componentes importantes en tu arquitectura de protección total de las aplicaciones, que también debería incluir un WAF fuerte, gestión de bots, inteligencia de amenazas y protección contra DDoS. Si puedes gestionar estas soluciones desde un único panel y sincronizarlas, tus aplicaciones y APIs estarán efectivamente protegidas.
¿Quieres obtener más información? Únete a nuestro webinar, donde brindaremos más información sobre las mejores prácticas para abordar las brechas en la protección presentadas en este blog.
¿Te gusta esta publicación? Subscríbete ahora para recibir el contenido más reciente de Radware en tu bandeja de entrada todas las semanas, además de acceso exclusivo al contenido Premium de Radware.
