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

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 hablará de las recomendaciones para usar Azure API Management para mitigar las 10 principales amenazas de API identificadas por OWASP.

Nota:

Además de seguir las recomendaciones de este artículo, puede habilitar Defender para API, una funcionalidad de Microsoft Defender for Cloud, para obtener información de seguridad de API, recomendaciones y detección de amenazas. Más información sobre el uso de Defender para API con API Management

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.

Más información sobre esta amenaza: API1:2019 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 solicitud de envío .

  • En escenarios de GraphQL, aplique la autorización de nivel de objeto mediante la directiva de validación de solicitud de GraphQL, usando el elemento authorize.

Autenticación de usuario interrumpida

Los mecanismos de autenticación a menudo se implementan incorrectamente o faltan, lo que permite a los atacantes aprovechar los errores de implementación para acceder a los datos.

Más información sobre esta amenaza: API2:2019 Autenticación de usuario interrumpida

Recomendaciones

Use API Management para la autenticación y la autorización de usuarios:

  • Autenticación: API Management admite los siguientes métodos de autenticación:

    • Directiva de autenticación básica: credenciales de nombre de usuario y contraseña.

    • Clave de suscripción: una clave de suscripción proporciona un nivel de seguridad similar a la autenticación básica y puede que no sea suficiente por sí sola. Si la clave de suscripción está en peligro, un atacante puede obtener acceso ilimitado al sistema.

    • Directiva de certificado de cliente: el uso de certificados de cliente es más seguro que las credenciales básicas o la clave de suscripción, pero no permite la flexibilidad proporcionada por protocolos de autorización basados en tokens, como OAuth 2.0.

  • Autorización: API Management admite una directiva de validación de JWT para comprobar la validez de un token de acceso JWT de OAuth 2.0 entrante en función de la información obtenida del punto de conexión de metadatos del proveedor de identidades de OAuth. Configure la directiva para comprobar las notificaciones de token pertinentes, la audiencia y la hora de expiración. Más información sobre cómo proteger una API mediante la autorización de OAuth 2.0 y Microsoft Entra ID.

Más recomendaciones:

  • Use directivas de restricción de acceso de API Management para aumentar la seguridad. Por ejemplo, la limitación de frecuencia de llamadas frena a los actores con malas intenciones que usan ataques por fuerza bruta para poner en peligro las credenciales.

  • Las API deben usar TLS/SSL (seguridad de transporte) para proteger las credenciales o los tokens. Las credenciales y los tokens deben enviarse en encabezados de solicitud y no como parámetros de consulta.

  • En el portal para desarrolladores de API Management, configure Microsoft Entra ID o Azure Active Directory B2C como proveedor de identidades para aumentar la seguridad de la cuenta. El portal para desarrolladores usa CAPTCHA para mitigar los ataques por fuerza bruta.

Exposición excesiva de datos

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 paso del tiempo, las interfaces de solicitud y respuesta contienen más campos de datos de los que necesitan las aplicaciones consumidoras.

Un actor con malas intenciones podría intentar acceder directamente a la API (quizás reproduciendo una solicitud válida) o examinar el tráfico entre el servidor y la API. El análisis de las acciones de la API y los datos disponibles podrían producir datos confidenciales al atacante, que no se muestran en la aplicación de front-end ni son utilizados por esta.

Más información sobre esta amenaza: API3:2019 Exposición excesiva de datos

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:

    • Revisiones para controlar elegantemente los cambios menores, por ejemplo, la adición de un campo a una interfaz. Puede usar revisiones junto con una implementación de control de versiones en el back-end.

    • Versiones para cambios importantes, por ejemplo, la eliminación de un campo de una interfaz.

  • 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. Por ejemplo, quite las propiedades JSON innecesarias del cuerpo de una respuesta.

  • La validación del contenido de la respuesta de API Management se puede usar con un esquema XML o JSON para bloquear las respuestas con propiedades no documentadas o valores incorrectos. La directiva también admite el bloqueo de las respuestas que superen un tamaño especificado.

  • Use la directiva de validación del código de estado para bloquear las respuestas con errores no definidos en el esquema de la API.

  • Use la directiva de validación de encabezados 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 establecimiento de encabezado.

  • En escenarios de GraphQL, use la directiva de validación de solicitudes de GraphQL para validar las solicitudes de GraphQL, autorizar el acceso a rutas de consulta específicas y limitar el tamaño de respuesta.

Falta de recursos y limitación de frecuencia

La falta de limitación de frecuencia puede provocar ataques de filtración de datos o ataques DDoS con éxito en los servicios back-end, lo que provoca una interrupción para todos los consumidores.

Más información sobre esta amenaza: API4:2019 Falta de recursos y limitación de frecuencia

Recomendaciones

  • Use directivas de límite de frecuencia (a corto plazo) y de límite de cuota (a largo plazo) para controlar el número permitido de llamadas API o ancho de banda por consumidor.

  • Establezca definiciones de objetos de solicitud estrictas y sus propiedades en la definición de OpenAPI. Por ejemplo, defina el valor máximo para la paginación de números enteros, el valor de maxLength y la expresión regular (regex) para las cadenas. Aplique esos esquemas con las directivas de validación de contenido y de validación de parámetros en API Management.

  • Exija el tamaño máximo de la solicitud con la directiva de validación de contenido.

  • Optimice el rendimiento con el almacenamiento en caché integrado, lo que reduce el consumo de CPU, memoria y recursos de red para determinadas operaciones.

  • Exija la autenticación para las llamadas API (consulte Autenticación de usuario interrumpida). Revoque el acceso de los usuarios malintencionados. Por ejemplo, desactive la clave de suscripción, bloquee la dirección IP con la directiva de restricción de direcciones IP del autor de la llamada o rechace solicitudes de una notificación de usuario determinada desde un token JWT.

  • 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 de carácter comodín (*) en la directiva de CORS.

  • 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.

  • Aunque API Management puede proteger los servicios back-end frente a ataques DDoS, puede ser vulnerable a esos ataques. Implemente un servicio de protección contra bots delante de API Management (por ejemplo, Azure Application Gateway, Azure Front Door o Azure DDoS Protection) para protegerse mejor frente a los ataques DDoS. Al usar un WAF con Azure Application Gateway o Azure Front Door, considere la posibilidad de utilizar 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 conduce a errores de autorización. Los atacantes se aprovechan de estos problemas para obtener acceso a los recursos o a las funciones administrativas de otros usuarios.

Más información sobre esta amenaza: API5:2019 Autorización de nivel de función interrumpida

Recomendaciones

  • De forma predeterminada, proteja todos los puntos de conexión de API en API Management con claves de suscripción.

  • Defina una directiva de validación de JWT y aplique las notificaciones de token necesarias. Si ciertas operaciones requieren una aplicación de notificaciones más estricta, defina directivas adicionales validate-jwt solo para esas operaciones.

  • 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.

Asignación masiva

Si una API ofrece más campos de los que el cliente requiere para una acción determinada, un atacante podría insertar propiedades excesivas para realizar operaciones no autorizadas sobre los datos. Los atacantes pueden detectar propiedades no documentadas inspeccionando el formato de las solicitudes y respuestas u otras API, o adivinándolas. Esta vulnerabilidad es especialmente aplicable si no usa lenguajes de programación fuertemente tipados.

Más información sobre esta amenaza: API6:2019 Asignación masiva

Recomendaciones

  • Las interfaces de API externas deben desacoplarse de la implementación de datos interna. Evite enlazar contratos de API directamente a contratos de datos en servicios back-end. Revise el diseño de la API con frecuencia y ponga en desuso y quite las propiedades heredadas mediante el control de versiones de API Management.

  • Defina con precisión contratos XML y JSON en el esquema de API y use directivas de validación de contenido y validación de parámetros para bloquear las solicitudes y respuestas con propiedades no documentadas. 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.

  • Si no se puede cambiar la interfaz de back-end, use directivas de transformación para reescribir las cargas de solicitud y respuesta y desacoplar los contratos de API de los contratos de back-end. Por ejemplo, enmascare o filtre datos o quite las propiedades JSON innecesarias.

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 innecesarias.
  • Conexiones de red innecesariamente abiertas a Internet.
  • Uso de protocolos o cifrados débiles.
  • Otras configuraciones o puntos de conexión que pueden permitir el acceso no autorizado al sistema.

Más información sobre esta amenaza: API7:2019 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.

  • 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 validación de JWT para comprobar la existencia y validez del token JWT 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.

    • 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 las directivas de validación en prevent en entornos de producción para validar los esquemas JSON y XML, los encabezados, los parámetros de consulta y los códigos de estado, y para exigir el tamaño máximo de 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 de validación de certificados de cliente. 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 validación de solicitudes de GraphQL. 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 integrarse con Key Vault o cifrarse dentro de API Management marcándolos con "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.

  • Use la integración de Key Vault para administrar todos los certificados: de esta forma se 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.

  • 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.

  • 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.

Inyección

Cualquier punto de conexión que acepte datos de usuario es potencialmente sensible a las vulnerabilidades de seguridad de inyección. Algunos ejemplos son:

  • Inyección de comandos, donde un actor malintencionado intenta modificar la solicitud de API para ejecutar comandos en el sistema operativo que hospeda la API

  • Inyección de código SQL, donde un actor malintencionado intenta modificar la solicitud de API para ejecutar comandos y consultas en la base de datos de la que depende una API.

Más información sobre esta amenaza: API8:2019 Inyección

Recomendaciones

  • Las directivas modernas de Web Application Firewall (WAF) cubren muchas vulnerabilidades comunes de inyección. Aunque API Management no tiene un componente WAF integrado, se recomienda encarecidamente implementar un WAF ascendente (delante) de la instancia de API Management. Por ejemplo, use Azure Application Gateway o Azure Front Door.

    Importante

    Asegúrese de que un actor malintencionado no pueda omitir la puerta de enlace que hospeda el WAF y conectarse directamente a la puerta de enlace de API Management o a la propia API de back-end. Entre las posibles mitigaciones se incluyen las siguientes: listas ACL de red, con las directivas de API Management para restringir el tráfico entrante por IP de cliente, la eliminación del acceso público cuando no es necesario y la autenticación de certificados de cliente (también conocida como TLS mutua o mTLS).

  • Use directivas de validación de esquemas y parámetros, cuando corresponda, para restringir y validar aún más la solicitud antes de que llegue al servicio de API de back-end.

    El esquema proporcionado con la definición de API debe tener aplicada una restricción de patrón de expresión regular a los campos vulnerables. Cada expresión regular debe probarse para asegurarse de que restringe el campo lo bastante como para mitigar los intentos de inyección comunes.

Administración incorrecta de recursos

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.

Más información sobre esta amenaza: API9:2019 Administración incorrecta de recursos

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 de API Management para controlar y regular los puntos de conexión 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.

  • Use una instancia de API Management por entorno (por ejemplo, desarrollo, prueba y producción). Asegúrese de que cada instancia 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.

  • Use etiquetas para organizar las API y los productos y agruparlos para su publicación.

  • Publique las API para su consumo mediante el portal para desarrolladores integrado. 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.

Registro y supervisión insuficientes

Un registro y una supervisión insuficientes, junto con una integración inexistente o ineficaz con la respuesta a incidentes, permite a los atacantes seguir atacando los sistemas, mantener la persistencia, pasar a más sistemas para manipularlos y extraer o destruir datos. La mayoría de los estudios sobre vulneración demuestran que el tiempo para detectar una infracción es de más de 200 días, normalmente detectada por partes externas en lugar de procesos internos o de supervisión.

Más información sobre esta amenaza: API10:2019 Registro y supervisión insuficientes

Recomendaciones

Pasos siguientes

Más información sobre: