Las 10 amenazas principales de aplicaciones web de OWASP

Estás viendo la documentación de Apigee Edge.
Ve a la documentación de Apigee X. Información

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

Descripción general

Los ecosistemas de APIs experimentan varios ataques de clientes internos y externos. Ofrecer y usar APIs crea enormes oportunidades para los proveedores de servicios, pero también implica algunos riesgos de seguridad. Los desarrolladores deben estar al tanto de estos desafíos y abordarlos cuando creen y usen las APIs.

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

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

  • URL
  • Encabezados
  • Ruta de acceso
  • Carga útil

Las solicitudes a la API con formato incorrecto 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 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 de administración inteligente de APIs de Apigee te permite abordar las principales vulnerabilidades de seguridad de las APIs de OWASP sin interrupciones mientras adoptas un enfoque centrado en el consumo para diseñar tus APIs y conectarlas con tus sistemas de backend. A continuación, se muestra una lista de políticas y configuración que Apigee recomienda para las principales amenazas de REST OWASP.

Soluciones de Apigee para las OWASP Top 10 de 2017

Existen muchas preocupaciones de seguridad cuando se trata de compilar y proteger aplicaciones web. OWASP publicó su lista de las 10 principales amenazas de seguridad de OWASP del 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 manejar todas las necesidades de seguridad de una aplicación web, pero puede desempeñar un papel fundamental en la seguridad de las APIs de REST. Estas son las principales amenazas a la seguridad de OWASP, con descripciones de cómo puedes usar Apigee para abordar esas amenazas.

A1:2017: Inyección

Para brindar protección contra la inyección de datos que no son de confianza, como SQL, NoSQL, LDAP y JavaScript, que puede provocar la ejecución de comandos no deseados o el acceso no autorizado a 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 más procesamiento. Apigee Edge, que actúa como un servidor para las solicitudes entrantes a la API, comprueba que la estructura de la carga útil se encuentre dentro de un rango aceptable, también conocido como verificación de límite. Puedes configurar un proxy de API para que la rutina de validación de entrada transforme la entrada a fin de quitar secuencias de caracteres riesgosas y reemplazarlas por valores seguros.

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 la identidad de otros usuarios mediante las fallas de implementación en las aplicaciones. Esto se debe más a un problema de implementación que a un problema del producto. Apigee proporciona políticas de VerifyApiKey, OAuth y de token web JSON (JWT), que ayudan a brindar protección 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 apps que se puede configurar para una API. Una app cliente simplemente presenta una clave de API con su solicitud. Luego, Apigee Edge, a través de una política adjunta a un proxy de API, verifica que la clave de API esté aprobada para el recurso solicitado.

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

El término “claves de API” puede tener distintos significados. En Apigee, cuando se forma la relación entre aplicación y producto, este genera un ID y un secreto de cliente. En algunos se hace referencia tanto al ID como al secreto como la clave de API. En algunos se hace referencia 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 la app realiza a los proxies de API que se incluyen en el producto de API.

Apigee también admite la capacidad de importar claves de API existentes desde 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, a través de la organización de una interacción de aprobación entre el propietario del recurso y el servicio HTTP, o al permitir que la aplicación de terceros obtenga acceso en su propio 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 de OAuthv2. El consumidor debe estar registrado y tener una app aprobada que le haya otorgado acceso a la API. A cambio, recibirán un ID de cliente de API y un secreto de 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 web JSON (o JWT) se usan comúnmente para compartir reclamaciones o confirmaciones entre aplicaciones conectadas. Apigee proporciona compatibilidad con JWT mediante tres políticas.

  • Generar tokens JWT (admite firmas HS256 y RS256)
  • Validar tokens JWT
  • Decodifica tokens JWT sin validarlos

A3:2017: Exposición de datos sensibles

Los atacantes se enfocan en datos sensibles, como detalles de tarjetas 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 robos de identidad, robos de dinero, fraudes y otros delitos. Las aplicaciones web deben implementar la encriptación, tanto en reposo como en tránsito, además de otras estrategias para garantizar la protección de 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.

La TLS en sentido norte (el cliente que se conecta a la API que actúa como servidor) es compatible con el uso de una configuración de host virtual. Se puede configurar un host virtual para TLS unidireccional o bidireccional.

La TLS de límite sur (apigee como un cliente que se conecta al servicio de backend) es compatible con una configuración de servidor de destino. Un servidor de destino puede configurarse para TLS unidireccional o bidireccional.

Apigee admite muchas opciones de configuración de TLS.

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

En Apigee híbrido, TLS está disponible en la entrada a través de un alias de host, que es un concepto similar al de 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 deAssignMessage y la política de JavaScript para quitar los datos sensibles antes de que se muestren al cliente.
  • Usa técnicas de OAuth estándar y considera agregar HMAC, hash, estado, nonce, PKCE o cualquier otra técnica para mejorar el nivel de autenticación de cada solicitud.
  • Usa la configuración de enmascaramiento de datos para enmascarar los datos sensibles en la herramienta de Edge Trace.
  • Ten cuidado cuando almacenes datos sensibles en la caché (o encripta los datos sensibles almacenados en ella). En Edge, puedes encriptar datos sensibles en reposo en mapas clave-valor.

A4:2017: Entidades externas XML

Los sistemas o las aplicaciones que procesan XML deben manejar "referencias a entidades externas" en XML, es decir, referencias a archivos o datos que se reemplazan por los datos reales durante el procesamiento en formato 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 del servicio.

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

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

A5:2017: Control de acceso dañado

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

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

Controles de acceso para la IU de Edge

Controles de acceso para el portal de 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 necesitan en los portales para desarrolladores basados en Drupal.
  • Configura portales para desarrolladores a fin de mostrar productos de API específicos según el rol del usuario.
  • Configura el portal para ocultar o mostrar contenido según el rol del usuario.

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

  • El acceso a las APIs se puede aplicar mediante claves de API, tokens de OAuth, permisos de OAuth, certificados y otras técnicas.
  • El proveedor de la API configura los recursos que 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 Management o a través del portal para desarrolladores. Cuando la app de un desarrollador obtiene acceso a un producto de API, este recibe un ID de cliente y un secreto que se usan en el proceso de autenticación.
  • Apigee puede integrarse en cualquier proveedor de identidad para ejecutar OAuth.
  • Apigee puede generar tokens JWT y 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 la seguridad

Las configuraciones incorrectas de seguridad son fáciles de pasar por alto, a menudo porque los administradores y desarrolladores confían erróneamente que los sistemas que usan son de seguridad inherente. La configuración incorrecta de la seguridad puede ocurrir de muchas maneras diferentes, como confiar en configuraciones predeterminadas o establecer parámetros de configuración parciales que pueden ser inseguros, permitir que los mensajes de error contengan detalles sensibles, almacenar datos en la nube sin los controles de seguridad adecuados, configurar de forma incorrecta los encabezados HTTP, etcétera. La plataforma de Apigee proporciona una serie de mecanismos que te permiten controlar, administrar y supervisar la configuración de seguridad, incluidos los flujos compartidos reutilizables.

Un flujo compartido permite a los desarrolladores de API combinar políticas y recursos en un grupo reutilizable. Mediante la captura de funciones reutilizables en un solo lugar, un flujo compartido te ayuda a garantizar la coherencia, reducir el tiempo de desarrollo y administrar el código con mayor facilidad. Puedes incluir un flujo compartido dentro de proxies de API individuales o puedes ir un paso más allá y colocar los 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.

Los lanzamientos de productos de Apigee garantizan la protección contra las bibliotecas con vulnerabilidades. Es posible que Apigee publique parches o actualizaciones adicionales si se encuentran nuevas vulnerabilidades. Se aplican parches automáticamente a la nube pública perimetral. Los clientes de Edge para la nube privada (local) deben aplicar parches de productos ellos mismos.

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

La secuencia de comandos entre sitios (XSS) permite que los atacantes ejecuten secuencias de comandos en los navegadores web de los usuarios para controlar las sesiones de los usuarios, manipular sitios web o tener un impacto malicioso de otras maneras en los usuarios. 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 los valores de la carga útil y los parámetros para JavaScript y otros ataques de inyección.

CORS, una de las soluciones que se suelen implementar en la política del mismo origen que se aplican a todos los navegadores, puede implementarse mediante la políticaAssignMessage.

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 inyección. La deserialización no segura también puede habilitar la ejecución remota de código.

Apigee no recomienda la deserialización. Sin embargo, la política JSONThreatProtection y la política RegularExpressionProtection pueden ayudar a protegerte contra cargas útiles JSON maliciosas. 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 reinyección. A nivel de la infraestructura, la plataforma de Apigee también tiene barreras de seguridad integradas para proteger los procesos en ejecución.

A9:2017: Cómo usar componentes con vulnerabilidades conocidas

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

Los lanzamientos habituales de productos de Apigee garantizan la protección contra las vulnerabilidades de los componentes, en especial cuando se descubren vulnerabilidades específicas. Los parches de la nube pública de Apigee se aplican automáticamente, y Apigee notifica a Edge de los clientes de la nube privada cuando los parches locales están disponibles para su instalación.

A10:2017: Registro y supervisión insuficientes

Cuando no realizas un registro, supervisión o 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 con la política de MessageLogging.
  • Los datos de las estadísticas de las APIs se pueden extraer a través de la API de Analytics y se pueden importar o exportar a otros sistemas.
  • En Edge para la nube privada, puedes usar la política MessageLogging para escribir en 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 o la API de Supervisión de API para supervisar con regularidad las APIs y los backends, y activar los APK.
  • Usa la supervisión de estado para supervisar con regularidad los backends del servidor de destino.
  • Apigee proporciona recomendaciones para supervisar Edge en la nube privada.
  • Apigee también proporciona prácticas recomendadas que tu equipo puede aprovechar para supervisar el programa de APIs.

Manejo de errores

Apigee ofrece un mecanismo de manejo de errores potente y versátil para los proxies de API. Así como 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 funcionalidades 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 de la API de Audits.

Soluciones de Apigee para vulnerabilidades de OWASP de 2013

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

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

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

Normas:

  • Esto se debe más a un problema del navegador, no a un 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 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 previstos, los atacantes pueden enviar a los usuarios a destinos maliciosos para realizar suplantación de identidad (phishing), ejecutar software malicioso y otros.

Normas:

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