¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
dev
Noelia Martín Hace 1 año Cargando comentarios…
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.
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:
Agente de amenaza
Específico de la aplicación
Explotabilidad
Fácil
Media
Difícil
Prevalencia de la vulnerabilidad
Generalizada
Común
Poco común
Detección de la vulnerabilidad
Fácil
Media
Difícil
Impacto técnico
Severo
Moderado
Mínimo
Impacto de negocio
Específico del negocio
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:
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
Dificultad del ataque
Fácil
Prevalencia del riesgo
Común
Detección del riesgo
Fácil
Impacto técnico
Severo
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
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
Dificultad del ataque
Fácil
Prevalencia del riesgo
Común
Detección del riesgo
Media
Impacto técnico
Severo
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.
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
Dificultad del ataque
Media
Prevalencia del riesgo
Generalizada
Detección del riesgo
Media
Impacto técnico
Severo
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.
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
Dificultad del ataque
Media
Prevalencia del riesgo
Común
Detección del riesgo
Fácil
Impacto técnico
Severo
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.
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
Dificultad del ataque
Media
Prevalencia del riesgo
Común
Detección del riesgo
Media
Impacto técnico
Severo
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.
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
Dificultad del ataque
Fácil
Prevalencia del riesgo
Generalizada
Detección del riesgo
Fácil
Impacto técnico
Moderado
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.
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
Dificultad del ataque
Fácil
Prevalencia del riesgo
Generalizada
Detección del riesgo
Fácil
Impacto técnico
Moderado
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.
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
Dificultad del ataque
Dificil
Prevalencia del riesgo
Común
Detección del riesgo
Media
Impacto técnico
Severo
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.
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
Dificultad del ataque
Media
Prevalencia del riesgo
Generalizada
Detección del riesgo
Media
Impacto técnico
Moderado
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.
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
Dificultad del ataque
Media
Prevalencia del riesgo
Generalizada
Detección del riesgo
Dificil
Impacto técnico
Moderado
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.
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:
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:
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.
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.
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:
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.
Tecnología, personas e impacto positivo.
Cuéntanos qué te parece.