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:

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:

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:

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:

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:

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.

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:

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.

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:

Cuéntanos qué te parece.

Enviar.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.

Suscríbete

Estamos comprometidos.

Tecnología, personas e impacto positivo.