Las 10 amenazas principales de la API de OWASP

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X. Información

En este documento, se describen varios enfoques que puedes usar en Apigee para abordar las vulnerabilidades de seguridad identificadas por OWASP. Si quieres obtener más información sobre los 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 API de confianza. A través del proyecto de seguridad de las APIs de OWASP, OWASP publica los riesgos de seguridad más importantes para las aplicaciones web y las APIs de REST, y proporciona recomendaciones para abordar esos riesgos.

En este documento, se analizan los enfoques para la protección contra ataques comunes basados en APIs, como se identifica en las diez amenazas de seguridad a las APIs más importantes de OWASP de 2019. Un tema común entre las principales amenazas destacadas en la lista más reciente se debe a la ubicación inadecuada de los controles de autenticación y autorización, como la dependencia del filtrado de los datos que muestra una solicitud a la API en las apps cliente, mediante el antipatrón de depender de la app cliente que consume para realizar la aplicación del control de acceso.

Debido a que el crecimiento del ecosistema de API continúa a un ritmo acelerado, los abusos y usos inadecuados de las API que provocan el robo de datos por parte de atacantes se están convirtiendo, lamentablemente, 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 las operaciones avanzadas de API, que incluyen informes de seguridad y funciones de detección de anomalías. Sin embargo, diseñar y, luego, implementar las funciones de seguridad de Apigee de forma correcta es fundamental para reducir las probabilidades de que se produzcan ataques exitosos en tus API.

Las aplicaciones para consumidores deben considerarse no confiables o "públicas", ya que no controlas la plataforma en la que se ejecuta la app. Da por sentado que cualquier app pública puede y estará comprometida. Por lo tanto, no se puede confiar en que se aplique el control de acceso (API1, API5), filtren los datos de respuesta (API6) o almacene de forma segura los secretos del cliente (API2), como claves de API o tokens de acceso. Estos son algunas recomendaciones que surgen del análisis de las principales 10 recomendaciones de OWASP de 2019:

  • Determina qué tipo de apps cliente consumen tus APIs (SPA, dispositivos móviles o basadas en el navegador) y diseña los patrones de autenticación, autorización y seguridad adecuados.
  • Usa siempre los flujos de OpenID Connect o OAuth de “cliente público” (se recomienda usar PKCE).
  • Piensa en la lógica empresarial de tu app, define primero la especificación de OpenAPI y diseña los proxies de la API para filtrar todos los datos de las respuestas del backend en Apigee. Nunca dependas de la lógica del código de la app descendente para hacerlo.
  • 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 de nivel de objeto dañado

Descripción de la amenaza

La validación de autorización insuficiente de una solicitud de acceso a un objeto permite que un atacante realice una acción no autorizada mediante la reutilización de un token de acceso. Esta amenaza se debe a una configuración incorrecta 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, pero es fundamental que estas políticas estén configuradas de forma correcta para evitar esta amenaza.

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

Hay dos aspectos principales que se deben considerar desde la perspectiva de la implementación de Apigee:

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

Integridad del token de acceso

Es fundamental validar que el token que proporciona el cliente solicitante no se haya alterado; para ello, usa el flujo de OAuth o OpenID Connect correcto junto con el mecanismo de firma o validación de credenciales adecuado. Apigee admite todos los flujos de OAuth de uso general.

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 verificó la validez del token de acceso, es fundamental implementar políticas de aplicación de 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: Usa flujos condicionales para evaluar las solicitudes de acceso según las reclamaciones extraídas como variables de flujo de un token de autorización
  • Delegado: Mediante un texto destacado del servicio en una solución de administración de accesos de terceros

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

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

Se recomienda el enfoque delegado (que se ilustra en la figura anterior) cuando las reclamaciones 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 separada a un servidor de autorización para obtener un token de acceso.

Con la política de solicitud de oferta, es posible solicitar una decisión sobre la política de autorización de un servicio de terceros o bien obtener información adicional sobre el reclamo sobre el agente solicitante para tomar una decisión de control de acceso mediante un flujo condicional.

API2:2019 Autenticación de usuarios dañada

Descripción de la amenaza

Las políticas de autenticación de usuarios que se implementan de manera incorrecta permiten que los atacantes suplanten la identidad de usuarios legítimos, ya que aprovechan las fallas de implementación en las implementaciones de autenticación. Estos son algunos principios de autenticación que debes tener en cuenta cuando implementas enfoques de autenticación:

  • Autentica siempre al usuario-agente (la app) y al usuario solicitante.
  • Usa patrones de autenticación y autorización delegados, y evita pasar contraseñas directamente dentro de una solicitud a la API.
  • Valida siempre la firma de las credenciales de acceso y asegúrate de que todas las credenciales de acceso usadas tengan un tiempo de vencimiento definido.
  • Configura cuotas y usa Apigee Sense para prevenir ataques de fuerza bruta a fin de detectar ataques de fuerza bruta generados por bots y responder a ellos

Bajo un paradigma por fuera, el diseño de la API se compila en función de los casos prácticos de los consumidores para los datos, en lugar de la estructura de los datos existentes en tus sistemas de backend. La seguridad es un elemento fundamental cuando se diseñan API para consumidores externos. Por lo general, 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 la protección contra esta amenaza.

Hay algunos elementos importantes que debes tener en cuenta, que se abordarán en las siguientes secciones:

  • Diseño de seguridad: Uso completo de las funciones de Apigee para implementar patrones de autenticación
  • Administración: Garantizar que se use de manera coherente el uso correcto de los patrones de autenticación diseñados en todos los productos de API publicados
  • Seguridad operativa: Poder detectar comportamientos sospechosos o anómalos y tratar de eludir o forzar los proxies de API autenticados por la fuerza bruta

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 la seguridad es una fase fundamental y comienza con la comprensión del tipo correcto de flujo de autenticación delegado que debes usar según el tipo de app que consumirá los extremos de la API. El siguiente paso es definir, junto con tu equipo de identidad, los patrones de integración que se implementarán con la solución de identidad.

Las RFC de OpenID Connect y OAuth proporcionan una gran cantidad de flujos de autenticación y autorización delegados, además de actores involucrados en esos flujos. Este es un tema complejo, y no es de extrañar que la autenticación dañada sea una de las principales amenazas a la API de OWASP. Proporcionar un manual 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, webcast y la implementación de ejemplo.

Políticas de autenticación

Las políticas de Apigee que ayudan a abordar los problemas de identidad y autenticación incluyen lo siguiente:

Administración de tráfico

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

  • La política Spike Arrest, para establecer un límite de frecuencia de promedio móvil general en un proxy de API
  • Políticas de cuotas, para establecer límites de frecuencia detallados de los proxies de API según las cuotas definidas por las claves de aplicaciones, los desarrolladores o las cuotas de productos de API
  • Políticas de almacenamiento en caché para almacenar en caché los tokens de acceso almacenados según sus horas de vencimiento definidas y la capacidad de invalidate las credenciales almacenadas en caché (por ejemplo, cuando un token de acceso válido está comprometido).

Administración

La seguridad es un proceso continuo, no un proyecto sencillo, y una de las principales causas de las violaciones de la seguridad es la configuración incorrecta. Una vez que se definieron los flujos de autenticación, los patrones de integración de identidades y las políticas de administración de tráfico relacionadas con la autenticación, es absolutamente fundamental que se implementen de forma correcta y coherente.

Apigee proporciona una serie de 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 empresa grande o una startup pequeña, la prevención de errores de configuración comienza con la garantía de que solo las personas y los equipos adecuados puedan acceder y modificar los parámetros de configuración del proxy de API. Los programas de APIs cuentan con el respaldo de equipos multidisciplinarios de tu organización. Es absolutamente esencial que a cada equipo solo se le otorguen los permisos necesarios para que realicen sus trabajos como parte de tu recorrido hacia la API.

Apigee proporciona las funciones para que administres el acceso basado en funciones, ya que te permite asignar usuarios a funciones predefinidas o crear funciones personalizadas que se adapten a tus equipos de API. Definir y administrar correctamente la asignación de funciones es fundamental para que puedas escalar de forma segura tu programa de API. También puedes usar la federación para integrarlo a 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 los proxies de API. Por ejemplo, es posible que hayas diseñado varios patrones de diseño de autenticación con tus equipos de seguridad en función del tipo de app que consume una API. No es necesario que un desarrollador de API sea un experto en identidad para reutilizar esta información; solo necesita conocer el flujo compartido correcto para agregarlo a su configuración del proxy de API existente por medio de 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.

Informes de seguridad

Una vez que te hayas asegurado de que solo las personas adecuadas en tu organización pueden modificar los patrones de autenticación y de que hayas definido los flujos de autenticación compartidos, debes asegurarte de que los proxies de API que desarrollaron tus equipos de API usen esos patrones de autenticación de forma coherente.

La nueva función Operaciones avanzadas de API de Apigee incluye informes de seguridad avanzados, que permiten a los equipos de Operaciones y seguridad ver con facilidad informes sobre todos los proxies de API y se centra en el cumplimiento de las políticas de seguridad, como el uso de flujos compartidos. Los informes, el registro y las alertas son un elemento clave de la seguridad de las APIs, que se analizará con más detalle en API10: registro insuficiente, pero, desde la perspectiva de prevenir riesgos de autenticación dañada, es muy útil para garantizar el cumplimiento de los estándares de autenticación definidos que se implementaron como flujos compartidos.

Seguridad operacional

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

Apigee Sense

Apigee Sense protege tus APIs del tráfico de solicitudes no deseado, incluidos los ataques de clientes maliciosos. Apigee Sense analiza el tráfico de solicitudes a la API para identificar patrones que podrían representar solicitudes no deseadas. Con este análisis, puedes identificar los clientes que realizan solicitudes no deseadas y, luego, tomar medidas para permitir, bloquear o marcar esas solicitudes. Las futuras funciones 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 los patrones de solicitud, como los siguientes:

  • Comportamiento automatizado que se combina con el comportamiento humano
  • Intentos persistentes desde la misma IP
  • Tasas de errores inusuales
  • Solicitudes de clientes sospechosas
  • Rastreo de datos
  • Recolección de claves y autenticación por ataques de fuerza bruta
  • Ráfagas de actividad
  • Patrones geográficos

Operaciones avanzadas de API

Si bien Sense se diseñó específicamente para detectar amenazas similares a bots y responder a ellas, las Operaciones avanzadas de API incluyen las definiciones de detección de anomalías y alertas avanzadas.

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

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

  • Alertas de tráfico totales. Genera una alerta cuando el tráfico cambia en un porcentaje específico durante un intervalo de tiempo. Por ejemplo, puedes generar una alerta cuando el tráfico aumente un 5% o más durante una hora, o cuando disminuya un 10% o más durante una semana.
  • Alertas de anomalías. Edge detecta problemas de tráfico y rendimiento en lugar de que tengas que predeterminarlos por tu cuenta. Luego, puedes enviar una alerta para estas anomalías
  • Alertas de vencimiento de TLS Se genera una notificación cuando un certificado TLS está a punto de caducar.

API3:2019 Exposición excesiva de datos

Descripción de la amenaza

Es posible que una API publicada exponga más datos de los necesarios, ya que depende de la app cliente para realizar el filtrado necesario. Si un atacante consulta directamente la API subyacente, podrá acceder a datos sensibles.

Uno de los principios de diseño “fuera hacia adentro” de Apigee para el diseño de APIs es la parsimonia de datos. Trabaja con tus diseñadores y desarrolladores de UX para exponer solo los datos a través de las APIs que sean necesarias dentro de 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 de API con Apigee es reducir los datos expuestos al mínimo necesario para proporcionar un gran 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 inquietudes sobre la seguridad, si dependes de que una app filtre los datos proporcionados por una API, es necesario transferir esa lógica de filtrado en cada plataforma para la que desarrollas una app.

Desde el punto de vista de la seguridad, esta amenaza es el resultado de la delegación de la aplicación de autorizaciones a una app; sin embargo, con frecuencia, en una plataforma o un SO sobre los que no tienes control. Ya evaluamos la importancia de implementar correctamente la autenticación y la autorización en la API1 y la API2 para evitar el acceso no autorizado a los datos.

En las siguientes secciones, se analiza cómo realizar las siguientes tareas:

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

Cómo reescribir respuestas y solicitudes

Por lo general, los sistemas de backend no están diseñados para su uso en apps públicas ni en redes públicas que no sean de confianza. Apigee Edge se diseñó para permitirte implementar productos de API públicas mediante la protección de tus backends contra la exposición excesiva de datos.

Para ello, Apigee usa tres políticas clave:

  • Asignar mensaje
  • Textos destacados del código
  • Manejo de errores

Asignar política de mensajes

La política Asignar mensaje cambia o crea mensajes de solicitud y respuesta nuevos durante el flujo de 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 consulta a un mensaje
  • Copia las propiedades existentes de un mensaje a otro.
  • Quitar encabezados, parámetros de consulta, parámetros de formulario o cargas útiles de mensajes de un mensaje
  • Establece el valor de las propiedades existentes en un mensaje.

Por lo general, con la opción Asignar mensaje debes agregar, cambiar o quitar las propiedades de la solicitud o la respuesta. Sin embargo, también puedes usar Asignar mensaje para crear un mensaje personalizado de solicitud o respuesta y pasarlo a un destino alternativo, como se describe en Cómo crear mensajes de solicitud personalizados.

Reescritura compleja con código personalizado

En el caso de reglas de reescritura y manejo de datos complejas cuya complejidad supera la capacidad de la política de mensajes Asignar, 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 código de procedimiento está diseñada para facilitar la implementación del control complejo de variables de flujo, fallas y 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: la política de JavaScript, la política de texto destacado de Java y la política de Python Script.

Solución de errores

Apigee te permite realizar un control de excepciones personalizado con una política del tipo Aumentar falla. La política Levantar errores, que es una variación de la política Asignar mensaje, 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 fallas. Por ejemplo, las mismas políticas configuradas que detectan un código de error HTTP específico desde el backend se pueden usar para reescribir la respuesta de error y mostrar un mensaje de error genérico.

API 4:2019 Falta de recursos y límite de frecuencia

Descripción de la amenaza

Si no se implementan políticas de límite de frecuencia, los atacantes pueden abrumar el backend con ataques de denegación del servicio.

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

  • Las políticas de cuotas y aumento repentino de los ataques como controles preventivos para establecer límites de tráfico en las solicitudes entrantes a la API
  • Apigee Sense para detectar y responder de forma dinámica los ataques generados por 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 aumento repentino

Apigee proporciona dos políticas para el límite de frecuencia:

  • La detención por spike proporciona una política general, definida a nivel del proxy de API, para limitar la cantidad total de solicitudes entrantes a un backend.
  • Las cuotas proporcionan una herramienta de políticas 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 de Spike Arrest protege contra los aumentos de tráfico. Esta política limita la cantidad de solicitudes que procesa un proxy de API y que se envían a un backend, lo que protege contra los retrasos de rendimiento y el tiempo de inactividad, mediante un valor de promedio móvil que se puede definir en la política.

Cuotas

La política de Cuota habilita la configuración de la cantidad de mensajes de solicitud que permite un proxy de API durante un período, como un minuto, una hora, un día, una semana o un mes. Puedes configurar la cuota de modo que sea la misma para todas las apps que acceden al proxy de API o puedes configurarla 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 la detención de aumento repentino y, por lo general, debe usarse en simultáneo con ella.

Detección de bots con Apigee Sense

Con Apigee Sense, puedes tomar medidas para permitir, bloquear o marcar de forma explícita solicitudes de clientes, rangos de IP o organizaciones de sistemas autónomos específicos, en función de aquellos clientes o ubicaciones que 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 bruto” y, luego, bloquearlo o marcarlo.

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

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

API5:2019: Autorización de nivel de función dañada

Descripción de la amenaza

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

Este tipo de amenaza destaca el valor de usar Apigee como capa de mediación y abstracción, ya que muchos sistemas de backend, que no están diseñados para el acceso público, podrían proporcionar de forma predeterminada un único extremo para ejecutar varias funciones de lógica empresarial, incluida incluso funciones administrativas de alto riesgo.

Los elementos conceptuales que reducen la probabilidad de esta amenaza se suelen dividir en los siguientes:

  • ¿Qué se protege? Piensa en la estrategia de producto de tu API y, luego, implementa la 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, los productos y las funciones de las apps de la API de Apigee.
  • ¿Quiénes acceden a tus recursos de API? Define los arquetipos de alto nivel y, luego, implementa derechos de acceso predeterminados de “privilegio mínimo” mediante 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 condicionales y fallas 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 función en Apigee mediante los alcances proporcionados dentro de un token de acceso como derechos.

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

Apigee proporciona un kit de herramientas altamente flexible para habilitar la segmentación lógica de los recursos de API, lo que permite agrupar proxies de API en cualquier cantidad de productos de API que, a su vez, los consuman tus desarrolladores de apps y que puedan registrar apps que usen 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 funcional eficaces, es fundamental definir una estrategia de producto de API. Parte de este proceso esencial y continuo es la definición del “quién” y el “qué” de tus productos de API. Para ello, se analizan tus recursos de API desde la perspectiva de tu cliente y desarrollador y, luego, definimos los tipos de solicitudes exactos que se permitirán en un recurso de ruta y un nivel de verbo HTTP.

Figura: Los recursos de API agrupados en un producto de API pueden provenir de una o más API, de modo que puedes mezclar y 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 reclamaciones de JWT

Si bien los enfoques de autorización que se analizaron antes para la autorización de objetos dañados de la API1:2019 abordan el control de acceso detallado a nivel de objeto, es igual de importante abordar el control de acceso detallado a nivel de la función. ¿El usuario solicitante puede solicitar esta ruta de URL? Este tipo de política suele definirse por persona de usuario (cliente, empleado, administrador, desarrollador interno o externo).

Para reducir el riesgo de una configuración incorrecta, recomendamos que trabajes con tu equipo de seguridad para asegurarte de que las aserciones sobre el usuario solicitante estén incluidas en el token de acceso, ya sea con el uso de permisos de OAuth o reclamaciones de JWT.

Solicita validación con flujos condicionales

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

  • Un extremo
  • un recurso
  • 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 a que una solicitud a la API no tiene el filtrado suficiente, 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 en función de tokens de acceso o reclamaciones, Apigee permite la implementación de la 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 API, el siguiente paso es restringir cualquier solicitud que no se incluya en este proceso mediante estas funciones del producto de Apigee:

  • Lógica condicional y políticas de generación de errores para restringir las rutas de recursos o los verbos en cualquier paso de una configuración de flujo de proxy
  • Políticas de protección contra amenazas JSON y XML para protegerte de ataques basados en contenido mediante cargas útiles de solicitudes 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 nombres de extremos para dar pistas sobre dónde realizar modificaciones no autorizadas o acceder a las propiedades de los objetos de datos almacenados en el backend.

Esta amenaza ocurre cuando se envían datos sin filtrar (por lo general, en JSON o XML) a un cliente, lo que le permite a un atacante adivinar 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 permitir que un atacante lea o manipule datos inapropiados o, en el peor de los casos, podría habilitar vulnerabilidades de ejecución de código remoto.

Normalmente, hay dos aspectos relacionados que permiten este tipo de amenaza:

  • La perspectiva del diseño de la API. Nunca dependas de la lógica de la aplicación para realizar un filtrado de datos del cliente, ya que los atacantes pueden aprovechar las apps y considerarse de confianza. Diseña siempre el esquema de datos de tu API para exponer solo los datos mínimos necesarios y habilitar un servicio de API.
  • La perspectiva de implementación de la API. Implementa filtrado de datos y 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 la especificación de OpenAPI

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

  1. Crea una especificación de OpenAPI (OAS) para diseñar tu API.
  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 en función del esquema de datos definido en tu especificación de OAS, incluidos la ruta base, el verbo, la política de mensajes de solicitud y los 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 con un esquema XSD o validando un mensaje SOAP con una definición de WSDL. Además, puedes usar la política de validación de mensajes para confirmar que la carga útil de un mensaje JSON o XML tenga el formato correcto, lo que incluye verificar lo siguiente en un mensaje en formato 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

Configuración incorrecta de la seguridad de API7:2019

Descripción de la amenaza

Una configuración incorrecta de la seguridad suele ser el resultado de una configuración predeterminada insegura, una configuración ad hoc o incompleta, el almacenamiento en la nube abierta, los encabezados HTTP configurados incorrectamente, los métodos HTTP innecesarios, el uso compartido de recursos entre dominios (CORS) permisivo y los mensajes de error detallados que contienen información sensible. A menudo, los atacantes intentan encontrar fallas sin parches, extremos comunes o archivos y directorios desprotegidos para obtener acceso o conocimiento no autorizados del sistema que quieren atacar. Los parámetros de configuración incorrectos de seguridad no solo pueden exponer datos sensibles del usuario, sino también detalles del sistema que pueden comprometer por completo el servidor. Además, otros casos prácticos para vulnerabilidades por parámetros de configuración incorrectos de seguridad pueden incluir los siguientes:

  • TLS con configuración incorrecta
  • Mensajes de error con seguimientos de pila
  • Sistemas sin parches
  • Paneles de administración del servidor o almacenamiento expuestos

Existen varios pasos que las organizaciones pueden seguir para abordar y mitigar los desafíos relacionados con la configuración incorrecta de la seguridad, que incluyen los siguientes:

  1. Establecer y estandarizar los procesos de endurecimiento y aplicación de parches
  2. Desarrollar la administración en torno al ecosistema de las APIs
  3. Restringir el acceso de administrador y habilitar la auditoría y las alertas

Flujos compartidos y enlaces de flujo

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

Informes de seguridad de las APIs

A medida que las organizaciones se esfuerzan por desarrollar un marco de trabajo de administración, Apigee proporciona capacidades en torno a los informes de seguridad de las APIs, lo que ayuda a los equipos de operaciones con la visibilidad que necesitan los atributos de seguridad de las APIs para lo siguiente:

  • Garantiza el cumplimiento de las políticas de seguridad y los requisitos de configuración
  • Protege los datos sensibles del abuso interno y externo
  • Identifica, diagnostica y resuelve proactivamente incidentes de seguridad

Los informes de seguridad de Apigee proporcionan estadísticas detalladas a los equipos de operaciones para garantizar el cumplimiento de las políticas y los requisitos de configuración, proteger a las APIs del abuso interno y externo, y también identificar y resolver los incidentes de seguridad con rapidez.

Con los informes de seguridad, los administradores de seguridad pueden comprender rápidamente cómo se configuran los proxies de API para garantizar la seguridad, así como las condiciones del entorno de ejecución que pueden afectar la seguridad de los proxies. Con esta información, puedes ajustar la configuración a fin de asegurarte de tener el nivel adecuado de seguridad para cada proxy.

Supervisión de API

Apigee proporciona una plataforma integral de supervisión de API que complementa las capacidades de informes de seguridad. La supervisión de API permite que las organizaciones detecten de forma proactiva los problemas de rendimiento y de tráfico de API. Apigee API Monitoring funciona en conjunto con Apigee Edge for Public Cloud a fin de proporcionar estadísticas contextuales en tiempo real sobre el rendimiento de las API, ayuda a diagnosticar problemas con rapidez y facilita acciones para la continuidad del negocio.

Figura: Apigee API Monitoring proporciona una amplia variedad de herramientas para supervisar, investigar y tomar medidas al respecto. 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 deseado, incluidos los ataques de clientes maliciosos. Apigee Sense analiza el tráfico de solicitudes a la API para identificar 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 contra los patrones de solicitud, como los siguientes:

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

API8:2019 Injection

Descripción de la amenaza

La inyección de datos no confiable, como SQL, NoSQL, analizadores de XML, ORM, LDAP, comandos del SO y JavaScript, en las solicitudes a la API puede provocar la ejecución de comandos no deseados o el acceso no autorizado a los datos. Los atacantes proporcionarán datos maliciosos a la API a través de los vectores de inserción disponibles, como entradas directas, parámetros, servicios integrados, etc., 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 escáneres de vulnerabilidades y fuzzers. Una inyección correcta puede provocar la divulgación de información que afecte la confidencialidad y la pérdida de datos o, en algunos casos, también puede dar lugar a un ataque de DoS.

Las prácticas recomendadas para mitigar errores o ataques de inserción incluyen definir estrictamente los datos de entrada, como esquemas, tipos y patrones de string, realizar validación de entrada, limitar verificaciones y aplicarlos durante el tiempo de ejecución. La plataforma de Apigee permite validar los datos entrantes mediante filtros a fin de permitir solo valores válidos para cada parámetro de entrada.

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

Política de protección de expresiones regulares

La política RegularExpressionProtection extrae información de un mensaje (por ejemplo, ruta de URI, parámetro de consulta, encabezado, parámetro de formulario, variable, carga útil XML o carga útil de JSON) y evalúa ese contenido en comparación con las expresiones regulares predefinidas. Si alguna expresión regular especificada se evalúa como verdadera, el mensaje se considera una amenaza y se rechaza. Una expresión regular, o regex para abreviar, es un conjunto de strings que especifican un patrón en una string. 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 permitir una defensa en profundidad. En esta sección, se describen algunos patrones recomendados para evitar el acceso al contenido.

Existen muchos otros enfoques para validar entradas disponibles en la plataforma de Apigee:

Valida los tipos de contenido

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

Informes de seguridad de las APIs

A medida que las organizaciones se esfuerzan por desarrollar un marco de trabajo de administración, Apigee proporciona capacidades en torno a los informes de seguridad de las APIs, que asisten y les brindan a los equipos de operación la visibilidad que necesitan para proteger las APIs, ya que brindan a los equipos de operaciones la visibilidad que necesitan los atributos de seguridad de las APIs para lo siguiente:

  • Garantiza el cumplimiento de las políticas de seguridad y los requisitos de configuración.
  • Proteger los datos sensibles del abuso interno y externo
  • Identifica, diagnostica y resuelve proactivamente incidentes de seguridad.

API9:2019 Administración inadecuada de recursos

Descripción de la amenaza

La administración del entorno y la segregación del entorno insuficientes permiten que los atacantes accedan a los extremos de la API poco seguros. La falta de protecciones de administración también causa una exposición innecesaria de recursos obsoletos.

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

Organizaciones, entornos y revisiones: Barreras de seguridad virtuales y físicas que garantizan el aislamiento y un proceso de promoción seguro mediante contextos de tiempo de ejecución.

Control de acceso según la función: Solo las personas necesarias de tus equipos de API tendrán permisos para administrar los cambios en la configuración y también el proceso de promoción.

Administración de públicos 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 mediante la administración del público objetivo.

Enganches de flujo: Puedes aplicar políticas y patrones globales que se pueden administrar como barreras de seguridad con privilegios que los desarrolladores de API no pueden modificar.

Informes de seguridad: Las partes interesadas en la seguridad tienen visibilidad de extremo a extremo de las APIs publicadas y su configuración de respaldo. El cumplimiento de las políticas de seguridad globales se puede auditar y evaluar en función del perfil de riesgo de cada extremo de API publicado.

Organizaciones y entornos

Los artefactos, los usuarios y las funciones de configuración de Apigee pueden aplicarse a organizaciones o entornos específicos. Esto significa que la plataforma tiene barreras de seguridad compiladas previamente que se pueden colocar en torno a las APIs y su configuración complementaria.

Organizaciones: Una organización es el usuario de nivel superior de Apigee. Te permite tener una segregación completa para el tráfico, la configuración y los usuarios. Como práctica recomendada de administración, debes considerar tener organizaciones separadas de producción y no producción. Esta práctica evita de manera eficaz mezclar datos de producción, usuarios y tráfico con entornos más bajos.

Entornos: Las APIs de 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 transmite 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 según el rol

Para mitigar API9, es fundamental tener definiciones claras y separación de obligaciones entre las partes interesadas en la seguridad y los desarrolladores de API. Como se indicó anteriormente en este documento, Apigee tiene funciones flexibles de control de acceso basado en funciones que te permiten asignar permisos a funciones personalizadas. Para esta amenaza específica, se puede determinar que los roles tengan privilegios limitados por organización, entornos o permisos de configuración más detallados. Como práctica preferida, considera limitar los privilegios para cambiar el estado de implementación de las APIs a través de los entornos y también para asegurarte de que los desarrolladores no puedan acceder a las bibliotecas de seguridad globales (hooks de flujo) ni modificarlas. Estos roles limitados evitarán los cambios no solicitados en las políticas de seguridad globales que tienen una amplia cobertura en los extremos heredados y publicados actualmente.

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. Te permite mantener un inventario completo de toda la documentación relacionada con tus API, incluidos los hosts y extremos, los recursos, las operaciones, los esquemas de carga útil y mucho más. En Apigee, puedes agrupar tus APIs mediante las construcciones de productos de API. Los productos de API se definen según paquetes de recursos y operaciones que pertenecen al mismo contexto empresarial y de seguridad (p. ej., plan de servicio, dominio empresarial, categoría, jerarquía de la empresa, etcétera).

Con el Portal para desarrolladores integrado de Apigee, puedes publicar productos de API y restringir la visibilidad del contenido publicado mediante la administración del público objetivo. Esta función cumple con una estrategia de segmentación de contenido que se ajusta a los requisitos comerciales y de seguridad.

Enlaces de flujo

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

Apigee te permite elevar las tareas de administración de seguridad mediante la aplicación de políticas globales a través de hooks de flujo. Estas políticas globales se pueden administrar como protecciones con privilegios que los desarrolladores de API no pueden modificar, lo que garantiza la separación de responsabilidades y promueve la agilidad mediante la aplicación de seguridad predeterminada y, por extensión, proporciona el cumplimiento de seguridad para todas las APIs implementadas en un entorno de ejecución determinado.

Figura: Se pueden configurar barreras de seguridad con privilegios en Apigee mediante enlaces de flujo y flujos compartidos. Las partes interesadas en la seguridad son responsables de mantener las políticas globales relacionadas con la seguridad. Estas funciones garantizan la separación de responsabilidades y promueven ciclos de vida de desarrollo ágiles.

Informes de seguridad

Las auditorías de seguridad están diseñadas para evaluar y probar las políticas de seguridad que protegen los datos y los objetivos comerciales de la organización. Las APIs son interfaces públicas o privadas estandarizadas que deben protegerse con un modelo de administración de seguridad integral y, al mismo tiempo, auditable.

En Apigee tienes acceso a informes de seguridad especializados que ayudan a garantizar el cumplimiento de las políticas definidas y permiten que tus equipos de seguridad tomen medidas en función de estadísticas integrales sobre los siguientes aspectos:

Tráfico del entorno de ejecución: Una vista integral de las estadísticas de tráfico de las APIs sobre los servidores de destino, los hosts virtuales, la configuración de TLS, los cambios de tráfico por entorno y mucho más.

Configuración: Capacidad de auditoría para la configuración de proxies de API que proporciona una visibilidad de extremo a extremo de todas las políticas que se aplican a nivel de proxy de API y también el espectro de aplicación de flujos compartidos que se conectan a niveles de organización o proxy.

Actividad del usuario: Realiza un seguimiento de las operaciones sensibles que realizan los usuarios de la plataforma. Desglosa la actividad sospechosa para analizar la actividad sospechosa.

API10:2019 Registro y supervisión insuficientes

Descripción de la amenaza

Los registros, la supervisión y las alertas insuficientes permiten que los ataques en curso pasen desapercibidos y, por lo tanto, se requiere una estrategia para obtener estadísticas sobre los eventos críticos que tienen un impacto en tu negocio.

En las estrategias de administración de eventos y registros de las APIs, se deben considerar las siguientes prácticas recomendadas:

  • Política de administración de registros: Documenta y aplica reglas para estandarizar y controlar la verbosidad, los niveles de registro, la integridad de los registros, el repositorio centralizado y mucho más.
  • Política de administración de eventos: Garantiza que se pueda rastrear cada evento hasta su fuente. Además, los eventos deben categorizarse por importancia y impacto empresarial
  • Informes y auditorías: Las partes interesadas en las operaciones y la seguridad deben poder acceder a los registros y eventos y reaccionar a ellos en tiempo real. Además, las partes interesadas 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. Entre estas herramientas, se incluyen las siguientes:

Política de registro de mensajes: Crea transmisiones de registro basadas en datos de tráfico o metadatos de tu tráfico de API. Tienes la flexibilidad de decidir la verbosidad de la transmisión mediante el uso de la lógica condicional y las plantillas de mensajes.

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

Política de texto destacado de servicio: Agrega compatibilidad con transmisiones de registros que requieren extremos HTTP para enviar eventos.

Analytics: Accede a los metadatos del tráfico históricos y analízalos mediante informes personalizados o listos para usar. Crea y administra alertas en función de tendencias y comprende las anomalías del tráfico.

Supervisión de API: como se describió antes, esta herramienta proporciona funciones de alerta que se pueden activar en función de eventos críticos. Los registros de tráfico se pueden analizar con más detalle y se pueden tomar medidas al respecto.