Las 10 amenazas principales de la API de OWASP

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

En este documento, se describen varios enfoques que puedes usar en Apigee para abordar las vulnerabilidades de seguridad identificadas por OWASP. Para conocer otros enfoques documentados para Apigee, consulta las opciones de mitigación de OWASP Top 10 2021 en Google Cloud.

Introducción

OWASP es una comunidad abierta dedicada a ayudar a las organizaciones a desarrollar, comprar y mantener aplicaciones y APIs confiables. A través del proyecto OWASP API Security, OWASP publica los riesgos de seguridad más críticos para las aplicaciones web y las APIs de REST, y proporciona recomendaciones para abordar esos riesgos.

En este documento, se analizarán los enfoques para protegerse contra los ataques comunes basados en APIs, según se identificaron en las diez principales amenazas de seguridad de APIs de OWASP en 2019. Un tema común en las principales amenazas destacadas en la lista más reciente es que se deben a la ubicación inadecuada de los controles de autenticación y autorización, como la dependencia del filtrado de los datos que devuelve una solicitud de API dentro de las apps cliente, mediante el uso del antipatrón de depender de la app cliente que consume para aplicar el control de acceso.

Dado que el ecosistema de APIs sigue creciendo a un ritmo acelerado, lamentablemente, los abusos y usos inadecuados de las APIs que provocan la filtración de datos por parte de los atacantes se están convirtiendo en uno de los vectores de ataque más comunes en la actualidad. La seguridad sigue siendo una prioridad clave para Apigee, con varias funciones nuevas, como Advanced API Ops, que incluye funciones de detección de anomalías. Sin embargo, diseñar e implementar correctamente las funciones de seguridad de Apigee es fundamental para reducir la probabilidad de ataques exitosos a tus APIs.

Las aplicaciones para el consumidor deben considerarse no confiables o “públicas”, ya que no controlas la plataforma en la que se ejecuta la app. Supón que cualquier app pública puede verse comprometida y lo hará. Por lo tanto, no se puede confiar en que aplique el control de acceso (API1, API5), filtre los datos de respuesta (API6) o almacene de forma segura los secretos del cliente (API2), como las claves de API o los tokens de acceso. Algunas recomendaciones surgen del análisis de las 10 principales vulnerabilidades de OWASP en 2019:

  • Determina qué tipo de apps cliente consumirán tus APIs (SPA, para dispositivos móviles o basadas en el navegador) y diseña los patrones de autenticación, autorización y seguridad adecuados.
  • Siempre usa flujos de OAuth o OpenID Connect de "cliente público" (se recomienda el uso de PKCE).
  • Piensa en la lógica empresarial de tu app, define primero tu especificación de OpenAPI y diseña tus proxies de API para filtrar todos los datos de respuesta del backend en Apigee. Nunca confíes en la lógica del código de la app descendente para realizar esta acción.
  • Filtra todas las solicitudes de datos que contengan PII específica del usuario para permitir solo los datos de tu backend que pertenezcan al usuario solicitante.

API1:2019 Autorización a nivel de objeto interrumpida

Descripción de la amenaza

La validación insuficiente de la autorización de una solicitud de acceso a un objeto permite que un atacante realice una acción no autorizada reutilizando un token de acceso. Esta amenaza se debe a una configuración inadecuada de las validaciones de autorización. Apigee proporciona políticas de VerifyApiKey, OAuth y JSON Web Token (JWT) que ayudan a proteger contra esta vulnerabilidad. Sin embargo, es fundamental que estas políticas estén configuradas correctamente para evitar esta amenaza.

Para evitar esta amenaza, es importante que los equipos de desarrollo y seguridad de aplicaciones colaboren estrechamente. La autorización es, por naturaleza, un tema complejo, y la autorización detallada eficaz requiere un conocimiento profundo de la lógica empresarial de la aplicación.

Desde la perspectiva de la implementación de Apigee, hay dos aspectos principales que se deben tener en cuenta:

  • Integridad del token de acceso
  • Aplicación del control de acceso

Integridad del token de acceso

Es fundamental validar que el token proporcionado por el cliente solicitante no se haya manipulado. Para ello, usa el flujo correcto de OAuth o OpenID Connect junto con el mecanismo de firma o validación de credenciales adecuado. Apigee admite todos los flujos de OAuth de uso frecuente.

Las políticas de verificación de tokens de acceso de Apigee incluyen lo siguiente:

Aplicación del control de acceso

Una vez que se verifica la validez del token de acceso, es fundamental implementar políticas de aplicación del control de acceso para evaluar cada solicitud a la API entrante en función de los derechos de acceso del token de autorización.

Apigee proporciona dos mecanismos principales para verificar y aplicar políticas de autorización:

  • Interno: Se usan flujos condicionales para evaluar las solicitudes de acceso según las declaraciones extraídas como variables de flujo de un token de autorización.
  • Delegado: Se usa una llamada de servicio a una solución de administración de acceso de terceros.

Se recomienda el enfoque interno (ilustrado en la figura anterior) cuando el modelo de control de acceso es relativamente sencillo. Por ejemplo, si los reclamos extraídos de un token de acceso se pueden usar para evaluar y autorizar directamente una solicitud de objeto de API.

Usa las variables de flujo disponibles para las políticas de OAuth o JWT para evaluar las solicitudes de acceso con instrucciones de flujo condicionales.

Se recomienda el enfoque delegado (ilustrado en la figura anterior) cuando las declaraciones extraídas de un token de acceso no se pueden usar directamente para autorizar una solicitud a la API a un objeto de backend o para tipos de flujo de OAuth más complejos que requieren una llamada independiente a un servidor de autorización para obtener un token de acceso.

Con la política de llamada de servicio, es posible solicitar una decisión basada en políticas de autorización a un servicio externo o bien obtener información adicional sobre la declaración del agente solicitante para luego tomar una decisión de control de acceso con un flujo condicional.

API2:2019, Autenticación de usuarios dañada

Descripción de la amenaza

Las políticas de autenticación de usuarios mal implementadas permiten que los atacantes se hagan pasar por usuarios legítimos aprovechando las fallas de implementación en las implementaciones de autenticación. Estos son algunos principios de autenticación que debes tener en cuenta cuando implementes enfoques de autenticación:

  • Siempre autentica el usuario-agente (la app) y el usuario solicitante.
  • Usa patrones de autenticación y autorización delegados, y evita pasar contraseñas directamente en una solicitud a la API.
  • Siempre valida la firma de las credenciales de acceso y asegúrate de que todas las credenciales de acceso que se usen tengan un tiempo de vencimiento definido.
  • Evita los ataques de fuerza bruta estableciendo cuotas y usando Apigee Sense para detectar y responder a los ataques de fuerza bruta basados en bots.

Según un paradigma de afuera hacia adentro, el diseño de la API se basa en los casos de uso de los consumidores para los datos, en lugar de la estructura de los datos existentes en tus sistemas de backend, y la seguridad es un elemento fundamental cuando se diseñan APIs para consumidores externos. Tradicionalmente, los sistemas de backend no se compilan con implementaciones de autenticación lo suficientemente sólidas para la exposición a redes públicas. Aquí es donde Apigee, junto con una solución de administración de identidades y accesos, puede ofrecer soluciones sólidas para protegerse contra esta amenaza.

Aquí hay algunos elementos importantes que se deben tener en cuenta, y que se abordarán en las secciones posteriores:

  • Diseño de seguridad: Aprovechar al máximo las funciones de Apigee para implementar patrones de autenticación
  • Administración: Garantizar que se utilicen de forma coherente los patrones de autenticación diseñados en todos los productos de API publicados
  • Seguridad operativa: Capacidad de detectar comportamientos sospechosos o anómalos, así como intentos de eludir o forzar proxies de API autenticados

Diseño de seguridad

El objetivo del diseño de seguridad es implementar correctamente los flujos de autenticación y la integración con herramientas de identidad de terceros. El diseño de seguridad es una fase fundamental que comienza con la comprensión del tipo correcto de flujo de autenticación delegada que se debe usar según el tipo de app que consumirá tus extremos de API. El siguiente paso es definir, junto con tu equipo de identidad, los patrones de integración que se implementarán con tu solución de identidad.

Los RFC de OpenID Connect y OAuth proporcionan una gran cantidad de flujos de autenticación y autorización delegados, así como los actores involucrados en estos flujos. Este es un tema complejo, y no sorprende que la autenticación interrumpida sea una de las principales amenazas de la API de OWASP. Proporcionar una introducción integral sobre la implementación correcta de los estándares de identidad está fuera del alcance de este documento. Sin embargo, Apigee tiene muchos recursos adicionales para comprender mejor los flujos de OAuth, como este libro electrónico, este seminario web y esta implementación de ejemplo.

Políticas de autenticación

Las políticas de Apigee que ayudan a abordar las inquietudes sobre la identidad y la autenticación incluyen las siguientes:

Administración de tráfico

Las siguientes funciones de administración del tráfico de Apigee ayudan a proteger contra ataques de fuerza bruta:

  • La política de SpikeArrest, para establecer un límite de frecuencia general de promedio móvil en un proxy de API
  • Políticas de cuotas para establecer límites de frecuencia detallados en los proxies de API según las cuotas definidas por las claves de API, los desarrolladores o las cuotas de productos de API
  • Políticas de almacenamiento en caché, para el almacenamiento en caché de tokens de acceso almacenados según sus tiempos de vencimiento definidos, así como la capacidad de invalidar credenciales almacenadas en caché (por ejemplo, en una situación en la que se vulnera un token de acceso válido)

Administración

La seguridad es un proceso continuo, no un proyecto de “configurar y olvidar”, y una de las principales causas de las violaciones de seguridad son los parámetros de configuración incorrectos. Una vez que se definen los flujos de autenticación, los patrones de integración de identidad y las políticas de administración del tráfico relacionadas con la autenticación, es fundamental que se implementen de forma correcta y coherente.

Apigee proporciona varias funciones y herramientas para garantizar la integridad de la implementación y evitar errores de configuración.

Control de acceso basado en roles (RBAC)

Ya sea que tengas una gran empresa o una pequeña startup, para evitar errores de configuración, primero debes asegurarte de que solo las personas y los equipos adecuados puedan acceder a las configuraciones del proxy de API y modificarlas. Los programas de API cuentan con el respaldo de equipos multidisciplinarios en toda tu organización. Es absolutamente esencial que a cada equipo solo se le otorguen los permisos necesarios para que realicen su trabajo como parte de tu recorrido por la API.

Apigee te proporciona las funciones para administrar el acceso basado en roles, ya que te brinda las capacidades para asignar usuarios a roles predefinidos o crear roles personalizados que se adapten a tus equipos de API. Definir y administrar correctamente la asignación de roles es fundamental para que puedas escalar tu programa de APIs de forma segura. También puedes usar la federación para integrarte con tu directorio corporativo existente y reducir la necesidad de administrar un segundo conjunto de credenciales de administrador en Apigee.

Flujos compartidos

Los flujos compartidos te permiten definir políticas y recursos en un objeto reutilizable que se puede implementar en todos los proxies de API. Por ejemplo, es posible que hayas diseñado de forma colaborativa con tus equipos de seguridad varios patrones de diseño de autenticación según el tipo de app que consume una API. Un desarrollador de APIs no necesita ser un experto en identidades para reutilizar esto, sino que simplemente debe conocer el flujo compartido correcto para agregar a la configuración existente del proxy de API con la política de llamada de flujo.

Figura: Los flujos compartidos son paquetes reutilizables de políticas y lógica condicional que te permiten mantener un patrón compuesto.

Seguridad operacional

Una vez que tus APIs estén en producción y utilicen los patrones de autenticación correctos con la administración del tráfico de referencia implementada, tu equipo de SecOps también debe poder supervisar y responder a la actividad sospechosa, que a menudo comienza con intentos de vulnerar las credenciales de autenticación.

Apigee Sense

Apigee Sense protege tus APIs del tráfico de solicitudes no deseadas, incluidos los ataques de clientes maliciosos. Apigee Sense analiza el tráfico de solicitudes a la API y, luego, identifica patrones que podrían representar solicitudes no deseadas. Con este análisis, puedes identificar a los clientes que realizan solicitudes no deseadas y, luego, tomar medidas para permitir, bloquear o marcar esas solicitudes. Las funciones futuras de Sense incluirán la capacidad de habilitar automáticamente la verificación de reCAPTCHA en el tráfico sospechoso.

Con Apigee Sense, puedes proteger tus APIs de patrones de solicitudes que incluyen lo siguiente:

  • Comportamiento automatizado que se combina con el comportamiento humano
  • Intentos persistentes desde la misma IP
  • Tasas de error inusuales
  • Solicitudes sospechosas del cliente
  • Rastreo de datos
  • Ataques de fuerza bruta para la autenticación y la recopilación de claves
  • Ráfagas de actividad
  • Patrones geográficos

Operaciones avanzadas de API

Si bien Sense se diseñó específicamente para detectar amenazas similares a las de los bots y responder a ellas, Advanced API Ops incluye la detección de anomalías y la definición de alertas avanzadas.

La detección de anomalías funciona aplicando modelos de inteligencia artificial (IA) y aprendizaje automático (AA) a tus datos históricos de la API. La detección de anomalías puede generar alertas en tiempo real para situaciones en las que ni siquiera habías pensado, lo que te permite mejorar tu productividad y reducir el tiempo promedio de resolución (MTTR) de los problemas de la API.

Las operaciones avanzadas de la API se basan en el mecanismo de alertas existente de la supervisión de API para agregar los siguientes tipos de alertas avanzadas:

  • Alertas de anomalías Edge detecta problemas de tráfico y rendimiento en lugar de que tengas que predeterminarlos por tu cuenta. Luego, puedes generar una alerta para estas anomalías.
  • Alertas de vencimiento de TLS Genera una notificación cuando un certificado TLS está por vencer

API3:2019 Exposición excesiva de datos

Descripción de la amenaza

Una API publicada podría exponer más datos de los necesarios, y depender de la app cliente para realizar el filtrado necesario. Si un atacante consulta directamente la API subyacente, puede acceder a datos sensibles.

Uno de los principios de diseño “de afuera hacia adentro” de Apigee para el diseño de APIs es la parquedad de datos. Trabaja con tus diseñadores y desarrolladores de UX para exponer datos solo a través de las APIs que se necesiten en la IU de tu app. Los sistemas de backend no se crearon para patrones de uso públicos, por lo que una de las primeras tareas del diseño centrado en las APIs con Apigee es reducir los datos expuestos al mínimo necesario para proporcionar un excelente producto de API a tus clientes y desarrolladores.

Otro de los principios de diseño de Apigee es la reutilización. Dejando de lado las preocupaciones de seguridad, depender de una app para filtrar los datos proporcionados por una API requiere portar esa lógica de filtrado a cada plataforma para la que desarrolles una app.

Desde una perspectiva de seguridad, esta amenaza surge de delegar la aplicación de la autorización a una app, a menudo en una plataforma o SO sobre los que no tienes control. Ya analizamos en API1 y API2 la importancia de implementar correctamente la autenticación y la autorización para evitar el acceso no autorizado a los datos.

En las siguientes secciones, se analiza cómo hacer lo siguiente:

  • Reescribe las solicitudes y respuestas a los servicios de backend para minimizar la exposición de datos
  • Implementa el control de errores para evitar que los mensajes de error detallados expongan información sensible del entorno a los atacantes sobre tus servicios de backend.

Reescribir respuestas y solicitudes

Por lo general, los sistemas de backend no están diseñados para usarse en apps públicas ni en redes públicas no confiables. Apigee Edge se diseñó para permitirte implementar productos de API públicos protegiendo tus backends de la exposición excesiva de datos.

Para ello, Apigee usa tres políticas clave:

  • Assign Message
  • Textos destacados de código
  • Manejo de fallas

Política de AssignMessage

La política Assign Message cambia o crea mensajes de solicitud y respuesta nuevos durante el flujo del proxy de API. La política te permite realizar las siguientes acciones en esos mensajes:

  • Agregar nuevos parámetros de formulario, encabezados o parámetros de búsqueda a un mensaje
  • Copiar las propiedades existentes de un mensaje a otro
  • Quitar encabezados, parámetros de búsqueda, parámetros de formulario o cargas útiles de mensajes de un mensaje
  • Establecer el valor de las propiedades existentes en un mensaje

Con Assign Message, sueles agregar, cambiar o quitar propiedades de la solicitud o la respuesta. Sin embargo, también puedes usar Assign Message para crear una solicitud personalizada o un mensaje de respuesta y pasarlo a un destino alternativo, como se describe en Crea mensajes de solicitud personalizados.

Reescritura compleja con código personalizado

Para el manejo de datos complejos y las reglas de reescritura cuya complejidad supera la capacidad de la política Assign message, puedes usar lenguajes de procedimiento como JavaScript, Java o Python. Puedes agregar código personalizado a un proxy de API y, luego, llamarlo desde las políticas agregadas al flujo del proxy. La compatibilidad con el código de procedimiento está diseñada para que te resulte más fácil implementar el control complejo de las variables de flujo, las fallas y los cuerpos de solicitud y respuesta.

Con el código de procedimiento, puedes hacer lo siguiente:

  • Crear o manipular valores de cuerpo complejos, como valores de solicitud y respuesta
  • Volver a escribir las URL, como para enmascarar una URL de extremo de destino

Apigee Edge incluye una política independiente para los lenguajes compatibles: política de JavaScript, política de JavaCallout y política de PythonScript.

Manejo de fallas

Apigee te permite realizar un manejo de excepciones personalizado con una política de tipo Raise Fault. La política Raise Fault, que es una variación de la política Assign Message, te permite generar una respuesta de falla personalizada en respuesta a una condición de error.

Flujos compartidos

Los flujos compartidos se pueden usar para aplicar la estandarización de los mensajes de error. Por ejemplo, las mismas políticas configuradas que detectan un código de error HTTP específico del backend se pueden usar para reescribir la respuesta de error y mostrar un mensaje de error genérico.

API4:2019 Falta de recursos y limitación de frecuencia

Descripción de la amenaza

Si no se implementan políticas de limitación de frecuencia, los atacantes pueden sobrecargar el backend con ataques de denegación de servicio.

Esta amenaza se puede abordar fácilmente con las siguientes funciones de Apigee:

  • Políticas de cuotas y SpikeArrest como controles preventivos para establecer límites de tráfico en las solicitudes a la API entrantes
  • Apigee Sense para detectar y responder de forma dinámica a los ataques basados en bots
  • Supervisión y alertas avanzadas de API como controles de detección para recibir alertas sobre ataques DDoS en curso

Límite de frecuencia con políticas de cuotas y Spike Arrest

Apigee proporciona dos políticas para la limitación de frecuencia:

  • Spike arrest proporciona una política general, definida a nivel del proxy de API, para limitar la frecuencia de la cantidad total de solicitudes entrantes a un backend.
  • Las cuotas proporcionan una herramienta de política detallada para aplicar políticas de cuotas, ya sea a nivel de un proxy de API o de un producto de API.

SpikeArrest

La política SpikeArrest protege contra los aumentos repentinos de tráfico. Esta política regula la cantidad de solicitudes que procesa un proxy de API y se envía a un backend, lo que protege contra los retrasos de rendimiento y el tiempo de inactividad, con un valor de promedio móvil que se puede definir dentro de la política.

Cuotas

La política de Quota permite configurar la cantidad de mensajes de solicitud que un proxy de API permite durante un período, como un minuto, una hora, un día, una semana o un mes. Puedes configurar la cuota para que sea la misma para todas las apps que acceden al proxy de API. También puedes configurar la cuota en función de lo siguiente:

  • El producto que contiene el proxy de API
  • La app que solicita la API
  • El programador de apps
  • Muchos otros criterios

Esta política es más detallada que SpikeArrest y, por lo general, se debe usar de forma simultánea con ella.

Detección de bots con Apigee Sense

Con Apigee Sense, puedes tomar medidas para permitir, bloquear o marcar explícitamente solicitudes de clientes, rangos de IP o organizaciones de sistemas autónomos específicos, según si esos clientes o ubicaciones muestran un comportamiento malicioso o sospechoso. Apigee Edge aplica estas acciones a las solicitudes antes de que los proxies de API las procesen. Por ejemplo, se puede detectar un rango de IP o un cliente específico que exhiba un comportamiento de "adivinador de fuerza bruta", y luego bloquearlo o marcarlo.

Detección de amenazas con la supervisión avanzada de operaciones de la API

Usa una alerta de tráfico para generar una notificación cuando el tráfico de un entorno, un proxy o una región cambie en un porcentaje especificado durante un período. Esta función puede generar una alerta de forma dinámica cuando el tráfico se desvía significativamente de la capacidad de procesamiento esperada, como sucedería durante un ataque DDoS. Estas alertas se pueden enviar fácilmente a una solución de supervisión y registro de terceros.

API5:2019, Autorización a nivel de la función vulnerada

Descripción de la amenaza

Esta amenaza es una variación de API1 y también es una vulnerabilidad de autorización. Con esta amenaza, un atacante puede realizar acciones enviando solicitudes a funciones a las que no tiene autorización para acceder. Por ejemplo, un atacante podría modificar o borrar datos que solo está autorizado a leer si un endpoint de API no valida el verbo de la solicitud HTTP, reemplazando un GET por un PUT o DELETE. O bien, si no se implementa un control de acceso suficientemente restrictivo en la ruta de URI de un recurso de API, un endpoint de API podría permitir que un atacante vea los datos de otro usuario simplemente cambiando la ruta en una solicitud.

Este tipo de amenaza destaca el valor de usar Apigee como una capa de mediación y abstracción, ya que muchos sistemas de backend, que no están diseñados para el acceso público, pueden proporcionar de forma predeterminada un solo extremo para ejecutar múltiples funciones de lógica empresarial, incluida la funcionalidad administrativa de alto riesgo.

Por lo general, los elementos conceptuales para reducir la probabilidad de esta amenaza se dividen en los siguientes:

  • ¿Qué se protege? Piensa en tu estrategia de productos de API y, luego, implementa una segmentación lógica de la funcionalidad cuando uses las prácticas recomendadas de RESTful para diseñar las rutas y los recursos que exponen los proxies de API, los productos y las funciones de las apps de Apigee.
  • ¿Quién accede a tus recursos de API? Define los arquetipos de alto nivel y, luego, implementa los derechos de acceso predeterminados con el principio de "privilegio mínimo" usando algunas de las funciones de autenticación y autorización de Apigee, como se describe en API1 y API2.
  • ¿Cómo se aplican tus políticas de acceso? Usa flujos y errores condicionales para validar la ruta de URL y el verbo de todas las solicitudes a la API.

Figura: En este diagrama, se muestra cómo se aplicaría la autorización a nivel de la función en Apigee, con los alcances proporcionados dentro de un token de acceso como derechos.

Segmentación lógica con proxies, productos y apps de API

Apigee proporciona un kit de herramientas muy flexible para permitir la segmentación lógica de los recursos de la API, lo que permite que los proxies de API se agrupen en cualquier cantidad de productos de API, que a su vez son consumidos por los desarrolladores de tu app, quienes pueden registrar apps que utilizan tus productos de API. Las políticas de acceso se pueden definir en cualquiera de estos niveles.

Sin embargo, para implementar una autorización y segmentación funcionales eficaces, es fundamental definir una estrategia de productos de API. Parte de este proceso esencial y continuo es la definición del "quién" y el "qué" de tus productos de API, analizando los recursos de la API desde la perspectiva de tus clientes y desarrolladores, y luego definiendo, hasta el nivel de verbo HTTP y recurso de ruta, exactamente qué tipos de solicitudes se permitirán.

Figura: Los recursos de API incluidos en un producto de API pueden provenir de una o más APIs, por lo que puedes combinar recursos para crear niveles de consumo y límites de autorización.

Control de acceso a nivel de función con alcances de OAuth y reclamos de JWT

Si bien los enfoques de autorización considerados anteriormente para API1:2019 Autorización de objetos interrumpida abordan el control de acceso detallado a nivel del objeto, es igual de importante abordar el control de acceso general a nivel de la función. ¿El usuario solicitante tiene permiso para solicitar esta ruta de URL? Este tipo de política suele definirse por arquetipo de usuario (cliente, empleado, administrador, desarrollador interno o externo).

Para reducir el riesgo de errores de configuración, se recomienda trabajar con tu equipo de seguridad para garantizar que las aserciones sobre el usuario solicitante se incluyan en el token de acceso, ya sea con el uso de permisos de OAuth o de reclamos de JWT.

Validación de solicitudes con flujos condicionales

En un nivel básico, una llamada a la API de REST se compone de lo siguiente:

  • Un extremo
  • un recurso
  • Un verbo de acción
  • Cualquier cantidad de atributos de solicitud adicionales, como parámetros de consulta

El tipo de ataque que se describe en esta amenaza suele deberse al filtrado insuficiente de una solicitud a la API, lo que permite que un atacante realice acciones no autorizadas o acceda a un recurso protegido. Además de la lógica condicional que te permite filtrar solicitudes según tokens de acceso o reclamos, Apigee permite implementar lógica de filtrado basada en la solicitud en sí.

Una vez que comprendas y definas claramente la lógica empresarial de un producto de API, y qué funciones permiten tus APIs, el siguiente paso es restringir cualquier solicitud que quede fuera de esto a través de estas funciones del producto de Apigee:

  • Lógica condicional y políticas de Raise Fault para restringir rutas de acceso o verbos de recursos en cualquier paso de una configuración de flujo de proxy
  • Políticas de protección contra amenazas de JSON y XML para protegerte contra ataques basados en contenido que usan cargas útiles de solicitudes de JSON o XML con errores de formato

API6:2019, Asignación masiva

Descripción de la amenaza

Los datos sin filtrar que se proporcionan a través de las APIs a las apps cliente permiten que los atacantes adivinen las propiedades de los objetos a través de solicitudes o que usen convenciones de nomenclatura de extremos para obtener pistas sobre dónde realizar modificaciones o accesos no autorizados a las propiedades de los objetos de datos almacenados en el backend.

Esta amenaza se produce cuando se envían datos sin filtrar (por lo general, en formato JSON o XML) a un cliente, lo que permite que un atacante adivine los detalles de implementación subyacentes de tus sistemas de backend, así como los nombres de las propiedades de los elementos de datos confidenciales. El resultado de este tipo de ataque podría otorgarle al atacante la capacidad de leer o manipular datos inapropiados, o, en el peor de los casos, podría habilitar vulnerabilidades de ejecución remota de código.

Por lo general, hay dos aspectos que permiten este tipo de amenaza:

  • La perspectiva del diseño de la API. Nunca confíes en la lógica de la aplicación para filtrar datos del cliente, ya que los atacantes pueden aprovechar las aplicaciones y considerarlas confiables. Siempre diseña el esquema de datos de tu API para exponer solo los datos mínimos y necesarios para habilitar un servicio de API.
  • La perspectiva de implementación de la API. Implementa el filtrado de datos y la validación de esquemas para evitar la exposición inadvertida de datos confidenciales a una aplicación cliente.

Desde la perspectiva del producto de Apigee, proporcionamos varias funciones útiles para garantizar una implementación sólida del filtrado de datos de tus APIs.

Política de filtrado de especificaciones de OpenAPI

La política OASValidation (Validación de especificaciones de OpenAPI) te permite validar un mensaje de solicitud o respuesta entrante con una especificación de OpenAPI 3.0 (JSON o YAML). Esta política te permite hacer lo siguiente:

  1. Diseña tu API creando una especificación de OpenAPI (OAS)
  2. Implementa la lógica de mediación, seguridad y almacenamiento en caché necesaria para exponer de forma segura un producto de API desde tu backend con Apigee
  3. Valida las solicitudes entrantes con el esquema de datos definido en tu especificación de OAS, incluidos basepath, verbo, política de mensajes de solicitud y parámetros.

Política de validación de mensajes SOAP

La política de validación de mensajes SOAP te permite validar solicitudes basadas en XML, ya sea validando un mensaje XML en relación con un esquema XSD o validando un mensaje SOAP en relación con una definición de WSDL. Además, puedes usar la política Message Validation para confirmar que una carga útil de mensaje JSON o XML tiene el formato correcto, lo que incluye verificar lo siguiente en un mensaje XML o JSON:

  • Que haya un solo elemento raíz
  • Que no haya caracteres ilegales en el contenido
  • Que los objetos y las etiquetas estén anidados correctamente
  • Que las etiquetas de inicio y fin coincidan

API7:2019 Configuración incorrecta de seguridad

Descripción de la amenaza

Una configuración incorrecta de la seguridad es a menudo el resultado de una configuración predeterminada poco segura, opciones de configuración ad hoc o incompletas, almacenamiento en la nube abierto, encabezados HTTP configurados incorrectamente, métodos HTTP innecesarios, uso compartido de recursos de origen cruzado (CORS) permisivo y mensajes de error detallados con información sensible. Los atacantes suelen intentar encontrar fallas sin parches, extremos comunes o archivos y directorios desprotegidos para obtener acceso no autorizado o conocimiento del sistema que quieren atacar. Los errores de configuración de seguridad no solo pueden exponer datos sensibles del usuario, sino también detalles del sistema que pueden provocar la vulneración total del servidor. Además, otros casos de uso para las vulnerabilidades de los errores de configuración de seguridad pueden incluir los siguientes:

  • TLS mal configurado
  • Mensajes de error con seguimientos de pila
  • Sistemas sin parches
  • Paneles de administración de servidores o almacenamiento expuestos

Las organizaciones pueden seguir varios pasos para abordar y mitigar los desafíos relacionados con los errores de configuración de seguridad, incluidos los siguientes:

  1. Establecer y estandarizar procesos de aplicación de parches y refuerzo
  2. Desarrollar la gobernanza en torno al ecosistema de APIs
  3. Restringe el acceso administrativo y habilita las alertas y la auditoría

Flujos compartidos y hooks de flujo

Apigee admite el concepto de un flujo compartido que permite a los desarrolladores de APIs combinar políticas y recursos en un grupo reutilizable. Al capturar funciones reutilizables en un solo lugar, el flujo compartido te ayuda a garantizar la coherencia, acortar el tiempo de desarrollo y administrar más fácilmente el código. Puedes incluir un flujo compartido dentro de proxies de API individuales o ir un paso más allá y colocar flujos compartidos en hooks de flujo para ejecutar automáticamente la lógica de flujo compartido para cada proxy de API implementado en el mismo entorno que un flujo compartido.

Supervisión de API

Apigee proporciona una plataforma integral de supervisión de APIs. La Supervisión de API permite a las organizaciones detectar de forma proactiva problemas de rendimiento y tráfico de las APIs. La Supervisión de API de Apigee funciona en conjunto con Apigee Edge para la nube pública para proporcionar estadísticas contextuales en tiempo real sobre el rendimiento de la API, ayuda a diagnosticar problemas rápidamente y facilita las acciones correctivas para la continuidad del negocio.

Figura: La Supervisión de API de Apigee proporciona una amplia variedad de herramientas para supervisar, investigar y tomar medidas en relación con los problemas. Aprovecha las mejores funciones de inteligencia de Google Cloud Platform.

Apigee Sense

Apigee Sense ayuda a proteger las APIs del tráfico de solicitudes no deseadas, incluidos los ataques de clientes maliciosos. Apigee Sense analiza el tráfico de solicitudes a la API y, luego, identifica patrones que podrían representar solicitudes no deseadas.

Con este análisis, las organizaciones pueden identificar a los clientes que realizan solicitudes no deseadas y, luego, tomar medidas para permitir, bloquear o marcar esas solicitudes. Con Apigee Sense, es posible proteger las APIs de patrones de solicitudes que incluyen lo siguiente:

  • Comportamiento automatizado que se combina con el comportamiento humano
  • Intentos persistentes desde la misma IP
  • Tasas de error inusuales
  • Solicitudes sospechosas del cliente
  • Rastreo de datos
  • Recopilación de claves
  • Ráfagas de actividad
  • Patrones geográficos

API8:2019 Inyección

Descripción de la amenaza

La inyección no confiable de datos, como SQL, NoSQL, analizadores de XML, ORM, LDAP, comandos del SO y JavaScript, en solicitudes de API puede provocar la ejecución de comandos no deseados o el acceso no autorizado a los datos. Los atacantes alimentarán la API con datos maliciosos a través de los vectores de inyección disponibles, como entradas directas, parámetros, servicios integrados, etcétera, con la expectativa de que se envíen a un intérprete. Los atacantes pueden descubrir estas fallas fácilmente cuando revisan el código fuente con analizadores de vulnerabilidades y fuzzers. Una inyección exitosa puede provocar la divulgación de información, lo que afecta la confidencialidad y la pérdida de datos, o, en algunos casos, también puede provocar una DoS.

Entre las prácticas recomendadas para mitigar los errores o ataques de inyección, se incluyen definir estrictamente los datos de entrada, como esquemas, tipos y patrones de cadenas, realizar la validación de entrada, las verificaciones de límites y aplicarlos en el tiempo de ejecución. La plataforma de Apigee permite validar los datos entrantes con filtros para permitir solo valores válidos para cada parámetro de entrada.

Apigee Edge, que actúa como servidor para las solicitudes de API entrantes, verifica que la estructura de la carga útil se encuentre dentro de un rango aceptable, lo que también se conoce como verificación de límite. Puedes configurar un proxy de API para que la rutina de validación de entrada transforme la entrada y quite las secuencias de caracteres riesgosas, y las reemplace por valores seguros.

Política de protección contra expresiones regulares

La política RegularExpressionProtection extrae información de un mensaje (por ejemplo, URI de la ruta, parámetro de consulta, encabezado, parámetro de forma, variable, carga útil de XML o carga útil de JSON) y evalúa ese contenido en expresiones regulares predefinidas. Si alguna de las expresiones regulares especificadas se evalúa como verdadera, el mensaje se considera una amenaza y se rechaza. Una expresión regular, o regex, es un conjunto de cadenas que especifican un patrón en una cadena. Las expresiones regulares permiten que el contenido se evalúe de manera programática para los patrones. Las expresiones regulares se pueden usar, por ejemplo, para evaluar una dirección de correo electrónico a fin de garantizar que esté estructurada de forma correcta.

El uso más común de RegularExpressionProtection es la evaluación de cargas útiles de JSON y XML en busca de contenido malicioso.

Ninguna expresión regular puede eliminar todos los ataques basados en el contenido, y se deben combinar varios mecanismos para habilitar la defensa en profundidad. En esta sección, se describen algunos patrones recomendados para evitar el acceso al contenido.

Existen otros enfoques para validar la entrada disponibles con la plataforma de Apigee:

Valida los tipos de contenido

El tipo de contenido hace referencia al contenido de un archivo que se transfiere a través de HTTP y se clasifica según una estructura de dos partes. Apigee recomienda validar los tipos de contenido de la solicitud y la respuesta con lógica condicional, como se explica a continuación.

API9:2019 Administración inadecuada de recursos

Descripción de la amenaza

La administración y la segregación insuficientes del entorno permiten que los atacantes accedan a extremos de API con seguridad insuficiente. La falta de medidas de protección de la gobernanza también causa una exposición innecesaria de los recursos en desuso.

Esta amenaza se puede abordar aprovechando las capacidades consolidadas de Apigee para administrar el ciclo de vida completo de la API, lo que te permite crear un modelo de administración integral que habilita la colaboración entre los equipos y, al mismo tiempo, aplica la separación de responsabilidades entre las partes interesadas de seguridad y los desarrolladores de API. Los límites y los controles se pueden configurar y mantener con las siguientes herramientas:

Organizaciones, entornos y revisiones: Son rieles virtuales y físicos que garantizan el aislamiento y un proceso de promoción seguro a través de contextos de tiempo de ejecución.

Control de acceso basado en roles: Solo las personas necesarias de tus equipos de APIs tendrán permisos para administrar los cambios de configuración y el proceso de promoción.

Administración de público para la documentación de la API: Una vez que se publica una API en el portal para desarrolladores, puedes limitar la visibilidad de la documentación administrando los públicos objetivo.

Flow Hooks: Puedes aplicar políticas y patrones globales que se pueden administrar como protecciones privilegiadas que los desarrolladores de APIs no pueden modificar.

Organizaciones y entornos

Los artefactos de configuración, los usuarios y las funciones de Apigee pueden limitarse a organizaciones o entornos específicos. Esto significa que la plataforma tiene protecciones integradas que se pueden colocar alrededor de las APIs y su configuración de asistencia.

Organizaciones: Una organización es el inquilino de nivel superior en Apigee. Te permite tener una segregación completa del tráfico, la configuración y los usuarios. Como práctica recomendada de gobernanza, debes considerar la posibilidad de tener organizaciones de producción y no producción separadas. Esta práctica evita de manera eficaz la combinación de datos, usuarios y tráfico de producción con entornos inferiores.

Entornos: Las APIs en Apigee se pueden promover a través de varios estados de implementación. Cada estado está vinculado a un contexto de ejecución. El contexto del entorno no se transfiere durante el proceso de promoción, por lo que se evita exponer la configuración sensible a usuarios sin privilegios.

Revisiones: Las revisiones permiten que las APIs y las funciones individuales se promuevan sin problemas a través de los entornos.

Control de acceso basado en roles

Para mitigar API9, es fundamental tener definiciones claras y una separación de funciones entre las partes interesadas en la seguridad y los desarrolladores de APIs. Como se mencionó anteriormente en este documento, Apigee tiene capacidades flexibles de control de acceso basado en roles que te permiten asignar permisos a roles personalizados. Para esta amenaza específica, los roles pueden tener un alcance limitado por organización, entornos o permisos de configuración más detallados. Como práctica recomendada, considera limitar los privilegios para cambiar el estado de implementación de las APIs a través de los entornos y también asegúrate de que los desarrolladores no puedan acceder a las bibliotecas de seguridad globales (Flow Hooks) ni modificarlas. Estos roles limitados evitarán cambios no solicitados en las políticas de seguridad globales que tienen una amplia cobertura en los extremos publicados heredados y actuales.

Administración de públicos para la documentación de la API

Un portal para desarrolladores es un componente fundamental para el éxito de tu estrategia de API, ya que te permite mantener un inventario completo de toda la documentación relacionada con tus APIs, incluidos los hosts o extremos, los recursos, las operaciones, los esquemas de carga útil y mucho más. En Apigee, puedes agrupar tus APIs con las construcciones de productos de API. Los productos de API se definen por paquetes de recursos y operaciones que se encuentran dentro del mismo contexto comercial y de seguridad (p. ej., plan de servicio, dominio comercial, categoría, jerarquía de la empresa, etcétera).

Con el Integrated Developer Portal de Apigee, puedes publicar productos de API y restringir la visibilidad del contenido publicado administrando los públicos objetivo. Esta capacidad cumple con una estrategia de segmentación de contenido que se alinea con los requisitos comerciales y de seguridad.

Hooks de flujo

Los procesos de lanzamiento y promoción de las APIs siempre deben incluir procesos de certificación y cumplimiento de seguridad. Para ser eficaces, los equipos de API que usan las herramientas adecuadas deben poder crear mecanismos de protección que garanticen la separación de responsabilidades y, al mismo tiempo, mantener ciclos de lanzamiento ágiles.

Apigee te permite mejorar las tareas de administración de la seguridad aplicando políticas globales a través de los Flow Hooks. Estas políticas globales se pueden administrar como parámetros de seguridad privilegiados que los desarrolladores de APIs no pueden modificar, lo que garantiza la separación de responsabilidades y también promueve la agilidad al aplicar la seguridad predeterminada y, por extensión, proporcionar el cumplimiento de la seguridad para todas las APIs implementadas en un entorno de ejecución determinado.

Figura: Los rieles de protección con privilegios se pueden configurar en Apigee a través de hooks de flujo y flujos compartidos. Las partes interesadas en la seguridad son responsables de mantener las políticas globales relacionadas con la seguridad. Estas características garantizan la separación de responsabilidades y promueven ciclos de vida de desarrollo ágiles.

API10:2019 Registro y supervisión insuficientes

Descripción de la amenaza

El registro, la supervisión y las alertas insuficientes permiten que los ataques en curso pasen desapercibidos, por lo que se debe implementar una estrategia para obtener estadísticas sobre los eventos críticos que tienen un impacto en tu empresa.

Las estrategias de administración de eventos y registros para las APIs deben tener en cuenta las siguientes prácticas recomendadas:

  • Política de administración de registros: Documenta y aplica reglas para estandarizar y controlar la verbosidad, los niveles y la integridad de los registros, el repositorio centralizado y mucho más.
  • Política de administración de eventos: Garantiza que cada evento se pueda rastrear hasta su fuente. Además, los eventos deben poder clasificarse según su criticidad y su impacto en la empresa.
  • Informes y auditorías: Las partes interesadas de seguridad y operaciones deben poder acceder a los registros y eventos, y reaccionar a ellos en tiempo real. Además, los interesados pueden realizar ciclos de refuerzo para ajustar los patrones de detección según los datos históricos.

Apigee proporciona las herramientas necesarias para crear una estrategia integral de administración de eventos y registros. Se incluyen las siguientes herramientas:

Política de registro de mensajes: Crea transmisiones de registros basadas en datos de tráfico o metadatos de tu tráfico de API. Puedes decidir la verbosidad de la transmisión con lógica condicional y plantillas de mensajes.

Google’s Cloud Operation Suite: Aprovecha la integración lista para usar en herramientas de supervisión y registro altamente escalables de Google.

Política de Llamadas de Servicio: Se agregó compatibilidad con flujos de registros que requieren extremos HTTP para enviar eventos.

Analytics: Accede a los metadatos históricos del tráfico y analízalos a través de informes listos para usar o personalizados. Crear y administrar alertas basadas en tendencias, y comprender las anomalías de tráfico

Supervisión de API: Como se describió anteriormente, esta herramienta proporciona capacidades de alertas que se pueden activar en función de eventos críticos. Los registros de tráfico se pueden analizar y utilizar aún más.