El uso de APIs y de herramientas para su gestión son una tendencia cada vez más demandada y extendida dentro de las organizaciones.

De hecho, es un dato que podemos ver en el estudio de Akamai de 2019, del cual se desprende que el 83% de todo el tráfico web va a través de APIs.  

Este volumen de información hace que los ataques también aumenten. Gartner estima que en el año 2022 los abusos derivados de las APIs serán el vector de ataque más frecuente, pero actualmente ya es una preocupación. 

En el informe de ataques en plataformas cloud de Cloud Security Alliance ya lo consideran la tercera vulnerabilidad más preocupante, y en el top 10 OWASP en su versión inicial de 2017 ya lo incluían como una principal amenaza, aunque en el informe final se eliminó:

Exponer una API supone ofrecer una puerta de acceso a los datos y a la propia organización en sí misma, por lo tanto su securización es algo que debería preocupar desde el principio. 

Entonces, ¿porqué se siguen dejando APIs completamente desprotegidas? ¿Sin identificar al llamante, ni limitando el número de peticiones que pueden realizar?

Algunas de las típicas respuestas a estas preguntas son: esta API solo la usamos nosotros no merece la pena protegerla, o si nadie sabe que existe porque no se promociona no la van a encontrar, no vamos a gastar esfuerzos en securizar. Estos argumentos (o mejor dicho excusas) se caen por su propio peso. 

Antes de la llegada de los conceptos de API Product y API First nunca se planteó que los servicios, sobre todo aquellos relacionados con acceso a datos, fueran accesibles desde Internet por aplicaciones fuera de la organización. 

Ahora gran parte de la funcionalidad se encuentra detrás de una API esperando a ser consumida por aplicaciones de una sola página (SPAs), aplicaciones móviles o terceros sobre los que no se tiene control. 

¿Entonces las APIS son inseguras en sí mismas? No, la diferencia es que las APIs son el punto de entrada inicial y la superficie de ataque es mayor debido a la mayor demanda de conectividad B2B. 

Esta demanda ha supuesto exponer vía API funcionalidades que estaban pensadas inicialmente para un consumo interno y en las que no se han implementado todos los controles de seguridad necesarios para un consumo externo. 

Si la securización de las APIs fuera un tema secundario y/o trivial sus vulnerabilidades no producirían tanto daño a las organizaciones tanto a nivel de imagen como a nivel económico.

Esta es la lista de las 10 mayores violaciones de datos durante 2018 en las que se comprometió información de millones de personas por datos mal manejados y agujeros en la seguridad. 

No se sabe con seguridad si todos ellos tienen APIs implicadas, pero en al menos 3 de ellos, marcados en rojo, se tiene la certeza que se produjeron a nivel de API y el impacto económico que supuso para la empresa:

• En el caso de Aadhar no se securizó la API de acceso a base de datos en el sistema de identidades de los ciudadanos, dejando completamente accesible información de residentes en la India incluyendo nombre, número de identificación y cuentas bancarias. 
• En el caso de Facebook los atacantes consiguieron aprovecharse de las vulnerabilidades a nivel de código de la aplicación para hacerse con los access token y tener acceso a información altamente sensible, como datos de contacto y localización de los usuarios.

Debe tenerse presente que los mecanismos de seguridad aplicados en las aplicaciones difieren a los que afectan a nivel de API. Muchos de los posibles ataques son compartidos, pero otros son específicos de esta disciplina. 

Uno de los problemas en el caso de las APIs es que son extremadamente claras proporcionando información de los datos internos, sus estructuras y su negocio.

Además en ocasiones por error y/o desconocimiento se ofrece información sobre la implementación técnica subyacente, es decir, se exponen datos muy valiosos para los atacantes. 

Con este documento lo que se pretende es concienciar sobre la importancia de la securización de las APIs, reflejando en qué consiste esa securización, la identificación de los riesgos más críticos y unas recomendaciones tanto en diseño como implementación para minimizar los daños. 

OWASP

A la hora de securizar APIs, y por extensión cualquier aplicación web, resulta básico conocer el ranking elaborado por OWASP.

OWASP (Open Web Application Security Project) es una fundación cuyo objetivo es canalizar sus esfuerzos en la seguridad de aplicaciones, APIs incluidas,  mediante la identificación a nivel global y de manera colaborativa de los 10 riesgos de seguridad más críticos de la web, conocido como OWASP TOP 10.

El último de sus informes realizado en 2017 compara sus resultados con el informe anterior que realizaron en el año 2013 identificando los cambios que se han producido en ese tiempo.  

Estos cambios residen fundamentalmente en que la tecnología base y la arquitectura de aplicaciones (microservicios, cloud native, etc) ha cambiado significativamente, por lo que los riesgos asociados a ellas también difieren, aunque muchos de ellos se mantienen.

Los cambios a destacar comparando ambos listados son:

• Nuevos riesgos, respaldados en datos: 
  • A4:2017 – Entidades Externas XML (XXE) es una nueva categoría, respaldada principalmente por los resultados obtenidos de las herramientas de análisis estático de código.
• Nuevos riesgos, respaldados por la comunidad: 
  • A8:2017 – Deserialización Insegura, que permite la ejecución remota de código o la manipulación de objetos sensibles en la plataforma afectada. 
  • A10:2017 – Registro y Monitoreo Insuficientes, la falta de estos aspectos puede impedir o demorar en forma significativa la detección de actividad maliciosa o de sustracción de datos, la respuesta a los incidentes y la investigación forense digital.

OWASP, además de identificar los riesgos, los cuantifica siguiendo una metodología mediante la cual atribuyen una graduación de 3 niveles para los siguientes criterios: 

• Dificultad del Ataque (explotabilidad).
• Prevalencia del riesgo.
• Detección del riesgo.
• Impactos técnicos.

El detalle puede verse en el siguiente esquema:

La cuantificación del TOP 10 de vulnerabilidades siguiendo la escala de gravedad anterior y las recomendaciones generales a la hora de implementar APIs y el uso de plataformas para su gestión que nos pueden ayudar a mitigarlos son los siguientes:

A1:2017 – Inyección

Descripción

Los errores causados por inyección (como inyección SQL) se producen cuando datos maliciosos son enviados al servidor y pueden ser interpretados como comandos o consultas que pueden habilitar acciones indeseadas.

Amenazas

Recomendaciones diseño o implementación API

Validar todos los datos: cabeceras, query parameters, path parameters y cuerpos petición/respuesta. La validación debe incluir: validación formato, tipo de datos, valor, longitud y/o rango según aplique.

Recomendación con API Management

Incluir políticas o mediadores para:
– Detectar ataques de inyección SQL y de serialización JSON y XML
– Validar esquema del cuerpo de petición/respuesta contra esquemas estrictos

A2:2017 – Rotura de autenticación

Descripción

Las funciones relacionadas a la autenticación y gestión de sesiones son implementadas incorrectamente, permitiendo a los atacantes comprometer usuarios y contraseñas, token de sesiones, o explotar otros errores de implementación para asumir la identidad de otros usuarios (temporal o permanentemente).

Amenazas

Recomendaciones diseño o implementación API

Es importante utilizar una comunicación segura con two-way SSL y estándares de autenticación y autorización (como OAuth 2.0 y openId Connect).

Recomendación con API Management

Habilitar comunicación two-way SSL y autenticación OAuth 2.0 y openId Connect.

A3:2017 – Exposición de datos sensibles

Descripción

Las APIs no protegen adecuadamente datos sensibles, tales como información financiera, de salud o Información Personalmente Identificable (PII).

Los atacantes pueden robar o modificar estos datos protegidos inadecuadamente para llevar a cabo fraudes con tarjetas de crédito, robos de identidad u otros delitos. Los datos sensibles requieren métodos de protección adicionales, como el cifrado en almacenamiento y tránsito.

Amenazas

Recomendaciones diseño o implementación API

Para prevenir esta vulnerabilidad es posible utilizar ofuscación de datos y de log, criptografía en el canal de comunicación y utilizar Two-way SSL.

Es importante no almacenar datos sensibles si no hay necesidad, y cifrarlos, tanto cuando están en reposo como en tránsito.

Recomendación con API Management

Además de la comunicación con two-way SSL, habilitar ofuscación de datos y logs e incorporar mecanismos de criptografía.

A4:2017 – Entidades externas XML

Descripción

Muchos procesadores XML antiguos o mal configurados evalúan referencias a entidades externas en documentos XML. Las entidades externas pueden utilizarse para revelar archivos internos mediante la URI o archivos internos en servidores no actualizados, escanear puertos de la LAN, ejecutar código de forma remota y realizar ataques de denegación de servicio (DoS).

Amenazas

Recomendaciones diseño o implementación API

Aplicar actualizaciones de las librerías y dependencias de procesadores XML. Verificar los XML de las peticiones mediante validación de entrada con un esquema estricto y deshabilite el procesamiento de XXE y DTD. El uso de WAFs y de API gateway ayudan con la tarea.

Recomendación con API Management

Habilitar dentro de la herramienta los mediadores y políticas que implemente la creación de whitelist, e interceptores para la protección frente a ataques sobre XML y JSON.

A5:2017 – Control de acceso fallido

Descripción

Las restricciones sobre qué pueden hacer los usuarios autenticados no se aplican correctamente.

Los atacantes pueden explotar estos defectos para acceder, de forma no autorizada, a funcionalidades y/o datos, cuentas de otros usuarios, ver archivos sensibles, modificar datos, cambiar derechos de acceso y permisos, etc.

Amenazas

Recomendaciones diseño o implementación API

Utilizar scopes de autorización para garantizar el acceso a los datos a quien solo debe tener acceso. Implementar mecanismos de control de cuota o de peticiones.

Recomendación con API Management

Aplicar autenticación con OAuth 2.0, validación de acceso a los recursos con planes y a cada plan asociar un límite de cuota de consumo por unidad de tiempo.

A6:2017 – Configuración incorrecta de seguridad

Descripción

Los usuarios pueden lograr ejecutar acciones indeseadas por falta de una configuración correcta de seguridad. Son ejemplos: S3 buckets abiertos, cabeceras HTTP mal configuradas, mensajes de error con contenido sensible, falta de parches y actualizaciones, frameworks, dependencias y componentes desactualizados, etc.

Amenazas

Recomendaciones diseño o implementación API

Es importante disponer de entornos debidamente separados y protegidos con control de acceso y autorización en todos los niveles, así como mantenerlos actualizados frente a posibles vulnerabilidades. Para el caso concreto de invocación de APIs hacer uso de OAuth con scopes y gestionando perfiles con sus correspondientes permisos para su gestión.

Recomendación con API Management

Creación y separación de entornos de desarrollo. Hacer uso de distintos perfiles para configurar los permisos sobre todo de publicación y modificación de APIs. Usar OAuth 2.0, creación y revocación de tokens, gestión centralizada y auditoría de eventos.

A7:2017 – Cross-Site Scripting (XSS)

Descripción

En el ataque XSS consisten en agregar scripts antes que se envíen y se ejecuten para obtener datos de sesiones, redirigir a sitios maliciosos o desfigurar páginas.

Amenazas

Recomendaciones diseño o implementación API

Se debe validar que las peticiones y las respuestas no contengan scripts.

Recomendación con API Management

Aplicar las políticas y mediadores cuya funcionalidad es protegernos frente a ataques XSS que permiten identificar y verificar la presencia de patrones maliciosos.

A8:2017 – Deserialización Insegura

Descripción

Estos ataques se deben a que se permite la recepción de objetos serializados adulterados sin dar un error de forma que estos objetos pueden ser manipulados por el atacante para realizar ataques de repetición, inyecciones o elevar sus privilegios de ejecución. En el peor de los casos, la deserialización insegura puede conducir a la ejecución remota de código en el servidor.

Amenazas

Recomendaciones diseño o implementación API

No aceptar objetos serializados a partir de fuentes no confiables o permitir solo serialización que permita tipos de datos primitivos. Si eso no fuera posible, implementar verificaciones de integridad o criptografía de los objetos serializados para evitar la creación hostil de objetos o adulteración de datos. Es importante almacenar en los logs las excepciones y fallas de deserialización. Restrinja o monitoree la conectividad de entrada y de salida y configure alertas para detectar problemas con la serialización.

Recomendación con API Management

Definición de white lists para fuentes confiables, crear logs específicos para cada etapa de la operación de las APIs, realizar traceo de las peticiones y configurar alertas.

A9:2017 – Utilización de Componentes con Vulnerabilidades Conocidas

Descripción

El atacante puede identificar componentes vulnerables por medio de scanning o análisis manual. Las APIs que utilizan componentes con vulnerabilidades conocidas pueden debilitar las defensas de las aplicaciones y permitir diversos ataques e impactos.

Amenazas

Recomendaciones diseño o implementación API

Usar herramientas para inventariar las versiones y dependencias de los componentes (server-side y client-side). Monitorizar vulnerabilidades en componentes a partir de fuentes públicas y usar software para análisis automático de versiones, dependencias y vulnerabilidades. También, es importante desactivar los componentes que no se utilicen, y aplicar actualizaciones y parches para prevenir vulnerabilidades que puedan ser explotadas.

Recomendación con API Management

Hasta la eliminación de la dependencia se puede censar el volumen de tráfico asociado a ella para tenerlo controlado mediante políticas que aplican condiciones comparativas en las url para identificar llamadas a URLs con vulnerabilidades conocidas y validarlas.

A10:2017 – Logging y Monitoreo Insuficientes

Descripción

Registrar inadecuadamente los errores, la falta de alertas cuando se produce un error y de bloqueos ante peticiones erróneas, permiten que el atacante mantenga el ataque en el ataque en el tiempo, pivotar a otros sistemas y manipular, extraer o destruir datos, básicamente explota el sistema hasta conseguir que una vulnerabilidad sea explotable.

Amenazas

Recomendaciones diseño o implementación API

Identificar todos los posibles errores en el flujo de implementación de la API y registrarlo en los logs en caso de que se produzcan así como enviar información clara del error pero sin el detalle técnico y entorno del problema producido al consumidor de la API.

Recomendación con API Management

Habilitar políticas y mediadores que permitan monitorizar las peticiones y respuestas en los logs en todas las etapas de las APIs y la configuración de alertas y dashboards personalizados.

Hay que aclarar que esos niveles de criticidad son una generalización y pueden variar dentro de cada tipo de organización.

Por ejemplo, el uso de un sistema de gestión de contenido (CMS) para un blog, no es lo mismo que el uso de ese mismo sistema de gestión de contenido en un organismo de la administración pública del sistema de salud cuyos datos sensibles son primordiales.

Vulnerabilidades

Mediante OWASP se identifican las vulnerabilidades más críticas, pero para mitigarlas se debe conocer cada una de ellas más a fondo. Todas las vulnerabilidades pueden categorizarse dentro de los siguientes vectores de ataque:

Parámetros: 

En este tipo de vulnerabilidades los atacantes explotan los atributos enviados en una API tanto en la URL, como en el cuerpo de la petición/respuesta, como en las cabeceras HTTP. 

Entre los ataques a nivel de parámetros, los más habituales y peligrosos son los de inyección. Estos ataques se deben fundamentalmente a que en desarrollo no se comprueba cuidadosamente las datos de entrada en la aplicación. 

Además, en el caso de las APIs, se agrava ya que solo con el nombre del campo es posible identificar de manera subyacente a qué se refiere esa información ofreciendo pistas tentadoras para el atacante. 

Otros problemas derivados de los parámetros expuestos en la API son los datos sensibles de manera abierta y los identificadores utilizados en las URL. 

A la hora de diseñar cualquier API debe tenerse presente que las URL y los parámetros de consulta no son seguros. Nunca deben contener información sensible o importante ya que son susceptibles de generar problemas de seguridad sobre todo debido a spyware dentro de los navegadores. 

Los motivos por los que no es seguro exponer información sensible en las urls son los siguientes:

• Se guardan en el historial del navegador lo cual implica que un software malicioso puede acceder a dicho historial para extraer tokens y contraseñas. 
• Se almacenan en memoria y en el servidor de logs de la aplicación. 
• La gente puede compartir/almacenar el link sin darse cuenta de la información que en realidad está compartiendo a un tercero o simplemente por equivocación dejando abierto la información contenida en el link.
• Esa información puede ir dentro de la cabecera «referrer». Desde el punto de vista de una API no es una incidencia importante, pero en el momento en el que una llamada acceda a otro dominio distinto si en la petición va la url anterior no se sabe lo que el nuevo dominio puede hacer con esa información.
• Es información disponible en extensiones del navegador. Las extensiones del navegador pueden ver cualquier query param de cualquier página si el usuario les da permiso.

Autenticación/autorización: 

En este caso los atacantes explotan los flujos de autenticacion y autorizacion así como los datos almacenados en sesión. 

La identidad del usuario es una idea con la que todos estamos familiarizados, pero en el caso de las APIs introducen otro concepto como es la identidad de la aplicación, cuya identificación está asociada a unos credenciales y en muchos casos a una API Key. 

Esa API Key se utiliza como una credencial autorizada, uso completamente erróneo y desvirtualizado, además se tiende a almacenar dicha información en el propio código resultando relativamente sencillo de encontrar y por tanto de usurpar.

Transporte:

A nivel de transporte se tienen diferentes tipos de ataque:

• Man-in-the-middle. 

Estos ataques interceptan peticiones legítimas y explotan los datos sin firmar y/o sin cifrar entre cliente y servidor. Pueden acceder a información confidencial, alterar transacciones al vuelo o replicar incluso peticiones legítimas. 

Todas aquellas APIs que no están configuradas correctamente usando SSL/TLS son altamente vulnerables a esta forma de ataque. 

Desafortunadamente, debido a problemas de escalado y tiempos de respuesta, históricamente se ha intentado evitar su uso e incluso cuando se aplica SSL/TLS se encuentra mal configurado y vulnerable a ciertos ataques que lo convierten en un medida de seguridad poco efectiva. 

La protección a nivel de transporte en las APIs resulta esencial para asegurar tanto los datos como el acceso a la funcionalidad.

• Denegación de servicio: 

Los ataques de denegación de servicio son un ejemplo claro en el que los mecanismos tradicionales de seguridad no bastan ya que limitando el número de peticiones no es suficiente. En estos ataques varias direcciones IP, es decir, varios clientes pueden atacar a la API a la vez, por lo que políticas de control de throttling que solo funcionan a nivel de IP no son válidas. 

Prevenir un ataque en el que las peticiones proceden de diferentes clientes es un problema mucho más complicado de resolver. 

También debe tenerse en cuenta la reutilización y la gestión de dependencias, ya que es posible que un mismo microservicio y la API expuesta a través de él se utilice en varios aplicativos. Y si a su vez tiene múltiples dependencias subyacentes que no se controlan pueden llegar a colapsar esos backend con unas pocas peticiones a nivel de la API.

Muchos ataques en la red se deben a estos problemas, pero conceptos como: aplicaciones que mantienen conexiones abiertas que ralentizan la aplicación y ataques en el inicio de sesión con continuos accesos, ya sean erróneos o no, son problemas típicos que hay que tener presentes.

Principios fundamentales

A la hora de diseñar e implementar una API los principios básicos que se deben tener en mente para evitar dolores de cabeza posteriores a nivel de seguridad son los siguientes:

• Asumir que todos quieren los datos. Es vital ponerse en la piel de una persona externa o atacante para evitar e identificar posibles accesos conflictivos. A menudo existe la tentación de crear la API lo más rápido posible e implementarla casi de inmediato obviando este principio.
• Conocer la funcionalidad de las APIs teniendo claro qué datos exponen y el grado de sensibilidad de los mismos. Un ejemplo es el de Open Banking UK que categoriza las APIs de la siguiente forma:

Es fundamental comprender quién necesita acceso a qué. Muchos problemas de seguridad de las API se deben por dejar de considerar estos diferentes niveles de acceso. 

Por ejemplo, en un hotel a cada cliente se le otorga acceso solo a su habitación  no a la a de otros huéspedes, los desarrolladores debemos pensar en el acceso a la API de la misma manera, controlando el acceso a la información en un grano fino. 

• Validar las peticiones a todos lo niveles: cabeceras, url, parámetros de consulta, cuerpo de la petición verificando su estructura y el formato tanto en cabecera como en cuerpo. Limpiar aquello que no sea estrictamente necesario evitando exponer cualquier dato sensible.
• Aplicar autenticación y autorización de manera rigurosa y con soluciones probadas. Esto implica:
  • Usar Oauth apropiadamente, los grant type adecuados para cada caso y no para autenticar usuarios. Validar los JWT a nivel de protocolo con firma y claims.
  • Autorizar a nivel de grado fino sabiendo quién está invocando y quién puede acceder a que mediante scopes y control de autorización.
• Aplicar detección de amenazas de manera explícita y reactiva: testear las APIs en busca de vulnerabilidades desde el primer momento para remediar el daño antes de que se produzca desde lo más básico mediante análisis manual y el uso de librerías confiables, hasta escaneos.
• Securizar todas las APIs sea cual sea su propósito e incluye en la arquitectura del proyecto herramientas como gateways, waf, hacer uso de control de tráfico y estableciendo cuotas para evitar denegación de servicio.
• Monitorizar las APIs para disponer de una trazabilidad end-to-end y analizar su comportamiento para identificar en tiempo de ejecución posibles incidencias y vulnerabilidades.

Las APIs se han convertido en una gran oportunidad para que las empresas integren aplicaciones de una manera rápida y sencilla, pero pueden ser un arma de doble filo. 

Su talón de Aquiles reside en la exposición de datos de una manera rápida y ágil a la vez que aumenta el riesgo por esa exposición si no se puede foco en su securización.

Los primeros pasos para abordar este desafío son:

• Comprender los tipos de errores y vulnerabilidades que se pueden explotar de manera malintencionada.
• Tener presentes en el momento del diseño e implementación algunos principios básicos que nos ayuden a mitigar esas vulnerabilidades. 
• Abordar la securización lo antes posible, ya que las APIs no son intrínsecamente inseguras pero sí son un vector de ataque importante.