Errores de configuración: fallos que no están en el código

Qué es

Muchas vulnerabilidades no vienen de un error de programación, sino de cómo está montado el sistema: un servicio que se dejó abierto, una opción por defecto que nadie cambió o un registro DNS que apunta a algo que ya no existe. El código puede ser perfecto y la aplicación seguir siendo vulnerable.

Ejemplos frecuentes

• Toma de subdominio (subdomain takeover): un subdominio sigue apuntando a un servicio externo (alojamiento, almacenamiento en la nube) que la empresa ya no usa. Si un tercero puede reclamar ese recurso, sirve contenido bajo el dominio de la empresa.
• CORS demasiado permisivo: el servidor refleja cualquier Origin y además permite credenciales, de modo que otra web puede leer respuestas con la sesión del usuario.
• Paneles y servicios expuestos: consolas de administración, bases de datos, herramientas de monitorización o depuración accesibles desde Internet.
• Ficheros que no deberían publicarse: .git, copias de seguridad, ficheros de configuración o listados de directorios.
• Almacenamiento en la nube público: contenedores con permisos de lectura o escritura para cualquiera.
• Cabeceras de seguridad ausentes, que solo suelen tener interés si permiten un ataque concreto.

Cómo se busca

1. Enumera los subdominios del programa (dentro del alcance) y revisa a dónde apunta cada uno. Los que devuelven errores de servicios externos son candidatos a toma.
2. Envía peticiones con un Origin propio y mira las cabeceras Access-Control-Allow-Origin y Access-Control-Allow-Credentials de la respuesta.
3. Busca rutas habituales de ficheros sensibles y paneles conocidos.
4. Revisa las versiones de los servicios expuestos.

Cómo se evita

• Inventario de dominios y servicios: borrar los registros DNS al retirar un servicio.
• CORS con una lista fija de orígenes permitidos.
• Paneles y servicios internos detrás de una VPN o con control de acceso, nunca abiertos a Internet.
• Revisar los permisos del almacenamiento en la nube y no desplegar ficheros de desarrollo.

Al reportarlo

Demuestra el impacto real, no solo la mala configuración: muchos programas no aceptan reportes de cabeceras ausentes o servicios expuestos si no se muestra qué permiten hacer. En una toma de subdominio, basta con una página inocua que lo pruebe.