Portada » Home » Buenas Prácticas de Desarrollo Seguro: A6 – Configuración de seguridad incorrecta

Buenas Prácticas de Desarrollo Seguro: A6 – Configuración de seguridad incorrecta

Los problemas de configuración o configuraciones por defecto pueden comprometer un sistema completo. Es importante configurar de forma personalizada los componentes que se utilizan y evitar usar configuraciones genéricas. 

Las configuraciones incorrectas de seguridad no están exentas a ningún sistema tecnológico, como los servicios de red, la plataforma, el servidor web, el servidor de aplicaciones, la base de datos, frameworks, el código personalizado y máquinas virtuales preinstaladas, etc.

Las configuraciones erróneas de seguridad aún abundan en muchas aplicaciones web. No actualizar aplicaciones/software (el sistema operativo, las bibliotecas de códigos, el servidor de aplicaciones / web, la base de datos) es sólo una de las causas de errores de configuración de seguridad, ya que hay muchas otras: Por ejemplo, las cuentas y contraseñas predeterminadas aún están disponibles, o no se han modificado, el manejo de errores no está configurado correctamente  dando como resultado la fuga de información sensible. Servicios innecesarios, puertos. Entre muchos otros problemas.

Las configuraciones erróneas de seguridad lógicamente se pueden reducir. Primero, hay que partir asegurándose de tener entornos reforzados idénticos (desarrollo, control de calidad y producción), además de verificar tener implementado un proceso de administración de parches que no solo aborde parches en el sistema operativo, DB y aplicaciones, sino también en las bibliotecas de códigos que se utilizan para el aplicaciones. Una auditoria periódica ayudará bastante para asegurarse que la organización esté al tanto de actualizaciones faltantes.

¿Cómo saber si es vulnerable?

OWASP nos muestra algunos ejemplos en el siguiente listado:

  • Falta hardening adecuado en cualquier parte del stack tecnológico, o permisos mal configurados en los servicios de la nube.
  • Se encuentran instaladas o habilitadas características innecesarias (ej. puertos, servicios, páginas, cuentas o permisos).
  • Las cuentas predeterminadas y sus contraseñas siguen activas y sin cambios.
  • El manejo de errores revela a los usuarios trazas de la aplicación u otros mensajes demasiado informativos.
  • Para los sistemas actualizados, las nuevas funciones de seguridad se encuentran desactivadas o no se encuentran configuradas de forma adecuada o segura.
  • Las configuraciones de seguridad en el servidor de aplicaciones, en el framework de aplicación (ej., Struts, Spring, ASP.NET), bibliotecas o bases de datos no se encuentran especificados con valores seguros.
  • El servidor no envía directrices o cabeceras de seguridad a los clientes o se encuentran configurados con valores inseguros.
  • El software se encuentra desactualizado o posee vulnerabilidades (ver A9: 2017 Uso de componentes con vulnerabilidades conocidas).

Ejemplos concretos son: S3 buckets abiertos, cabeceras HTTP mal configuradas, mensajes de error con contenido sensible, falta de parches y actualizaciones, frameworks, etc.

Los escáneres automatizados son útiles para detectar configuraciones erróneas, el uso de cuentas o configuraciones predeterminadas, servicios innecesarios, opciones heredadas, etc.

Además de los siguientes puntos: 

  • Proceso de fortalecimiento reproducible que agilice y facilite la implementación de otro entorno asegurado. Los entornos de desarrollo, de control de calidad (QA) y de Producción deben configurarse de manera idéntica y con diferentes credenciales para cada entorno. Este proceso puede automatizarse para minimizar el esfuerzo requerido para configurar cada nuevo entorno seguro.
  • Use una plataforma minimalista sin funcionalidades innecesarias, componentes, documentación o ejemplos. Elimine o no instale frameworks y funcionalidades no utilizadas.
  • Siga un proceso para revisar y actualizar las configuraciones apropiadas de acuerdo a las advertencias de seguridad y siga un proceso de gestión de parches. En particular, revise los permisos de almacenamiento en la nube (por ejemplo, los permisos de buckets S3).
  • La aplicación debe tener una arquitectura segmentada que proporcione una separación efectiva y segura entre componentes y acceso a terceros, contenedores o grupos de seguridad en la nube (ACLs).
  • Envíe directivas de seguridad a los clientes (por ej. cabeceras de seguridad).
  • Utilice un proceso automatizado para verificar la efectividad de los ajustes y configuraciones en todos los ambientes.

El atacante

Por lo general intentará explotar vulnerabilidades que no han sido parchadas, o acceder a cuentas por defecto, páginas no utilizadas, archivos y directorios desprotegidos, etc. de este modo obtendrá acceso o conocimiento del sistema.

¿Cómo prevenir?

A modo general, se recomiendan las siguientes medidas de mitigación:

  • No utilizar contraseñas comunes
  • No utilizar usuarios genéricos
  • No usar configuraciones por defecto
  • Configurar correctamente los permisos y propietarios de directorios y archivos
  • No utilizar componentes con vulnerabilidades conocidas
  • Mantener actualizado los sistemas
  • Configurar las cabeceras HTTP de forma correcta
  • Implementar SSL/TLS de forma correcta
  • No habilitar el modo debug en produccion
  • Evitar mostrar errores de base de datos, sistema operativo o de framework
  • Deshabilitar la opción «Directory Listing»
  • Evitar exponer componentes y versiones en las cabeceras o en las rutas de archivos

More Reading

Post navigation