Seguridad en tus APIs: ¿a qué vulnerabilidades se pueden enfrentar tus APIs?

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

A2:2017 - Rotura de autenticación

A3:2017 - Exposición de datos sensibles

A4:2017 - Entidades externas XML

A5:2017 - Control de acceso fallido

A6:2017 - Configuración incorrecta de seguridad

A7:2017 – Cross-Site Scripting (XSS)

A8:2017 – Deserialización Insegura

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

A10:2017 – Logging y Monitoreo Insuficientes

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.