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

Descripción general

Los ecosistemas de API experimentan varios ataques de clientes externos y también internos. Ofrecer y usar APIs crea grandes oportunidades para los proveedores de servicios, pero también representa algunos riesgos de seguridad. Los desarrolladores deben ser conscientes de 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 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.

Con Apigee, la capa de proxy de API puede detectar, bloquear e informar solicitudes a la API con el 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 el formato incorrecto pueden incluir cualquier componente que forme parte del protocolo HTTP a nivel de la aplicación:

  • URL
  • Encabezados
  • Ruta
  • Carga útil

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

La plataforma de administración de APIs inteligente de Apigee te permite abordar las vulnerabilidades de seguridad de las APIs de OWASP más importantes 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 las políticas o la configuración que Apigee recomienda para las principales amenazas de OWASP de REST.

Soluciones de Apigee para los 10 principales de OWASP de 2017

Existen muchas preocupaciones de seguridad cuando se trata de compilar y proteger aplicaciones web. OWASP publicó su lista de las 10 amenazas de seguridad de OWASP más importantes 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 muestran las principales amenazas de seguridad de OWASP con descripciones de cómo puedes usar Apigee para abordarlas.

A1:2017 - Inyecció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 entradas para verificar que los valores proporcionados por un cliente coincidan con las expectativas 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 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 para 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 dañada y administración de la sesión

Los atacantes pueden acceder a contraseñas, tokens de sesión y claves para suplantar la identidad de otros usuarios aprovechando las fallas de implementación en las aplicaciones. Este es más un problema de implementación que 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. Luego, 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 asistencia 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" puede tener diferentes significados. En Apigee, cuando se forma la relación entre la app y el producto, Apigee genera un ID de cliente y un secreto de cliente.  Algunos se refieren al ID y al secreto como la clave de API. Algunos solo se refieren 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.

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

OAuth 2.0

El framework 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 recursos mediante la organización de una interacción de aprobación entre el propietario del recurso y el servicio HTTP, o permitiendo 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 forzosa de tokens 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á un ID de cliente y un secreto de cliente de la API. El consumidor debe pasar por una de las concesiones 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 (JWT) se usan comúnmente para compartir reclamaciones o confirmaciones entre aplicaciones conectadas. Apigee proporciona compatibilidad con JWT mediante tres políticas.

  • Tokens de GenerateJWT (admite firmas HS256 y RS256)
  • Tokens de ValidateJWT
  • Cómo decodificar tokens de DecodeJWT sin validar

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 IDs fiscales 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, 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.

El TLS orientado al norte (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.

El TLS de salida (Apigee como cliente que se conecta al servicio de backend) es compatible con 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 forzosa 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 al de un host virtual.

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

  • Usa una plataforma que admita TLS unidireccional y bidireccional, que brindará protección a nivel del protocolo.
  • Usa políticas, como la política de AssignMessage 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 de 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 par clave-valor.

A4:2017 - Entidades externas XML

Los sistemas o las aplicaciones que procesan XML deben controlar las "referencias de entidades externas" en XML, que son referencias a archivos o datos que se reemplazan por 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 piratear los datos y usarlos para robar información o lanzar varios tipos de ataques al sistema, como denegación del servicio.

La política 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, las rutas de URI, las cargas útiles de JSON/XML, los parámetros de formulario y los 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, 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 - Broken Access Control

Después de que los usuarios acceden a un sistema, se deben implementar los controles de autorización adecuados para que puedan ver y hacer solo lo que tienen permitido. 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 roles (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 los portales para desarrolladores para mostrar productos de API específicos según el rol del usuario.
  • Configura el portal para ocultar o mostrar el 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 a través de claves de API, tokens de OAuth, permisos de OAuth, certificados y otras técnicas.
  • El proveedor de la API configura qué recursos están disponibles definiendo un producto de API. El acceso se otorga de forma manual en la IU, a través de la API de administración o del portal para desarrolladores. Cuando se le otorga acceso a un producto de API a la app de un desarrollador, este recibe un ID de cliente y un secreto que se usan en el proceso de autenticación.
  • Apigee se puede integrar en 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

Es fácil pasar por alto las configuraciones de seguridad incorrectas, a menudo porque los administradores y 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, como confiar en configuraciones predeterminadas o hacer configuraciones parciales que podrían ser no seguras, permitir que los mensajes de error contengan detalles 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 que te permiten 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 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.

Los lanzamientos de productos de Apigee garantizan la protección contra bibliotecas con vulnerabilidades. Es posible que Apigee lance parches o actualizaciones adicionales si se encuentran nuevas vulnerabilidades. La nube pública de Edge se actualiza automáticamente. Los clientes de Edge para nube privada (local) deben aplicar los parches del producto por su cuenta.

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 se relacionan necesariamente 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 ataques de inserción.

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 de AssignMessage.

A8:2017 - Deserialización no segura

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 desserialización. Sin embargo, la política JSONThreatProtection y la política RegularExpressionProtection pueden ayudar a protegerte contra cargas útiles de 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 proteger 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 ejecución completa y acceso a CRUD, los atacantes pueden aprovechar las vulnerabilidades de los componentes para atacar los sistemas.

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

A10:2017: Registro y supervisión insuficientes

Cuando 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 otros extremos 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 para 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 o la API de API de Monitoring 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 para 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 control de errores 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 auditorías.

Soluciones de Apigee para las vulnerabilidades de OWASP de 2013

Cuando OWASP actualizó su lista para 2017, se omitieron algunas vulnerabilidades de la lista de 2013. Aún son amenazas válidas. En las siguientes secciones, se describe cómo manejar 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 la 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 de confianza, los atacantes pueden enviar a los usuarios a destinos maliciosos para realizar phishing, ejecutar 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 la API y controla los redireccionamientos de forma adecuada.