Compartir a través de

Recomendaciones para mitigar las 10 principales amenazas de seguridad de las API de OWASP mediante API Management

  • Artículo

SE APLICA A: todos los niveles de API Management

Nota:

Este artículo se ha actualizado para reflejar la lista más reciente de seguridad de la API de OWASP 10 para 2023.

La fundación Open Web Application Security Project (OWASP) trabaja para mejorar la seguridad del software gracias a sus proyectos de software de código abierto dirigidos por la comunidad, sus cientos de divisiones en todo el mundo, sus decenas de miles de miembros, y con la celebración de conferencias a nivel local y mundial.

El proyecto API Security de OWASP se centra en estrategias y soluciones para comprender y mitigar las vulnerabilidades y los riesgos de seguridad únicos de las API. En este artículo se describen las recomendaciones más recientes para mitigar las 10 principales amenazas de API identificadas por OWASP en su lista de 2023 mediante Azure API Management.

Aunque API Management proporciona controles completos para la seguridad de la API, otros servicios de Microsoft proporcionan funcionalidad complementaria para detectar o proteger contra amenazas de api de OWASP:

Autorización de nivel de objeto interrumpida

Los objetos de API que no están protegidos con el nivel de autorización adecuado pueden ser vulnerables a pérdidas de datos y a la manipulación de datos no autorizada mediante identificadores de acceso a objetos débiles. Por ejemplo, un atacante podría aprovechar un identificador de objeto entero, que se puede iterar.

Obtenga más información sobre esta amenaza: API1:2023 Autorización de nivel de objeto interrumpida

Recomendaciones

  • El mejor lugar para implementar la autorización de nivel de objeto es dentro de la propia API de back-end. En el back-end, se pueden tomar las decisiones de autorización correctas a nivel de solicitud (u objeto), si procede, mediante la lógica aplicable al dominio y la API. Considere los casos en los que una solicitud determinada puede producir distintos niveles de detalle en la respuesta, en función de los permisos y la autorización del solicitante.

  • Si no se puede cambiar una API vulnerable actual en el back-end, API Management podría usarse como reserva. Por ejemplo:

    • Use una directiva personalizada para implementar la autorización de nivel de objeto, si no se implementa en el back-end.

    • Implemente una directiva personalizada para asignar identificadores desde la solicitud hasta el back-end y desde el back-end hasta el cliente, de modo que no se expongan los identificadores internos.

      En estos casos, la directiva personalizada podría ser una expresión de directiva con una búsqueda (por ejemplo, un diccionario) o una integración con otro servicio mediante la directiva de send-request.

  • Para escenarios de GraphQL, aplique la autorización de nivel de objeto a través de la directiva de validate-graphql-request mediante el elemento authorize.

Autenticación interrumpida

El mecanismo de autenticación de un sitio o API es especialmente vulnerable porque está abierto a usuarios anónimos. Los recursos y los puntos de conexión necesarios para la autenticación, incluidos los flujos de contraseña olvidados o de restablecimiento de contraseña, deben protegerse para evitar la explotación.

Obtener más información sobre esta amenaza: API2:2023

Recomendaciones

  • Use Microsoft Entra para implementar la autenticación de API. Microsoft Entra proporciona automáticamente puntos de conexión de inicio de sesión protegidos, resistentes y distribuidos geográficamente. Use la directiva validate-azure-ad-token para validar los tokens de Microsoft Entra en las solicitudes de API entrantes.
  • Cuando se requiere autenticación, API Management admite la validación de tokensde OAuth 2, autenticación básica, certificados del cliente y claves de API.
    • Asegúrese de la configuración adecuada de los métodos de autenticación. Por ejemplo, establezca require-expiration-time y require-signed-tokens en true al validar tokens de OAuth2 mediante la directiva validate-jwt.
  • La limitación de velocidad se puede utilizar para reducir la eficacia de los ataques por fuerza bruta.
  • El filtrado IP de cliente se puede usar para reducir el área expuesta a ataques. Los grupos de seguridad de red se pueden aplicar a redes virtuales integradas con API Management.
  • Si es posible, autentíquese en back-end desde API Management mediante protocolos seguros e identidad administrada o administrador de credenciales para autenticarse en los back-end.
  • Asegúrese de que los tokens o claves se pasan en encabezados y no las direcciones URL de las solicitudes entrantes a API Management y las solicitudes salientes a los back-end.
  • Use Microsoft Entra para tener acceso seguro al portal para desarrolladores de API Management.

Autorización de nivel de propiedad de objeto roto

Un buen diseño de la interfaz de API es engañosamente complicado. A menudo, especialmente con las API heredadas que han evolucionado con el tiempo, las interfaces de solicitud y respuesta contienen más campos de datos que los que requieren las aplicaciones que consumen, lo que permite ataques de inyección de datos. Los atacantes también pueden detectar interfaces no documentadas. Estas vulnerabilidades podrían producir datos confidenciales al atacante.

Obtener más información sobre esta amenaza: API3:2023 Autorización de nivel de propiedad de objeto roto

Recomendaciones

  • El mejor enfoque para mitigar esta vulnerabilidad es asegurarse de que las interfaces externas definidas en la API de back-end están diseñadas cuidadosamente e, idealmente, con independencia de la persistencia de los datos. Solo deben contener los campos requeridos por los consumidores de la API. Las API deben ser revisarse con frecuencia, y los campos heredados deben eliminarse.
  • En API Management, use las revisiones para controlar correctamente los cambios que no se produzcan interrupciones, por ejemplo, la adición de un campo a una interfaz y versiones para implementar cambios importantes. También debe tener interfaces de back-end de versión, que normalmente tienen un ciclo de vida diferente al de las API orientadas al consumidor.
  • Desacoplar las interfaces de API externas de la implementación de datos internos. Evite enlazar contratos de API directamente a contratos de datos en servicios back-end.
  • Si no es posible modificar el diseño de la interfaz de back-end y el exceso de datos es un problema, use las directivas de transformación de API Management para reescribir cargas de respuesta y enmascarar o filtrar los datos. La validación de contenido en API Management se puede usar con un esquema XML o JSON para bloquear las respuestas con propiedades no documentadas o valores incorrectos. Por ejemplo, quite las propiedades JSON innecesarias del cuerpo de una respuesta. El bloqueo de solicitudes con propiedades no documentadas mitiga los ataques, mientras que el bloqueo de respuestas con propiedades no documentadas dificulta la ingeniería inversa de posibles vectores de ataque. La directiva de validate-content también admite el bloqueo de respuestas que excedan un tamaño específico.
  • Use la directiva de validate-status-code para bloquear las respuestas con errores no definidos en el esquema de la API.
  • Use la directiva de validate-headers para bloquear las respuestas con encabezados que no estén definidos en el esquema o que no cumplan su definición en el esquema. Quite los encabezados no deseados con la directiva de set-header.
  • En escenarios de GraphQL, use la directiva de validate-graphql-request para validar las solicitudes de GraphQL, autorizar el acceso a rutas de consulta específicas y limitar el tamaño de respuesta.

Consumo de recursos sin restricciones

Las API requieren recursos para ejecutarse, como memoria o CPU, y pueden incluir integraciones de bajada que representan un costo operativo (por ejemplo, servicios de pago por solicitud). La aplicación de límites puede ayudar a proteger las API frente al consumo excesivo de recursos.

Obtenga más información sobre esta amenaza: API4:2023 Consumo de recursos sin restricciones

Recomendaciones

  • Use directivas rate-limit-by-key o rate-limit para aplicar limitaciones en ventanas de tiempo más cortas. Aplique directivas de limitación de velocidad más estrictas en puntos de conexión confidenciales, como restablecimiento de contraseña, inicio de sesión o operaciones de registro, o puntos de conexión que consumen recursos significativos.
  • Use quota-by-key o quota-limit para controlar el número permitido de llamadas API o ancho de banda durante períodos de tiempo más largos.
  • Optimice el rendimiento con el almacenamiento en caché integrado, lo que reduce el consumo de CPU, memoria y recursos de red para determinadas operaciones.
  • Aplicar directivas de validación.
    • Utilice el atributo max-size en la directiva validate-content para imponer el tamaño máximo de solicitudes y respuestas
    • Defina esquemas y propiedades, como longitud de cadena o tamaño máximo de matriz, en la especificación de API. Use las directivas validate-content, validate-parameters y valid-headers para aplicar esos esquemas para solicitudes y respuestas.
    • Use la directiva validate-graphql-request para las API de GraphQL y configure los parámetros max-depth y max-size.
    • Configure alertas en Azure Monitor para un consumo excesivo de datos por parte de los usuarios.
  • Para las API de IA generativas:
  • Minimice el tiempo que tarda un servicio back-end en responder. Cuanto más tiempo tarda el servicio back-end en responder, más tiempo ocupa la conexión en API Management, lo que reduce el número de solicitudes que se pueden atender en un período de tiempo determinado.
    • Defina timeout en la directiva forward-request y se esfuerza por obtener el valor más corto aceptable.
    • Limite el número de conexiones de back-end paralelas con la directiva limit-concurrency.
  • Aplique una directiva de CORS para controlar los sitios web que pueden cargar los recursos atendidos mediante la API. Para evitar configuraciones excesivamente permisivas, no use valores comodín (*) en la directiva CORS.
  • Aunque Azure tiene tanto protección de nivel de plataforma como protección mejorada contra ataques de denegación de servicio distribuido (DDoS), la protección de aplicaciones (nivel 7) para las API se puede mejorar mediante la implementación de un servicio de protección contra bots delante de API Management. Por ejemplo: Azure Application Gateway, Azure Front Door, o Azure DDoS Protection. Al usar una directiva de firewall de aplicaciones web (WAF) con Azure Application Gateway o Azure Front Door, considere la posibilidad de usar Microsoft_BotManagerRuleSet_1.0.

Autorización de nivel de función interrumpida

Las directivas de control de acceso complejas con diferentes jerarquías, grupos y roles, y una separación poco clara entre las funciones administrativas y regulares, conducen a errores de autorización. Al aprovechar estos problemas, los atacantes obtienen acceso a los recursos o funciones administrativas de otros usuarios.

Obtener más información sobre esta amenaza: API5:2023 Autorización de nivel de función interrumpida

Recomendaciones

  • De forma predeterminada, proteja todos los puntos de conexión de API de API Management con claves de suscripción o toda la directiva de autorización de nivel de API. Si procede, defina otras directivas de autorización para determinadas API o operaciones de API.
  • Valide los tokens de OAuth mediante directivas.
    • Use la directiva validate-azure-ad-token para validar los tokens de Microsoft Entra. Especifique todas las notificaciones necesarias y, si procede, especifique las aplicaciones autorizadas.
    • Para validar tokens no emitidos por Microsoft Entra, defina una directiva de validate-jwt y aplique las notificaciones de token necesarias. Si es posible, requiera tiempo de expiración.
    • Si es posible, use tokens cifrados o enumerar aplicaciones específicas para el acceso.
    • Supervise y revise las solicitudes rechazadas debido a la falta de autorización.
  • Use una red virtual de Azure o Private Link para ocultar los puntos de conexión de API de Internet. Más información sobre el uso de opciones de red virtual con API Management.
  • No defina operaciones de API con caracteres comodín (es decir, API "catch-all" con *  como ruta de acceso). Asegúrese de que API Management solo atienda solicitudes de puntos de conexión definidos explícitamente y se rechacen las solicitudes a puntos de conexión no definidos.
  • No publique API con productos abiertos que no requieran una suscripción.
  • Si se conocen las direcciones IP de cliente, use una directiva ip-filter para permitir el tráfico solo desde direcciones IP autorizadas.
  • Use la directiva validate-client-certificate para exigir que un certificado presentado por un cliente a una instancia de API Management coincida con las notificaciones y las reglas de validación especificadas.

Acceso sin restricciones a flujos empresariales confidenciales

Las API pueden exponer una amplia gama de funcionalidades a la aplicación que consume. Es importante que los autores de API comprendan los flujos empresariales que proporciona la API y la confidencialidad asociada. Existe un mayor riesgo para la empresa si las API que exponen flujos confidenciales no implementan protecciones adecuadas.

Obtenga más información sobre esta amenaza: API6:2023 Acceso sin restricciones a flujos empresariales confidenciales

Recomendaciones

  • Reduzca o bloquee el acceso en función de las huellas digitales del cliente. Por ejemplo, use la directiva return-response con la directiva choose para bloquear el tráfico desde exploradores sin encabezado en función del encabezado User-Agent o la coherencia de otros encabezados.
  • Use la directiva validate-parameters para aplicar que los encabezados de solicitud coincidan con la especificación de la API.
  • Use la directiva ip-filter para permitir solicitudes solo de direcciones IP conocidas o denegar el acceso desde direcciones IP específicas.
  • Use características de red privadas para limitar la conectividad externa a las API internas.
  • Use la directiva rate-limit-by-key para limitar los picos en el consumo de API en función de la identidad del usuario, la dirección IP u otro valor.
  • Front API Management con Azure Application Gateway o el servicio Azure DDoS Protection para detectar y bloquear el tráfico de bots.

Falsificación de solicitud del lado servidor

Una vulnerabilidad de falsificación de solicitudes del lado servidor podría producirse cuando la API captura un recurso de bajada en función del valor de una dirección URL que ha pasado el autor de la llamada de API sin las comprobaciones de validación adecuadas.

Obtener más información sobre esta amenaza: API7:2023 Server Side Request Forgery

Recomendaciones

  • Si es posible, no utilice las URL proporcionadas en las cargas útiles del cliente, por ejemplo, como parámetros para las URL de backend, la directiva send-request o rewrite-url.
  • Si API Management o los servicios backend usan URL proporcionadas en la carga útil de la solicitud para la lógica empresarial, defina y aplique una lista limitada de nombres de host, puertos, tipos de medios u otros atributos con directivas en API Management, como la directiva choose y las expresiones de directiva.
  • Defina el atributo timeout en las políticas forward-request y send-request.
  • Valide y sane los datos de solicitud y respuesta con directivas de validación. Si es necesario, use la directiva set-body para procesar la respuesta y evitar devolver datos sin procesar.
  • Use redes privadas para restringir la conectividad. Por ejemplo, si la API no necesita ser pública, restrinja la conectividad desde Internet para reducir la superficie expuesta a ataques.

Configuración incorrecta de seguridad

Los atacantes pueden intentar aprovechar las vulnerabilidades de la configuración incorrecta de seguridad, como:

  • Falta protección de seguridad.
  • Características habilitadas innecesariamente
  • Conexiones de red innecesariamente abiertas a Internet.
  • Uso de protocolos o cifrados débiles.

Obtenga más información sobre esta amenaza: API8:2023 Configuración incorrecta de seguridad

Recomendaciones

  • Configure correctamente TLS de puerta de enlace. No use protocolos vulnerables (por ejemplo, TLS 1.0, 1.1) o cifrados.
  • Configure las API para que acepten solo el tráfico cifrado, por ejemplo, mediante protocolos HTTPS o WSS. Puede auditar y aplicar esta configuración mediante Azure Policy.
  • Considere la posibilidad de implementar API Management detrás de un punto de conexión privado o conectado a una red virtual implementada en modo interno. En las redes internas, el acceso se puede controlar desde dentro de la red privada (mediante un firewall o grupos de seguridad de red) y desde Internet (a través de un proxy inverso).
  • Use directivas de Azure API Management:
    • Herede siempre las directivas principales mediante la etiqueta <base>.
    • Al usar OAuth 2.0, configure y pruebe la directiva de validate-jwt para comprobar la existencia y validez del token antes de llegar al back-end. Compruebe automáticamente la hora de expiración del token, la firma del token y el emisor. Exija notificaciones, audiencias, expiración de tokens y firma de token mediante la configuración de directivas. Si usa Microsoft Entra, la directiva validate-azure-ad-token proporciona una manera más completa y sencilla de validar tokens de seguridad.
    • Configure la directiva de CORS y no use caracteres comodín * con ninguna opción de configuración. En su lugar, enumere explícitamente los valores permitidos.
    • Establezca directivas de validación en entornos de producción para validar esquemas JSON y XML, encabezados, parámetros de consulta y códigos de estado, y para aplicar el tamaño máximo para la solicitud o respuesta.
    • Si API Management está fuera de un límite de red, la validación de IP de cliente sigue siendo posible mediante la directiva de restricción de direcciones IP del autor de la llamada. Asegúrese de que usa una lista de permitidos, no una lista de bloqueados.
    • Si se usan certificados de cliente entre el autor de la llamada y API Management, use la directiva validate-client-certificate. Asegúrese de que los atributos validate-revocation, validate-trust, validate-not-before y validate-not-after estén establecidos en true.
  • También se pueden aplicar certificados de cliente (TLS mutuo) entre API Management y el back-end. El back-end debe:
    • Tener configuradas las credenciales de autorización
    • Validar la cadena de certificados cuando corresponda
    • Validar el nombre del certificado cuando corresponda
    • En escenarios de GraphQL, use la directiva de validate-graphQL-request. Asegúrese de que el elemento authorization y los atributos max-size y max-depth estén establecidos.
  • No almacene secretos en archivos de directiva ni en el control de código fuente. Use siempre valores con nombre de API Management o capture los secretos en tiempo de ejecución mediante expresiones de directiva personalizadas. Los valores con nombre deben estar integrados con Azure Key Vault o cifrados en API Management marcando "secreto". Nunca almacene secretos en valores con nombre de texto sin formato.
  • Publique las API mediante productos que requieran suscripciones. No use productos abiertos que no requieran una suscripción.
  • Asegúrese de que las API requieren claves de suscripción, incluso si todos los productos están configurados para requerir claves de suscripción. Más información
  • Requerir la aprobación de la suscripción para todos los productos y revisar cuidadosamente todas las solicitudes de suscripción.
  • Use la integración de Key Vault para administrar todos los certificados. Esto centraliza la administración de certificados y puede ayudar a facilitar las tareas de administración de operaciones, como la renovación o la revocación de certificados. Use la identidad administrada para autenticarse en almacenes de claves.
  • Al usar la puerta de enlace autohospedada, asegúrese de que exista un proceso implementado para actualizar la imagen a la versión más reciente periódicamente.
  • Represente los servicios back-end como entidades de back-end. Configure las credenciales de autorización, la validación de la cadena de certificados y la validación de nombres de certificado cuando corresponda.
  • Siempre que sea posible, use el administrador de credenciales o la identidad administrada para autenticarse en los servicios de back-end.
  • Al usar el portal para desarrolladores:
    • Si decide hospedar automáticamente el portal para desarrolladores, asegúrese de que exista un proceso para actualizar periódicamente el portal autohospedado a la versión más reciente. Las actualizaciones de la versión administrada predeterminada son automáticas.
    • Use Microsoft Entra ID o Azure Active Directory B2C para el registro y el inicio de sesión de los usuarios. Deshabilite la autenticación predeterminada de nombre de usuario y contraseña, que es menos segura.
    • Asigne grupos de usuarios a productos para controlar la visibilidad de las API en el portal.
  • Use Azure Policy para aplicar permisos de configuración de nivel de recurso y de control de acceso basado en rol (RBAC) de API Management para controlar el acceso a los recursos. Conceda privilegios mínimos necesarios a todos los usuarios.
  • Use un enfoque de proceso DevOps e infraestructura como código fuera de un entorno de desarrollo para garantizar la coherencia de los cambios de configuración y contenido de API Management y para minimizar los errores humanos.
  • No use ninguna característica en desuso.

Administración de inventario incorrecta

Las vulnerabilidades relacionadas con la administración incorrecta de recursos incluyen:

  • Falta de documentación o información de propiedad adecuada de la API.
  • Número excesivo de versiones anteriores de la API, que pueden carecer de correcciones de seguridad.

Obtenga más información sobre esta amenaza: API9:2023 Administración incorrecta del inventario

Recomendaciones

  • Use una especificación OpenAPI bien definida como origen para importar las API REST. La especificación permite la encapsulación de la definición de API, incluidos los metadatos de documentación automática.
  • Use interfaces de API con rutas de acceso, esquemas de datos, encabezados, parámetros de consulta y códigos de estado precisos. Evite operaciones con caracteres comodín. Proporcione descripciones para cada API y operación e incluya información de contacto y licencia.
  • Evite los puntos de conexión que no contribuyan directamente al objetivo empresarial. Aumentan innecesariamente la superficie expuesta a ataques y dificultan la evolución de la API.
  • Use revisiones y versiones en API Management para administrar los cambios de API. Disponga de una sólida estrategia de control de versiones del back-end y comprométase con un número máximo de versiones de la API compatibles (por ejemplo, 2 o 3 versiones anteriores). Planee poner en desuso rápidamente y, en última instancia, quitar versiones de API antiguas, y a menudo, menos seguras. Asegúrese de que los controles de seguridad se implementan en todas las versiones de API disponibles.
  • Separe entornos (como desarrollo, prueba y producción) con diferentes servicios de API Management. Asegúrese de que cada servicio de API Management se conecta a sus dependencias en el mismo entorno. Por ejemplo, en el entorno de prueba, el recurso de API Management de prueba debe conectarse a un recurso de Azure Key Vault de prueba y a las versiones de prueba de los servicios back-end. Use procedimientos de automatización e infraestructura como código de DevOps para ayudar a mantener la coherencia y la precisión entre entornos y reducir los errores humanos.
  • Aísle los permisos administrativos a las API y los recursos relacionados mediante áreas de trabajo.
  • Use etiquetas para organizar las API y los productos y agruparlos para su publicación.
  • Publique las API para su consumo a través de un portal para desarrolladores. Asegúrese de que la documentación de la API está actualizada.
  • Descubra las API no documentadas o no administradas y expóngalas mediante API Management para mejorar el control.
  • Use el Centro de Azure API para mantener un inventario completo y centralizado de LAS API, las versiones y las implementaciones, incluso si las API no se administran en Azure API Management.

Consumo no seguro de las API

Los recursos obtenidos a través de integraciones de bajada tienden a ser más de confianza que la entrada de API del autor de la llamada o del usuario final. Si no se aplican los estándares de seguridad y saneamiento adecuados, la API podría ser vulnerable, incluso si la integración se proporciona a través de un servicio de confianza.

Obtenga más información sobre esta amenaza: API10:2023 Consumo no seguro de las API

Recomendaciones

  • Considere la posibilidad de usar API Management para actuar como unaçreferencia para las dependencias de nivel inferior con las que se integran las API de back-end.
  • Si las dependencias de bajada se presentan con API Management o si las dependencias de bajada se consumen con una directiva de send-reques en API Management, use las recomendaciones de otras secciones de esta documentación para garantizar su consumo seguro y controlado, entre los que se incluyen:
    • Asegúrese de que el transporte seguro está habilitado y aplicar la configuración TLS/SSL
    • Si es posible, autentíquese con el administrador de credenciales o la identidad administrada
    • Control del consumo con directivas rate-limit-by-key y quota-limit-by-key
    • Registrar o bloquear respuestas que no son compatibles con la especificación de API mediante las directivas validate-content y validate-header
    • Transformar respuestas con la directiva set-body, por ejemplo, para quitar información innecesaria o confidencial
    • Configurar tiempos de espera y limitación de simultaneidad

Contenido relacionado

Más información sobre: