Las 10 amenazas principales de la API de OWASP

Estás viendo la documentación de Apigee Edge.
Ve 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 que identificó OWASP. Para ver otros enfoques documentados para Apigee, consulta 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 de confianza. A través del proyecto de seguridad de APIs de OWASP, 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 protegerte contra los ataques comunes basados en APIs, como los que se identifican en las diez principales amenazas de seguridad de las APIs de OWASP de 2019. Un tema común en las principales amenazas que destaca la lista más reciente se debe a la ubicación incorrecta de los controles de autenticación y autorización, como la dependencia del filtrado de datos que muestra una solicitud a la API dentro de las apps cliente, a través del uso del antipatrón de depender de la app cliente consumidora para realizar la aplicación forzosa del control de acceso.

A medida que el ecosistema de las APIs sigue creciendo a un ritmo acelerado, los abusos y usos inadecuados de las APIs que resultan en la extracción de datos por parte de los atacantes se están convirtiendo, por desgracia, en uno de los vectores de ataque más comunes en la actualidad. La seguridad sigue siendo una prioridad clave para Apigee, con una serie de funciones nuevas, como Advanced API Ops, que incluye funciones de informes de seguridad y 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 que se realicen ataques exitosos en tus APIs.

Las aplicaciones para consumidores deben considerarse no confiables o "públicas", ya que no controlas la plataforma en la que se ejecuta la app. Supongamos que cualquier app pública puede vulnerarse y, por lo tanto, no se puede confiar en ella para aplicar el control de acceso (API1, API5), filtrar los datos de respuesta (API6) o almacenar de forma segura secretos de cliente (API2), como claves de API o tokens de acceso. Estas son algunas recomendaciones que surgen del examen de los 10 principales de OWASP de 2019:

  • Determina qué tipo de apps cliente consumirán tus APIs (SPA, para dispositivos móviles o basada en navegadores) y diseña los patrones de autenticación, autorización y seguridad adecuados.
  • Usa siempre los flujos de OAuth o OpenID Connect de "cliente público" (se recomienda usar 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 dentro de Apigee. Nunca te bases en la lógica del código de la app downstream 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 dañada

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 reutilizando 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. Sin embargo, es fundamental que estas políticas se configuren correctamente para evitar esta amenaza.

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

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

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

Integridad del token de acceso

Es fundamental validar que no se haya manipulado el token que proporcionó el cliente solicitante. Para ello, usa el flujo correcto de OAuth o OpenID Connect junto con el mecanismo de validación o firma 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 las siguientes:

Aplicación del control de acceso

Una vez que se haya verificado la validez del token de acceso, es fundamental implementar políticas de aplicación del control de acceso para evaluar cada solicitud entrante a la API 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 los reclamos extraídos como variables de flujo de un token de autorización.
  • Delegado: Se usa una nota al pie de servicio para una solución de administración de acceso 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 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 sentencias de flujo condicionales.

Se recomienda el enfoque delegado (que se ilustra en la figura anterior) cuando los reclamos extraídos de un token de acceso no se pueden usar directamente para autorizar una solicitud de 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 texto destacado del servicio, es posible solicitar una decisión de política de autorización a un servicio de terceros o obtener información de reclamos adicional sobre el agente solicitante para tomar una decisión de control de acceso con un flujo condicional.

API2:2019 Autenticación de usuario dañada

Descripción de la amenaza

Las políticas de autenticación de usuarios implementadas de forma incorrecta permiten que los atacantes roben la identidad de 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 dentro de 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 generados por bots.

En 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 protegerte contra esta amenaza.

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

  • Diseño de seguridad: Aprovecha al máximo las funciones de Apigee para implementar patrones de autenticación.
  • Gobernanza: Garantiza que el uso correcto de los patrones de autenticación diseñados se use de manera coherente en todos los productos de API publicados.
  • Seguridad operativa: Ser capaz de detectar comportamientos sospechosos o anómalos, y de intentar eludir o forzar de manera bruta los 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 y comienza con la comprensión del tipo correcto de flujo de autenticación delegada que se debe usar en función del 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.

Las 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 es de extrañar que la autenticación dañada sea una de las principales amenazas de la API de OWASP. Proporcionar una guía 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 webcast y este ejemplo de implementación.

Políticas de autenticación

Entre las políticas de Apigee que ayudan a abordar las inquietudes relacionadas con la identidad y la autenticación, se incluyen las siguientes:

Administración de tráfico

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

  • La política de Spike Arrest, para establecer un límite general de frecuencia 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 app, los desarrolladores o las cuotas de productos de API
  • Políticas de almacenamiento en caché, para almacenar en caché los tokens de acceso almacenados en función de sus tiempos de vencimiento definidos, así como la capacidad de invalidate las 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 la seguridad es la configuración incorrecta. Una vez que se definen los flujos de autenticación, los patrones de integración de identidad y las políticas de administración de 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 incorrecta.

Control de acceso basado en roles (RBAC)

Ya sea que tengas una gran empresa o una startup pequeña, para evitar errores de configuración incorrecta, primero debes asegurarte de que solo las personas y los equipos adecuados puedan acceder a la configuración del proxy de la API y modificarla. Los programas de API están respaldados por equipos multidisciplinarios de 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 de API.

Apigee te proporciona las funciones para administrar el acceso basado en roles, ya que te permite asignar usuarios a roles predefinidos o crear roles personalizados para tus equipos de API. Definir y administrar correctamente la asignación de roles es fundamental para que puedas escalar tu programa de API de forma segura. También puedes usar la federación para integrarte 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 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 API no necesita ser un experto en identidad para volver a usar esto, solo necesita conocer el flujo compartido correcto para agregarlo a su configuración de proxy de API existente con la política de callout 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 de tu organización puedan modificar tus patrones de autenticación y hayas definido tus 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 Advanced API Ops de Apigee incluye informes de seguridad avanzados, que permiten a los equipos de operaciones y seguridad ver fácilmente informes sobre todos los proxies de API y se enfocan 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 la API, que se analizará con más detalle en API10: Registro insuficiente, pero, desde la perspectiva de evitar riesgos de autenticación fallida, es muy útil para garantizar el cumplimiento de los estándares de autenticación definidos implementados como flujos compartidos.

Seguridad operacional

Una vez que tus APIs estén en producción con los patrones de autenticación correctos y se implemente la administración de tráfico de referencia, 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 los patrones de solicitudes que incluyen lo siguiente:

  • Comportamiento automatizado que se mezcla con el comportamiento humano
  • Intentos persistentes desde la misma IP
  • Tasas de errores inusuales
  • Solicitudes de clientes sospechosas
  • rastreo de datos
  • Ataque de fuerza bruta de recolección de claves y autenticación
  • Actividades intensas
  • Patrones geográficos

Operaciones avanzadas de API

Si bien Sense se diseñó específicamente para detectar y responder a amenazas similares a bots, 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. Luego, la detección de anomalías puede generar alertas en tiempo real para situaciones que ni siquiera habías pensado para mejorar tu productividad y reducir el tiempo promedio de resolución (MTTR) de tus problemas de API.

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

  • Total de alertas de tráfico: Genera una alerta cuando el tráfico cambia en un porcentaje especificado durante un período. Por ejemplo, puedes generar una alerta cuando el tráfico aumente en un 5% o más durante una hora, o disminuya en un 10% o más durante una semana.
  • Alertas de anomalías. Edge detecta problemas de tráfico y rendimiento, en lugar de que tú los tengas que predeterminar. 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 puede exponer más datos de los necesarios, lo que depende de la app cliente para realizar el filtrado necesario. Si un atacante consulta directamente la API subyacente, puede acceder a los datos sensibles.

Uno de los principios de diseño “de afuera 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 se necesitan 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 de prioridad de la API 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. Además de las preocupaciones de seguridad, depender de una app para filtrar los datos que proporciona una API implica que se debe portar esa lógica de filtrado a todas las plataformas para las que desarrollas una app.

Desde una perspectiva de seguridad, esta amenaza se produce cuando se delega la aplicación de la autorización a una app, a menudo en una plataforma o un SO sobre los que no tienes control. Ya examinamos 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 explica cómo hacer lo siguiente:

  • Vuelve a escribir las solicitudes y respuestas a los 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.

Reescribe las respuestas y las 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úblicas protegiendo tus backends de una exposición excesiva de datos.

Para ello, Apigee usa tres políticas clave:

  • Asignar mensaje
  • Textos destacados de código
  • Manejo de fallas

Política de asignación de mensajes

La política AssignMessage cambia o crea nuevos mensajes de solicitud y respuesta 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
  • Quita los encabezados, los parámetros de búsqueda, los parámetros de formulario o las cargas útiles de mensaje de un mensaje
  • Establece el valor de las propiedades existentes en un mensaje

Con AssignMessage, por lo general, debes agregar, cambiar o quitar propiedades de la solicitud o la respuesta. Sin embargo, también puedes usar AssignMessage 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 complejo de datos y las reglas de reescritura cuya complejidad supera la capacidad de la política de asignar mensajes, 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 de proxy. La compatibilidad con el código de procedimientos está diseñada para que sea más fácil implementar un 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: política de JavaScript, política de texto destacado de Java y política de secuencia de comandos de Python.

Solución de errores

Apigee te permite realizar un manejo de excepciones personalizado con una política de tipo RaiseFault. La política RaiseFault, que es una variación de la política de asignación de mensajes, 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.

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 abrumar al backend con ataques de denegación del servicio.

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

  • Cuotas y políticas de Spike Arrest como controles preventivos para establecer límites de tráfico en las solicitudes entrantes de la API
  • Apigee Sense para detectar y responder de forma dinámica los ataques generados por bots
  • Supervisión y alertas de API avanzadas como controles de detección para recibir alertas sobre ataques DDoS en curso

Límite de frecuencia con políticas de cuotas y de protección contra aumentos de tráfico

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

  • La protección contra aumentos de tráfico 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 en un proxy de API o en un producto de API.

SpikeArrest

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

Cuotas

La política de cuotas 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 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 la de protección contra aumentos de tráfico y, por lo general, debe usarse de forma simultánea con ella.

Detección de bots con Apigee Sense

Con Apigee Sense, puedes tomar medidas para permitir, bloquear o marcar solicitudes de clientes, rangos de IP o organizaciones de sistemas autónomos específicos de forma explícita, según esos clientes o ubicaciones que muestren 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 muestre un comportamiento de “ataque de descifrado de contraseñas” y, luego, bloquearlo o marcarlo.

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

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 de manera significativa de la capacidad de procesamiento esperada, como sería el caso de un ataque DDoS. Estas alertas se pueden enviar fácilmente a una solución de registro y supervisión de terceros.

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

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 reemplazar un GET por un PUT o DELETE para modificar o borrar datos que solo tiene autorización para leer si un extremo de la API no valida el verbo de la solicitud HTTP. O bien, si no se implementa un control de acceso lo suficientemente restrictivo en una ruta de acceso de URI de un recurso de API, un extremo de API podría permitir que un atacante vea los datos de otro usuario simplemente cambiando la ruta de acceso 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, podrían proporcionar de forma predeterminada un único extremo para ejecutar varias funciones de lógica empresarial, incluso funciones administrativas de alto riesgo.

Los elementos conceptuales para reducir la probabilidad de esta amenaza suelen dividirse en lo siguiente:

  • ¿Qué se protege? Piensa en tu estrategia de productos de 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 de API, los productos y las funciones de las apps de Apigee.
  • ¿Quiénes acceden a tus recursos de API? Define los arquetipos de alto nivel y, luego, usa algunas de las funciones de autenticación y autorización de Apigee para implementar los derechos de acceso predeterminados de “privilegios mínimos”, como se describe en API1 y API2.
  • ¿Cómo se aplican tus políticas de acceso? Usa flujos y fallas 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 permisos proporcionados dentro de un token de acceso como derechos.

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

Apigee proporciona un kit de herramientas muy flexible para habilitar la segmentación lógica de los recursos de API, lo que permite que los proxies de API se empaqueten en cualquier cantidad de productos de API, que, a su vez, son consumidos por los desarrolladores de tu app, que pueden registrar apps que usan 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 de quién y qué son tus productos de API, analizando los recursos de tu API desde la perspectiva del cliente y del desarrollador, y luego definiendo exactamente qué tipos de solicitudes se permitirán a nivel de un recurso de ruta y un verbo HTTP.

Figura: Los recursos de API agrupados en un producto de la API pueden provenir de una o más APIs para que puedas combinar y hacer coincidir recursos a fin de crear niveles de consumo y límites de autorización.

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

Si bien los enfoques de autorización que se consideraron anteriormente para API1:2019 Broken object authorization se refieren al control de acceso detallado a nivel del objeto, es igual de importante abordar el control de acceso detallado a nivel de la función. ¿El usuario solicitante tiene permitido 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 una configuración incorrecta, la recomendación es trabajar con tu equipo de seguridad para asegurarte de que las afirmaciones sobre el usuario solicitante se incluyan en el token de acceso, ya sea con el uso de alcances de OAuth o de declaraciones de JWT.

Solicita la validación con flujos condicionales

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

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

Por lo general, el tipo de ataque que se describe en esta amenaza se debe 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 la implementación de lógica de filtrado según la solicitud en sí.

Una vez que comprendas y definas claramente la lógica empresarial de un producto de API, qué funciones permiten tus APIs, el siguiente paso es restringir las solicitudes que no se incluyen en ellas a través de estas funciones del producto de Apigee:

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

API6:Asignación masiva de 2019

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 obtener pistas sobre dónde realizar modificaciones no autorizadas o acceder a propiedades en objetos de datos almacenados en el backend.

Esta amenaza se produce cuando se envían datos sin filtrar (por lo general, en JSON o XML) a un cliente, lo que permite que un atacante averigüe 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, habilitar vulnerabilidades de ejecución de código remota.

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

  • La perspectiva de diseño de la API. Nunca confíes en la lógica de la aplicación para realizar el filtrado de datos del cliente, ya que los atacantes pueden aprovecharse de las apps y considerarlas de confianza. Siempre diseña tu esquema de datos de API para que solo exponga 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 de los productos de Apigee, proporcionamos varias funciones útiles para garantizar una implementación sólida de filtrado de datos de tus APIs.

Política de filtrado de la especificación 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. 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 con el esquema de datos definido en tu especificación de OAS, incluidos la basepath, 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 en un esquema XSD o validando un mensaje SOAP en una definición de WSDL. Además, puedes usar la política de validación de mensajes para confirmar que una carga útil de mensaje JSON o XML tenga 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 la 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 abierta, encabezados HTTP configurados incorrectamente, métodos HTTP innecesarios, uso compartido de recursos de origen múltiple (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 información sobre el sistema que quieren atacar. Las configuraciones de seguridad incorrectas 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, estos son otros casos de uso de vulnerabilidades para configuraciones de seguridad incorrectas:

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

Existen varios pasos que las organizaciones pueden seguir para abordar y mitigar los desafíos relacionados con los errores de configuración de seguridad, entre los que se 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 la API
  3. Restringe el acceso de administrador y habilita la auditoría y las alertas

Flujos y hooks de flujo compartidos

Apigee admite el concepto de un flujo compartido que permite que los desarrolladores de API combinen políticas y recursos en un grupo reutilizable. Debido a que captura la funcionalidad reutilizable en un solo lugar, un flujo compartido te ayuda a garantizar la coherencia, acortar el tiempo de desarrollo y administrar el código con mayor facilidad. Puedes incluir un flujo compartido dentro de proxies de API individuales, o bien puedes 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.

Informes de seguridad de la API

A medida que las organizaciones se esfuerzan por desarrollar un marco de gobierno, Apigee proporciona capacidades en torno a los informes de seguridad de las APIs que ayudan 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 incidentes de seguridad de forma proactiva

Los informes de seguridad de Apigee proporcionan estadísticas detalladas para que los equipos de operaciones garanticen el cumplimiento de las políticas y los requisitos de configuración, protejan las APIs del abuso interno y externo, y también identifiquen y resuelvan rápidamente los incidentes de seguridad.

Con los informes de seguridad, los administradores de seguridad pueden comprender rápidamente cómo están configurados los proxies de API para la seguridad, así como las condiciones del entorno de ejecución que podrían afectar la seguridad del proxy. Con esta información, puedes ajustar la configuración para asegurarte de tener el nivel de seguridad adecuado 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 a las organizaciones detectar de forma proactiva problemas de tráfico y rendimiento de las APIs. Apigee API Monitoring funciona junto con Apigee Edge para Public Cloud para proporcionar estadísticas contextuales en tiempo real sobre el rendimiento de las APIs, ayudar a diagnosticar rápidamente los problemas y facilitar las acciones de solución para la continuidad empresarial.

Figura: La supervisión de API de Apigee proporciona una amplia variedad de herramientas para supervisar, investigar y abordar los problemas. Aprovecha las funciones de inteligencia de primer nivel 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 los patrones de solicitudes que incluyen lo siguiente:

  • Comportamiento automatizado que se mezcla 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
  • Actividades intensas
  • Patrones geográficos

Inyección de API8:2019

Descripción de la amenaza

La inserción de datos no confiables, 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 cualquier vector de inyección disponible, 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 escáneres de vulnerabilidades y generadores de fuzz. 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 un DoS.

Las prácticas recomendadas para mitigar los errores o ataques de inyección incluyen definir estrictamente los datos de entrada, como los esquemas, los tipos y los patrones de cadenas, realizar la validación de entradas, realizar verificaciones de límite y aplicarlas durante 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 a la API entrantes, verifica que la estructura de la carga útil esté dentro de un rango aceptable, también conocida 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, luego, las reemplace por valores seguros.

Política de protección de 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 formulario, 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 las cargas útiles de JSON y XML para el contenido malicioso.

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

Existen varios otros enfoques para validar las entradas 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.

Informes de seguridad de la API

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

  • Garantizar el cumplimiento de las políticas de seguridad y los requisitos de configuración
  • Proteger los datos sensibles del abuso interno y externo
  • Identificar, diagnosticar y resolver de forma proactiva los incidentes de seguridad

API9:2019 Administración de recursos inadecuada

Descripción de la amenaza

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

Para abordar esta amenaza, puedes aprovechar las capacidades maduras de Apigee para administrar el ciclo de vida completo de la API, lo que te permite crear un modelo de administración integral que permita la colaboración entre los equipos y, al mismo tiempo, aplicar la separación de responsabilidades entre las partes interesadas en la seguridad y los desarrolladores de la API. Los límites y los controles se pueden configurar y mantener con lo siguiente:

Organizaciones, entornos y revisiones: Barreras virtuales y físicas 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 API tendrán permisos para administrar los cambios de configuración y 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 administrando los públicos objetivo.

Hooks de flujo: Puedes aplicar políticas y patrones globales que se pueden administrar como límites de privilegio que los desarrolladores de la 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 compatibilidad. 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 de configuración, los usuarios y las funciones de Apigee se pueden asignar a organizaciones o entornos específicos. Esto significa que la plataforma tiene protecciones precompiladas que se pueden colocar alrededor de las APIs y su configuración de compatibilidad.

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 tener organizaciones de producción y no producción separadas. Esta práctica evita de manera eficaz mezclar datos, usuarios y tráfico de producción con entornos inferiores.

Entornos: Las APIs de Apigee se pueden promocionar 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 conserva durante el proceso de promoción, por lo que se evita exponer la configuración sensible a los usuarios sin privilegios.

Revisión: Las revisiones permiten que las APIs y las funciones individuales se promocionen 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 deberes entre las partes interesadas en la seguridad y los desarrolladores de la API. Como se indicó 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 se pueden asignar para tener privilegios limitados 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 para asegurarte de que los desarrolladores no puedan acceder a las bibliotecas de seguridad globales ni modificarlas (hooks de flujo). Estos roles limitados evitarán cambios no solicitados en las políticas de seguridad globales que tengan 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 integral 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 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 portal para desarrolladores integrado de Apigee, puedes publicar productos de API y restringir la visibilidad del contenido publicado administrando los públicos objetivo. Esta función cumple con una estrategia de segmentación de contenido que se alinea con los requisitos de seguridad y empresariales.

Hooks de flujo

Los procesos de promoción y lanzamiento 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 protecciones que garanticen la separación de responsabilidades y, al mismo tiempo, mantener ciclos de lanzamiento ágiles.

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

Figura: Los controles de acceso 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 funciones garantizan la separación de responsabilidades y promueven ciclos de vida de desarrollo ágil.

Informes de seguridad

Las auditorías de seguridad tienen como objetivo evaluar y probar las políticas de seguridad que tienen como objetivo proteger los datos y los objetivos comerciales de tu 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 lo siguiente:

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

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

Actividad del usuario: Realiza un seguimiento de las operaciones sensibles que realizan los usuarios de la plataforma. Para analizar la actividad sospechosa, desglosa esta actividad.

API10:2019 Registro y supervisión insuficientes

Descripción de la amenaza

La falta de registros, supervisión y alertas permite que los ataques en curso no se detecten y, por lo tanto, se debe implementar una estrategia para obtener estadísticas sobre los eventos críticos que afectan a tu empresa.

Las estrategias de administración de eventos y registros de 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, la integridad, el repositorio centralizado y mucho más de los registros.
  • 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 importancia y su impacto en el negocio.
  • Informes y auditorías: Las partes interesadas en seguridad y operaciones 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 en función de 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 flujos de registro basados en datos de tráfico o metadatos de tu tráfico de API. Tienes la flexibilidad de decidir la verbosidad del flujo aprovechando la lógica condicional y las plantillas de mensajes.

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

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

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

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