Las 10 amenazas principales de aplicaciones web de OWASP

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

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

Descripción general

Los ecosistemas de API experimentan varios ataques de clientes externos e internos. Ofrecer y usar APIs crea enormes oportunidades para los proveedores de servicios, pero también plantea algunos riesgos de seguridad. Los desarrolladores deben conocer estos desafíos y abordarlos cuando crean y usan APIs.

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

Con Apigee, la capa de proxy de API puede detectar, bloquear y denunciar solicitudes a la API con errores de formato del cliente antes de que se procesen en los sistemas de backend, lo que mitiga el riesgo y protege tus servicios. Las solicitudes con errores de formato pueden incluir cualquier componente que forme el protocolo HTTP a nivel de la aplicación:

  • URL
  • Encabezados
  • Ruta
  • Carga útil

Las solicitudes a la API con errores de formato pueden provenir de clientes conocidos o desconocidos desarrollados por desarrolladores externos, desarrolladores internos o bots maliciosos. Estos tipos de solicitudes constituyen la mayoría de las amenazas de OWASP, pero hay componentes adicionales de la capa de proxy de API subyacente que pueden mitigar riesgos, como el enmascaramiento de datos, el registro, la administración, etcétera.

La plataforma inteligente de administración de APIs de Apigee te permite abordar las principales vulnerabilidades de seguridad de la API de OWASP sin problemas a medida que adoptas un enfoque centrado en el consumo para diseñar tus APIs y conectarlas con tus sistemas de backend. A continuación, se incluye una lista de políticas o configuraciones que Apigee recomienda para las principales amenazas de OWASP de REST.

Soluciones de Apigee para OWASP Top 10 de 2017

Existen muchas inquietudes de seguridad cuando se trata de compilar y proteger aplicaciones web. OWASP publicó su lista de las 10 principales amenazas de seguridad de OWASP de 2017 para aplicaciones web. Si bien una aplicación web tiene muchas partes, la mayoría de las apps web modernas dependen en gran medida de las APIs de REST. Apigee no está diseñado para controlar todas las necesidades de seguridad de una aplicación web, pero puede desempeñar un papel fundamental en la protección de las APIs de REST. A continuación, se indican las principales amenazas de seguridad de OWASP con descripciones de cómo puedes usar Apigee para abordar esas amenazas.

A1:2017: Inserción

Para protegerte contra la inserción de datos no confiables, como SQL, NoSQL, LDAP y JavaScript, que pueden provocar la ejecución de comandos no deseados o el acceso no autorizado a los datos, Apigee proporciona varias políticas de validación de entrada para verificar que los valores proporcionados por un cliente coincidan con la expectativa antes de permitir el procesamiento adicional. 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 conocido como verificación de límite. Puedes configurar un proxy de API para que la rutina de validación de entrada transforme la entrada a fin de quitar las secuencias de caracteres riesgosas y, luego, reemplazarlas por valores seguros.

Existen varios enfoques para validar las entradas con la plataforma de Apigee:

Valida los tipos de contenido:

A2:2017: Autenticación y administración de sesiones dañadas

Los atacantes pueden acceder a contraseñas, tokens de sesión y claves para suplantar a otros usuarios aprovechando las fallas de implementación en las aplicaciones. Este es más un problema de implementación y no un problema del producto. Apigee proporciona políticas de VerifyApiKey, OAuth y JSON Web Token (JWT), que ayudan a proteger contra esta vulnerabilidad.

Validación de la clave de API

La validación de la clave de API es la forma más simple de seguridad basada en aplicaciones que se puede configurar para una API. Una app cliente simplemente presenta una clave de API con su solicitud, Apigee Edge, a través de una política adjunta a un proxy de API, verifica que la clave de API esté en estado aprobado para el recurso que se solicita.

Apigee proporciona compatibilidad para la generación y validación de claves de API. Apigee genera una clave de API y un secreto cuando se crea y aprueba una app para desarrolladores que está vinculada a uno o más productos de API.

El término “claves de API” a veces puede significar diferentes cosas. En Apigee, cuando se forma la relación entre la app y el producto, Apigee genera un ID de cliente y un secreto del cliente. Algunos se refieren al ID y al secreto como la clave de API. Algunos se refieren solo al ID de cliente como la clave de API. En la IU de Edge, verás "clave de consumidor" y "secreto de consumidor".

En la política VerifyAPIKey, solo se verifica el ID de cliente o la "clave de consumidor". Los desarrolladores reciben una clave de consumidor cuando registran su app en Apigee y la asocian con un producto de API. Los desarrolladores incluyen la clave de consumidor en las llamadas que realiza la app a los proxies de API que se agrupan en el producto de API.

Apigee también admite la capacidad de importar claves de API existentes de fuentes externas.

Para los tipos de otorgamiento de OAuth, se usan el ID de cliente y el secreto.

OAuth 2.0

El marco de trabajo de autorización de OAuth 2.0 permite que una aplicación de terceros obtenga acceso limitado a un servicio HTTP, ya sea en nombre de un propietario de recurso mediante la organización de una interacción de aprobación entre el propietario del recurso y el servicio HTTP, o permitir que la aplicación de terceros obtenga acceso en su nombre.

Las políticas de OAuth 2.0 de Apigee te permiten implementar y personalizar los cuatro tipos de otorgamiento de OAuth 2.0. La aplicación del token de acceso de OAuth se puede realizar con la política OAuthv2. El consumidor debe estar registrado y tener una app aprobada que le haya otorgado acceso a la API. A cambio, recibirá un ID de cliente de API y un secreto del cliente. El consumidor debe pasar por uno de los otorgamientos de OAuth para autenticarse, lo que le otorga un token de acceso opaco. Este token se puede usar para controlar el acceso a la API.

JWT

Los tokens JSON Web Token (o JWT) se usan de uso frecuente para compartir reclamaciones o aserciones entre aplicaciones conectadas. Apigee proporciona compatibilidad con JWT mediante tres políticas.

  • Tokens GenerateJWT (admite la firma HS256 y RS256)
  • Tokens ValidateJWT
  • Tokens DecodeJWT sin validar

A3:2017: Exposición de datos sensibles

Los atacantes segmentan datos sensibles, como datos de la tarjeta de crédito, números de seguridad social, credenciales de acceso, información de identificación personal (PII) y números de identificación fiscal para cometer robo de identidad, robo de dinero, fraude y otros delitos. Las aplicaciones web deben implementar encriptación, tanto en reposo como en tránsito, y otras estrategias para garantizar la protección de los datos sensibles.

TLS (seguridad de la capa de transporte, cuyo predecesor es SSL) es la tecnología de seguridad estándar para establecer un vínculo encriptado entre un servidor web y un cliente web, como un navegador o una app. Apigee admite TLS unidireccional y bidireccional.

Se admite TLS de salida (cliente que se conecta a la API que actúa como servidor) mediante el uso de una configuración de host virtual. Se puede configurar un host virtual para TLS unidireccional o bidireccional.

Se admite TLS de entrada (Apigee como cliente que se conecta al servicio de backend) mediante el uso de una configuración de servidor de destino. Se puede configurar un servidor de destino para TLS unidireccional o bidireccional.

Apigee admite muchas opciones de configuración de TLS .

La aplicación de TLS bidireccional garantiza que el cliente use un certificado que ya se haya incorporado a Apigee. OWASP también proporciona prácticas recomendadas de TLS.

En Apigee Hybrid, TLS está disponible en la entrada a través de un alias de host, que es un concepto similar a un host virtual.

A continuación, se incluyen lineamientos para proteger los datos sensibles:

  • Usa una plataforma que admita TLS unidireccional y bidireccional, que protegerá a nivel de protocolo.
  • Usa políticas, como la política de asignación de mensaje y la política de JavaScript para quitar los datos sensibles antes de que se muestren al cliente.
  • Usa técnicas estándar de OAuth y considera agregar HMAC, hash, estado, nonce, PKCE, u otras técnicas para mejorar el nivel de autenticación para cada solicitud.
  • Usa la configuración de enmascaramiento de datos para enmascarar datos sensibles en la herramienta de seguimiento de Edge.
  • Ten cuidado de no almacenar datos sensibles en la caché (o encripta los datos sensibles que se almacenan en la caché). En Edge, puedes encriptar datos sensibles en reposo en mapas de clave-valor.

A4:2017: Entidades externas XML

Los sistemas o las aplicaciones que procesan XML deben controlar las "referencias de entidades externas" en XML, es decir, las referencias a archivos o datos que se reemplazan con los datos reales durante el procesamiento de XML. Si las aplicaciones o los procesadores XML son antiguos o están mal implementados, los atacantes pueden hackear los datos y usarlos para robar información o lanzar varios tipos de ataques en el sistema, como la denegación de servicio.

La política de ExtractVariables de Apigee te permite extraer el contenido de una solicitud o respuesta y asignar ese contenido a una variable. Puedes extraer cualquier parte del mensaje, incluidos los encabezados, rutas de URI, cargas útiles de JSON/XML, parámetros de formulario y parámetros de búsqueda. La política funciona mediante la aplicación de un patrón de texto en el contenido del mensaje y, cuando se encuentra una coincidencia, se establece una variable con el contenido del mensaje especificado.

Apigee tiene un analizador de XML integrado como parte de la plataforma que usa XPath para extraer datos. También tiene una política XMLThreatProtection para protegerse contra cargas útiles de XML maliciosas.

A5:2017: Control de acceso dañado

Después de que los usuarios acceden a un sistema, se deben implementar controles de autorización adecuados para que los usuarios puedan ver y hacer solo lo que se les permite. Sin controles de acceso sólidos, los atacantes pueden ver datos no autorizados y, a menudo, sensibles, o manipular de forma maliciosa los datos y el comportamiento del sistema.

Apigee admite un enfoque en capas para implementar controles de acceso a fin de evitar que los actores que actúan de mala fé realicen cambios no autorizados o accedan al sistema.

Controles de acceso para la IU de Edge

Controles de acceso para el portal para desarrolladores de Apigee

  • Configura el inicio de sesión único con el proveedor de identidad de tu empresa.
  • Configura el control de acceso basado en funciones (RBAC) para permitir que los usuarios solo accedan a la funcionalidad y la configuración que necesiten en los portales para desarrolladores basados en Drupal.
  • Configura portales para desarrolladores a fin de mostrar productos de API específicos según la función del usuario.
  • Configura el portal para ocultar o mostrar el contenido según la función del usuario.

Controles de acceso para el acceso a la API de entorno de ejecución de Apigee

  • Se puede aplicar el acceso a las APIs a través de claves de API, tokens de OAuth, alcances de OAuth, certificados, y otras técnicas.
  • El proveedor de la API configura qué recursos están disponibles mediante la definición de un producto de API. El acceso se otorga de forma manual en la IU, a través de la API de administración o a través del portal para desarrolladores. Cuando se otorga acceso a la app de un desarrollador a un producto de API, recibe un ID de cliente y un secreto que se usan en el proceso de autenticación.
  • Apigee se puede integrar con cualquier proveedor de identidad para realizar OAuth.
  • Apigee puede generar tokens JWT o usar otras técnicas para enviar la identidad del usuario a los servicios de destino. Los servicios de destino pueden usar esa identidad para restringir el acceso a los servicios y los datos según sea necesario.

A6:2017: Configuración incorrecta de seguridad

Las configuraciones incorrectas de seguridad son fáciles de pasar por alto, a menudo porque los administradores y los desarrolladores confían erróneamente en que los sistemas que usan son inherentemente seguros. La configuración incorrecta de seguridad puede ocurrir de muchas maneras diferentes, como confiar en configuraciones predeterminadas o hacer configuraciones parciales que podrían ser no seguras, permitir mensajes de error que contengan datos sensibles, almacenar datos en la nube sin controles de seguridad adecuados, configurar de forma incorrecta encabezados HTTP, etcétera. La plataforma de Apigee proporciona varios mecanismos para permitirte controlar, administrar, y supervisar las configuraciones de seguridad, incluidos los flujos compartidos reutilizables.

Un flujo compartido 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 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.

Las versiones de productos de Apigee garantizan la protección contra bibliotecas con vulnerabilidades. Apigee puede lanzar parches o actualizaciones adicionales si se encuentran vulnerabilidades nuevas. La nube pública de Edge se parchea automáticamente. Los clientes de Edge para la nube privada (local) deben aplicar los parches de productos por sí mismos.

A7:2017: Secuencia de comandos entre sitios (XSS)

Las secuencias de comandos entre sitios (XSS) permiten a los atacantes ejecutar secuencias de comandos en navegadores web de usuarios para controlar las sesiones de usuario , manipular los sitios web o afectar a los usuarios de forma maliciosa de otras maneras. Los problemas de XSS no están necesariamente relacionados con las APIs, pero Apigee proporciona políticas de protección contra amenazas que se pueden aprovechar para protegerte contra XSS en la API. Mediante expresiones regulares, ya sea con la política RegularExpressionProtection o la política de JavaScript, verifica la carga útil y los valores de parámetros de JavaScript y otro tipo de inserción ataques.

CORS, una de las soluciones implementadas con frecuencia en la política del mismo origen que aplican todos los navegadores, se puede implementar con la política AssignMessage.

A8:2017: Deserialización insegura

Los atacantes pueden usar fallas en la deserialización para diferentes tipos de ataques, como la repetición, la elevación de privilegios y la inserción. La deserialización insegura también puede habilitar la ejecución de código remoto.

Apigee no recomienda la deserialización. Sin embargo, la política JSONThreatProtection y la política RegularExpressionProtection pueden ayudar a protegerte contra cargas útiles maliciosas de JSON. La política de JavaScript también se puede usar para analizar cargas útiles en busca de contenido malicioso. La caché y otras políticas se pueden usar para protegerte contra ataques de repetición. A nivel de la infraestructura, la plataforma de Apigee también tiene protecciones integradas para proteger los procesos en ejecución.

A9:2017: Uso de componentes con vulnerabilidades conocidas

Debido a que los frameworks, las bibliotecas y los módulos se ejecutan con acceso completo de ejecución y CRUD, los atacantes pueden aprovechar las vulnerabilidades de los componentes para atacar los sistemas.

Las versiones de productos periódicas de Apigee garantizan la protección contra las vulnerabilidades de los componentes, en especial cuando se descubren vulnerabilidades específicas. La nube pública de Apigee se parchea automáticamente y Apigee notifica a los clientes de Edge para la nube privada cuando los parches locales están disponibles para la instalación.

A10:2017: Registro y supervisión insuficientes

Si no realizas el registro, la supervisión y la administración de incidentes de forma adecuada en tus sistemas, los atacantes pueden realizar ataques más profundos y prolongados en los datos y el software.

Apigee tiene varias formas de realizar el registro, la supervisión, el manejo de errores y el registro de auditoría.

Logging

  • Los mensajes de registro se pueden enviar a Splunk o a otro extremo de syslog mediante la política MessageLogging.
  • Los datos de estadísticas de API se pueden extraer mediante la API de estadísticas y se pueden importar o exportar a otros sistemas.
  • En Edge para la nube privada, puedes usar la política de MessageLogging a fin de escribir en los archivos de registro locales. También están disponibles los archivos de registro de cada uno de los componentes en ejecución.
  • La política de JavaScript se puede usar para enviar mensajes de registro a un extremo de registro de REST de forma síncrona o asíncrona.

Supervisión

  • Usa la IU de API Monitoring o la API para supervisar las APIs y los backends con regularidad y activar alertas.
  • Usa la supervisión de estado para supervisar los backends del servidor de destino con regularidad.
  • Apigee proporciona recomendaciones a fin de supervisar Edge para la nube privada.
  • Apigee también brinda prácticas recomendadas que tu equipo puede aprovechar para supervisar tu programa de API.

Manejo de errores

Apigee ofrece un mecanismo de control de fallas potente y versátil para los proxies de API. De manera similar a cómo un programa de Java detectaría excepciones, los proxies de API pueden detectar fallas y determinar cómo mostrar las respuestas adecuadas a los clientes. El manejo de fallas personalizado de Apigee te permite agregar funciones como el registro de mensajes cada vez que se produce un error.

Registros de auditoría

La plataforma de Apigee mantiene un registro de auditoría que realiza un seguimiento de los cambios en los proxies de API, los productos y el historial de la organización. Este registro está disponible a través de la IU o a través de la API de Audits.

Soluciones de Apigee para vulnerabilidades de OWASP de 2013

Cuando OWASP actualizó su lista para 2017, se omitieron algunas vulnerabilidades de la lista de 2013. Sin embargo, siguen siendo amenazas válidas. En las siguientes secciones, se describe cómo controlar estas amenazas con Apigee.

A8:2013: Falsificación de solicitudes entre sitios (CSRF)

Las solicitudes de falsificación entre sitios permiten que los atacantes reenvíen los detalles de autenticación, la cookie de sesión, y otros datos de un usuario a una aplicación web vulnerable a través de HTTP, lo que engaña a la aplicación web para que crea que las solicitudes son legítimas del usuario.

Lineamientos:

  • Este es más un problema del navegador, no un problema del producto de API. Puedes abordar esta vulnerabilidad con OpenID Connect, OAuth y otras técnicas.
  • Considera usar técnicas de HMAC, estado, hash, nonce o PKCE para evitar ataques de falsificación y repetición.

A10:2013: Redireccionamientos y reenvíos no validados

Si una aplicación web realiza redireccionamientos, pero no valida que los redireccionamientos envíen a los usuarios a sitios web confiables y deseados, los atacantes pueden enviar a los usuarios a destinos maliciosos para realizar phishing, ejecución de software malicioso y otros ataques.

Lineamientos:

  • Usa OAuth y aplica la validación en cada solicitud.
  • Para evitar redireccionamientos 302 inesperados, verifica los códigos de respuesta en la lógica del proxy de API y controla los redireccionamientos de forma adecuada.