7. Evaluando los riesgos de seguridad de las Mule Application


Como arquitecto debes evaluar los riesgos a los que te estás enfrentando con una aplicación o API.

 

Riesgos de Seguridad en Mule

En el entorno de desarrollo de Mule, enfrentamos diversos riesgos de seguridad que pueden comprometer nuestras aplicaciones. Estos incluyen:

 

1. Riesgos de Inyección

La inyección es un riesgo común donde los atacantes introducen datos maliciosos. Esto puede ocurrir en:

  • Operaciones de base de datos como ‘Execute Script’ y ‘Execute DDL’.
  • Extracción de XPath donde pueden ejecutar elementos no deseados en un archivo XML.
  • Plantillas de análisis (Parse Template) que pueden exponer propiedades seguras si el sistema de archivos no está protegido.
  • Cabeceras HTTP donde valores maliciosos pueden provocar un ataque de denegación de servicio (DoS).
Prevención:
  • Utiliza operaciones de módulo de validación y otras técnicas de codificación defensiva.
  • Prefiere las variables de enlace en consultas SQL en lugar de la manipulación de cadenas de texto.
  • Evita consultas dinámicas.
  • Aplica validación de esquemas utilizando el enrutador de APIkit o esquemas XML/JSON.

Una medida efectiva para protegerse contra inyecciones es utilizar parámetros de entrada (input parameters) en lugar de concatenar cadenas de texto en las consultas SQL. Esto requiere una colaboración estrecha con los desarrolladores durante la implementación de la aplicación, asegurando que el código se escriba con la seguridad en mente desde el principio.

2. Riesgos de Autenticación y Gestión de Sesión

Los riesgos aquí incluyen:

  • Proveedores de autenticación que almacenan credenciales de usuario en texto plano.
  • Conectores que envían contraseñas, identificadores de sesión o credenciales en URLs no encriptadas.
  • Sesiones de OAuth que no se invalidan después del cierre de sesión.
Prevención:
  • Almacena credenciales utilizando cifrado o hashing.
  • Utiliza archivos de propiedades seguras para implementaciones alojadas por el cliente y propiedades ocultas seguras para implementaciones de CloudHub.
  • Emplea conexiones seguras para la comunicación.
  • Invalida las sesiones de forma oportuna.

 

3. Riesgos por Configuración de Seguridad Inadecuada

Los peligros surgen de:

  • Fuentes de eventos no utilizadas y conectores que pueden conducir al uso no intencionado de recursos de la aplicación.
  • Puertos no utilizados o caminos a través de oyentes HTTP que pueden ofrecer acceso no deseado a la aplicación.
Prevención:
  • Fortalece las aplicaciones Mule y asegura adecuadamente el entorno desplegado.
  • Utiliza una arquitectura sólida.
  • Realiza escaneos de seguridad y auditorías periódicas.
  • Estandariza el manejo de errores sin proporcionar información innecesaria o insegura sobre el sistema subyacente.

 

4. Riesgos por Exposición de Datos Sensibles

Puede ocurrir cuando:

  • Las propiedades de la aplicación permiten que los atacantes lean credenciales del sistema, lo que podría desencadenar un ataque de día cero.
  • Almacenes persistentes como el Object Store o archivos no están privados para información sensible.
  • Los almacenes de certificados de seguridad no están protegidos y permiten el acceso a servicios no intencionados en la red.
Prevención:
  • Usa propiedades seguras.
  • Implementa cifrado, hashing o enmascaramiento para datos sensibles (PII o PCI).
  • Protege el acceso a los recursos utilizando la seguridad empresarial de Anypoint Platform o los permisos/grants a nivel de sistema operativo o máquina virtual (OS/VM).

 

5. Riesgos al Utilizar Componentes con Vulnerabilidades Conocidas

Los componentes vulnerables pueden ser identificados y explotados, como:

  • El uso de TLS 1.0 en HTTP/S, SFTP/S y Socket, que es susceptible a ataques de intermediarios.
  • Bibliotecas personalizadas no probadas que podrían ser explotadas, como la vulnerabilidad de Struts en Apache.
Prevención:
  • Emplea TLS 1.2/1.1 y evita versiones obsoletas como TLS 1.0/SSL 3.0.
  • Utiliza únicamente bibliotecas empresariales aprobadas.
  • Realiza análisis de código estático y dinámico de fuentes de Java o bytecode.

 

OWASP: Marco de Referencia para la Seguridad

El proyecto OWASP proporciona un marco de referencia para mitigar los 10 riesgos más comunes de seguridad (y no solo ellos), siendo adoptado por 9 de cada 10 empresas. Este recurso es crucial para desarrolladores y arquitectos de seguridad, ya que ofrece directrices detalladas para proteger aplicaciones contra vulnerabilidades. Encuentra más información y recursos en OWASP Top Ten.

 

Conclusión

Como arquitecto de soluciones MuleSoft, tu papel es fundamental para garantizar la seguridad de las aplicaciones. Al comprender y aplicar las prácticas de prevención contra riesgos comunes, no solo mejorarás la robustez de tus aplicaciones sino que también contribuirás a la seguridad general del ecosistema de TI de tu organización. Mantente actualizado con las últimas tendencias y herramientas de seguridad, y colabora con tu equipo de desarrollo para implementar las mejores prácticas desde la base del código hasta la infraestructura de producción.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *