¿Qué es la seguridad de las API?

Por qué es importante la seguridad de las API

Las aplicaciones son ubicuas y constituyen un componente clave de las empresas y la sociedad en general. Pero es que, además, detrás de casi cualquier aplicación hay una API, por lo que su seguridad es absolutamente crucial.

Las API actúan como el marco de back-end tanto de la mayoría de las aplicaciones nativas en la nube, incluidas las aplicaciones móviles, las web y las de software como servicio (SaaS), como de las aplicaciones internas y las destinadas a partners y clientes. Para poner el uso de las API en perspectiva, Postman, la plataforma de gestión de API, registró 1130 millones de llamadas de las API en 2022. El auge de las API, por supuesto, conlleva una superficie de ataque potencialmente muy lucrativa para los ciberdelincuentes.

Como las API exponen la lógica de las aplicaciones, recursos y datos confidenciales —como información de identificación personal (PII)—, se han convertido en un blanco para los atacantes. Si los atacantes logran acceder a las API sin proteger, podrán interrumpir la actividad empresarial, acceder a datos confidenciales y destruirlos, y robar la propiedad.

La seguridad tradicional de las aplicaciones web

En la época de las aplicaciones monolíticas, la seguridad de las aplicaciones web consistía en implementar un cortafuegos de aplicaciones web (WAF) en el perímetro para interceptar e inspeccionar el tráfico HTTP enviado por los clientes web. Los WAF ofrecían, y siguen ofreciendo, una seguridad de las aplicaciones eficaz frente a los usuarios maliciosos que pretendieran atacar los envíos de formularios web HTTP o solicitudes del navegador estándar.

Pero la naturaleza de las aplicaciones web ha cambiado y ya no se alojan en servidores web independientes, sino en aplicaciones nativas en la nube basadas en contenedores que están distribuidas en un clúster de servidores host.

Así las cosas, los desarrolladores y equipos de seguridad de hoy en día, que gestionan arquitecturas de microservicios nativas en la nube muy distribuidas, tienen que defender unas redes que carecen de perímetro. Las fuentes de las que beben las aplicaciones modernas son muy variadas: solicitudes web estándar, llamadas API desde dispositivos móviles, eventos en la nube, comunicaciones telemétricas de dispositivos IoT, almacenamiento en la nube…

En una secuencia de flujos de comunicación, las solicitudes HTTP entrantes de los clientes (es decir, tráfico vertical) suelen ir primeras. En muchos casos, una sola solicitud entrante genera decenas de llamadas API internas (es decir, tráfico horizontal). Si esas llamadas API no se inspeccionan y validan correctamente, los endpoints de API quedarán desprotegidos.

Inspeccionar la entrada en el perímetro es insuficiente para reconocer las cargas útiles peligrosas. Los endpoints de API pueden desconfigurarse y permitir el acceso no autorizado a determinados microservicios, con la consiguiente exposición de la lógica de la aplicación a actos maliciosos. Es esencial, por tanto, supervisar y proteger todos los endpoints de API, externos e internos, de manera continua.

Anatomía de un ataque a una API

Los atacantes se aprovechan de que las organizaciones funcionen a base de API y buscan fallos que explotar en estas API. Este ejemplo de ataque basado en una API dirigido a una aplicación de comercio electrónico con una aplicación móvil como protagonista ilustra lo fácil que es para los actores de amenazas encontrar formas de llegar a los datos valiosos.

Paso 1: el atacante aplica la ingeniería inversa a la aplicación móvil para identificar la URL de un endpoint de API obsoleta y la usa para extraer datos de un microservicio de back-end.

Paso 2: el atacante se da cuenta de que, para enviar llamadas API a este endpoint, no necesita ni autenticación ni autorización.

Paso 3: el atacante explota la vulnerabilidad SQLi. La URL del endpoint de API incluye un identificador de producto único en forma de valor numérico y el atacante ejecuta una serie de comprobaciones automatizadas para descubrir que el campo de entrada <id_de_producto> puede utilizarse para consumar un ataque a la vulnerabilidad SQLi.

Paso 4: en lugar de atacar esta vulnerabilidad SQLi para manipular los datos, el atacante decide ejecutar un comando de shell en el microservicio que ejecuta la base de datos SQL. El comando de shell descarga un ejecutable malicioso y lo ejecuta. El ejecutable resulta ser un software de minería de bitcoins.

Riesgos de seguridad de las API

Los errores de configuración, los fallos lógicos y las vulnerabilidades de las API dejan las aplicaciones y los datos a merced de los atacantes. Aunque una puerta de enlace de API solo puede ver el tráfico de API que la atraviesa y no ofrece visibilidad del tráfico interno, algunas organizaciones relegan la seguridad de las API a una puerta de enlace de API creyendo que así está protegida.

Los equipos de seguridad necesitan visibilidad de su superficie de API. No se puede proteger lo que no se ve y lo que no se ve termina convirtiéndose en la actividad no detectada de los adversarios que descubren una API en la sombra.

Aunque las puertas de enlace de API supervisan las API y su uso de manera eficaz, no son capaces de detectar ni de bloquear los ataques. La seguridad de las API requiere, además de protección en tiempo real frente a los ataques maliciosos, visibilidad y gestión de riesgos.

OWASP Top 10

En 2019, el Proyecto abierto de seguridad de aplicaciones web (OWASP) publicó una lista de los principales 10 riesgos de seguridad de las API para sensibilizar sobre este tipo de riesgos, que afectan también a las aplicaciones web modernas. La lista esboza los ataques más comunes contra las API web e incluye consejos para protegerse de estas amenazas.

Fallos en la autorización a nivel de objeto

Los endpoints que gestionan identificadores de objetos suelen quedar expuestos por las API, lo que genera problemas en los controles de acceso por niveles que agrandan la superficie de ataque. Sin las debidas comprobaciones de autorización, los atacantes podrían, por ejemplo, sustituir durante una llamada API el ID de un recurso que pertenezca a otro usuario. Conocido como ataque de referencia directa insegura a objetos (IDOR), permite al atacante acceder a un recurso sin autorización.

Fallos en la autenticación de los usuarios

Los mecanismos de autenticación de las API las convierten en blanco fácil debido a que están expuestas a todo el mundo. Un mecanismo de autenticación mal implementado o, lo que es lo mismo, una vulnerabilidad de autenticación en la API, permite el ingreso a los atacantes, quienes pueden explotar fallos en la implementación para asumir la identidad de usuarios autorizados.

Los errores de configuración de la autenticación en sistemas API pueden producirse cuando se desatienden las prácticas recomendadas del sector y, por ejemplo, deja de implementarse la validación de los identificadores de acceso o de las credenciales y las claves se almacenan en las URL de endpoint de la API.

Exposición excesiva de los datos

Cuantos más datos se exponen, mayor es el riesgo. Durante la implementación de las API, los desarrolladores a veces exponen propiedades de los objetos sin restricciones detalladas y confían en que el cliente filtre los datos innecesarios antes de mostrarlos en la IU. Pero, aun en el caso de que el cliente de la API filtrara los datos confidenciales, los atacantes podrían explotar la llamada API inicial y, tal vez, obtener acceso a números de tarjeta de crédito, credenciales de inicio de sesión y números de la Seguridad Social.

Falta de recursos y límites de frecuencia

Las API que no restringen el número de recursos a los que puede llamar un cliente son vulnerables a la sobrecarga del tráfico. Este tipo de sobrecarga empeora el rendimiento del servidor de API, bloquea a usuarios legítimos y puede desembocar en un ataque de DoS. La sobrecarga del servidor de API expone la API a los fallos de autenticación, como la fuerza bruta.

Fallos en la autorización a nivel de función

Uno de los retos a los que se enfrentan los desarrolladores de API es la complejidad que supone implementar políticas de control de acceso para distintas jerarquías de grupos de usuarios y funciones. La distinción entre las funciones de administración y de uso estándar es borrosa, lo que crea fallos en la autorización que los atacantes pueden explotar para obtener acceso a los recursos de un usuario o ejecutar funciones administrativas no autorizadas.

Asignación masiva

La vulnerabilidad de asignación masiva surge cuando los datos suministrados por un cliente están vinculados a modelos de datos que no se han contrastado con una lista de permitidos que impediría que los usuarios asignaran datos a campos protegidos. Con esta vulnerabilidad, los atacantes pueden obtener acceso a datos confidenciales mediante la interceptación de consultas API y la modificación de las propiedades de los objetos de back-end almacenados. Para ello, tratan de adivinar propiedades de objetos, leen documentación y examinan endpoints de API en busca de pistas que les permitan averiguar cómo poner en riesgo la seguridad de los atributos de los datos de una API privada.

Errores de configuración de la seguridad

Los errores de configuración de la seguridad pueden exponer información del usuario y detalles del sistema confidenciales y, como consecuencia, poner en riesgo el servidor. Entre las causas habituales, se cuentan el intercambio de recursos de origen cruzado (CORS), configuraciones incompletas o «ad hoc», encabezados HTTP o métodos HTTP incorrectos, configuraciones de fábrica poco seguras, configuraciones incompletas o incorrectas, y mensajes de error demasiado prolijos que exponen información confidencial.

Inyección

Las API están sujetas a las vulnerabilidades por inyección —inyección de SQL, de NoSQL y de comandos— que pueden producirse cuando se envían datos no fiables a un intérprete en un comando o consulta. Un atacante puede engañar a un intérprete para que ejecute comandos peligrosos y exponga datos no autorizados para manipularlos y robarlos.

Gestión de activos inadecuada

Las API exponen más endpoints que las aplicaciones web tradicionales, por lo que impedir que las API hagan un uso indebido de los endpoints de API confidenciales o vulnerables expuestos pasa por adoptar una gestión de API robusta que los controle. Los atacantes pueden usar endpoints de API o de depuración de errores obsoletos para atacar la aplicación.

Registro y supervisión insuficientes

El registro y la supervisión inadecuados, aunque no suponen una amenaza directa, retrasan la detección de actividad maliciosa. Los atacantes, que trabajan en la sombra, tienen tiempo de sobra para desarrollar sus ataques y propagarlos por distintos sistemas con el fin de alterar, extraer y destruir datos. Según varios estudios sobre brechas, se puede llegar a tardar más de 200 días en detectar una amenaza persistente. Y, tras una brecha de datos, sin un sistema de registro y supervisión adecuado, las organizaciones carecen de la información forense que necesitan para evaluar el daño.

Seguridad de las API para SOAP, REST y GraphQL

SOAP, REST y GraphQL son tres patrones de arquitectura de API habituales y cada estilo arquitectónico plantea sus propias consideraciones de seguridad.

Seguridad de las API SOAP

SOAP (protocolo simple de acceso a objetos) es un protocolo para intercambiar datos estructurados en la implementación de servicios web en redes de ordenadores. SOAP utiliza XML como formato de mensajes y puede transmitirse a través de distintos protocolos de niveles inferiores, como HTTP y SMTP. Las API SOAP suelen protegerse mediante una combinación de seguridad de la capa de transporte (como HTTPS) y en el nivel del mensaje (como XML, las firmas digitales y el cifrado).

La seguridad de las API SOAP afecta a las extensiones de los protocolos. SOAP se adhiere a las especificaciones de los servicios web (WS), que garantizan una seguridad de tipo empresarial para todos los servicios web a través de funciones como WS-ReliableMessaging, que amplía la asistencia integrada para la gestión de errores.

Seguridad de las API REST

La arquitectura de API de transferencia de estado representacional, o API REST, utiliza la transferencia de datos JSON y el protocolo de transferencia HTTP/S; en comparación con otras arquitecturas de API, simplifican el desarrollo de las API REST. Las API RESTful emplean solicitudes HTTP para crear (POST), actualizar (PUT), leer (GET) y eliminar (DELETE) datos.

La seguridad de las API REST, que carecen de unas disposiciones de seguridad propias, depende del diseño de la API. Los servicios de transmisión de datos, implementación e interacción con los clientes deben incorporar ciertas consideraciones de seguridad. La mayoría de las API RESTful usarán métodos de seguridad de la capa de transporte (como HTTPS) y autenticación basada en identificadores.

Una opción arquitectónica habitual para proteger la seguridad de las API REST consiste en implementarlas detrás de una puerta de enlace de API y, a continuación, ofrecer esta opción de conectividad a los clientes. No obstante, hay que tener en cuenta que una puerta de enlace de API no está equipada para defender de todas las amenazas de seguridad.

REST vs. SOAP

Tanto las API SOAP como las RESTful admiten solicitudes y respuestas HTTP, así como la capa de sockets seguros (SSL), pero eso es todo lo que tienen en común. Las API SOAP, que incluyen funciones de seguridad integradas, son seguras por naturaleza. Por el contrario, para que las API RESTful sean seguras, es necesario implementar medidas de seguridad y opciones arquitectónicas.

Seguridad de las API GraphQL

GraphQL es un lenguaje de API de código abierto que describe el modo en que los clientes solicitan información y actúa como un tiempo de ejecución para responder a las consultas con los datos de que dispone. Los desarrolladores utilizan la sintaxis de GraphQL para realizar solicitudes de datos específicos desde una o varias fuentes. Con GraphQL, los clientes pueden definir la estructura de los datos para una consulta y el servidor se asegurará de devolver la estructura exacta.

La aplicación de los mecanismos de seguridad de las API GraphQL presenta retos relacionados con las solicitudes personalizables y flexibles. El servidor no tiene por qué saber gestionar las consultas complejas y, en el proceso, podría ejecutar consultas maliciosas por error.

Algunos métodos para mitigar los riesgos de seguridad de las API GraphQL incluyen la limitación y configuración de una profundidad máxima de consultas, así como la expiración de las consultas para evitar que se reciban consultas demasiado grandes.

Prácticas recomendadas en materia de seguridad de las API

Dado que cada vez hay más API de acceso público, es importante responder a los riesgos de exposición de los datos implementando prácticas recomendadas que reduzcan al mínimo la superficie de ataque, corrijan las vulnerabilidades y detecten la actividad maliciosa en tiempo casi real.

Utilice métodos seguros de autenticación y autorización

Asegúrese de que solo puedan acceder a la API los usuarios autorizados con métodos de autenticación seguros, como OAuth2 o los identificadores web de JSON (JWT).

Implemente límites de frecuencia

Implemente límites de frecuencia en sus API para evitar los ataques por fuerza bruta y otros comportamientos maliciosos. Los límites de frecuencia restringen el número de solicitudes que puede recibir una API en un periodo de tiempo dado.

Use HTTPS

Las solicitudes y respuestas API deberían hacerse a través de HTTPS para asegurarse de que están cifradas y son seguras, sobre todo si los datos son confidenciales.

Realice evaluaciones de seguridad regulares

Evalúe la seguridad de sus API con regularidad para identificar posibles vulnerabilidades. Revise las modificaciones en el inventario de API para detectar nuevas API expuestas y sus perfiles de riesgo, incluida la exposición a datos confidenciales, la exposición a internet, lasvulnerabilidades de las cargas de trabajo y el nivel de autenticación.

Use una clave de API

Una clave de API es un identificador único empleado para saber qué aplicaciones llaman a una API y verificar que están autorizarlas a hacerlo. La diferencia entre las claves de API y los identificadores de autenticación reside en que aquellas identifican la aplicación (o sitio web) que hace la llamada a la API, no la persona que utiliza la aplicación (o sitio web). Ambas medidas de seguridad son importantes.

Siga las prácticas recomendadas en materia de almacenamiento de claves de API para evitar llamadas no deseadas, accesos no autorizados y posibles brechas de datos con pérdida de información personal.

Supervise sus API

Gestione y supervise las especificaciones, la documentación, los casos de prueba, el tráfico y los parámetros de las API. Bloquee la actividad no deseada, como los bots y el tráfico de las API maliciosos, para ayudar a proteger la aplicación y reducir costes innecesarios.

Forme a sus equipos en las prácticas de seguridad recomendadas

Incorpore la seguridad al principio de los ciclos de CI/CD y forme a sus desarrolladores para que mejoren sus conocimientos sobre los riesgos de seguridad, como la falta de una autenticación robusta y las vulnerabilidades lógicas. Implemente los principios de DevSecOps como la colaboración entre los equipos de seguridad y desarrollo.

Conozca sus vulnerabilidades

Identifique los puntos débiles de su ciclo de API buscando de forma rutinaria los principales 10 riesgos de seguridad de las API descritos por el OWASP. Utilice herramientas de análisis de API y técnicas para identificar sus vulnerabilidades y resolverlas de inmediato para evitar su explotación.

Exija un identificador de seguridad para la autenticación

Exigir un identificador de seguridad para la autenticación es la primera línea de defensa. Los identificadores de seguridad protegen las API de los accesos no autorizados rechazando la llamada a la API en el caso de que el identificador de un usuario no supere la verificación.

En resumen, las prácticas recomendadas deberían empezar por visibilizar y supervisar sus superficies de ataque para detectar automáticamente todas las aplicaciones web y endpoints de API de su entorno. Las capas de defensa deben incluir políticas para el tráfico vertical y horizontal que bloqueen las amenazas maliciosas, se originen en internet o dentro de sus aplicaciones.

Añadir otra capa de análisis de vulnerabilidades y del cumplimiento normativo, así como un sistema de autenticación sólido, protegerá aún mejor sus aplicaciones. Tampoco se olvide de sus cargas de trabajo o de la capa de la infraestructura, como los hosts, las máquinas virtuales (VM), los contenedores y las funciones sin servidor que ayudan a alojar sus aplicaciones. Estas también hay que protegerlas.

Solución de seguridad de las API de Prisma Cloud

Prisma Cloud brinda detección de API, creación de perfiles de riesgo y protección en tiempo real, todo ello integrado en nuestra plataforma de protección de aplicaciones nativas en la nube (CNAPP).

Funciones de seguridad de las API

• Detección de las API: detecte todas las API de su entorno automáticamente y elimine los ángulos muertos creados por las API fraudulentas o en la sombra.
• Perfiles de riesgo de las API: identifique los riesgos de las API y los factores de riesgo (como los errores de configuración, la exposición a datos confidenciales y los controles de acceso) y priorice su corrección.
• Protección en tiempo real: aplique medidas de protección en tiempo real para combatir tanto los principales 10 riesgos de seguridad de las API descritos por el OWASP como los bots maliciosos, e implemente límites de frecuencia.

Preguntas frecuentes sobre la seguridad de las API