Archivos .env, .git y copias de seguridad expuestos: cómo se filtran secretos desde una web

Algunas de las filtraciones web más dañinas no requieren ningún ataque. Un archivo que nunca debió ser público está en la raíz web, el servidor se lo envía sin problema a quien lo pida, y ese archivo contiene una contraseña de base de datos, una clave de API o el código fuente completo del sitio.

Los 3 sospechosos habituales son los archivos .env con secretos de configuración, las carpetas .git que contienen todo el historial del repositorio y las copias de seguridad como site.zip, db.sql o config.php.bak. La OWASP Web Security Testing Guide los recoge todos como fuentes típicas de credenciales y código fuente expuestos.

Puede revisar su propio sitio en pocos minutos con curl.

Cómo acaban siendo accesibles estos archivos

• Archivos .env. Muchos frameworks leen los secretos de un archivo .env en la carpeta del proyecto. Si la raíz de documentos del servidor web es la carpeta del proyecto y no su subcarpeta public, el archivo se sirve como cualquier otro.
• Carpetas .git. Desplegar ejecutando git clone o git pull directamente en la raíz web deja el directorio .git junto al sitio. Con él, cualquiera puede reconstruir el código fuente y todos los commits anteriores, incluidos secretos que se "eliminaron" hace tiempo.
• Copias y volcados. Un zip rápido antes de una actualización, una exportación db.sql para una migración, una copia del editor como index.php~ o config.php.old. OWASP señala que la copia de un script puede servirse como texto plano en lugar de ejecutarse, lo que revela su código.
• Restos de herramientas. phpinfo.php, .htpasswd, .DS_Store, archivos de estado de Terraform y archivos de log aparecen de la misma manera.

El denominador común es editar o desplegar directamente en el servidor de producción sin un paso que decida qué debe estar en la raíz web.

Cómo revisar su propio sitio

Solicite las rutas más habituales y fíjese en el código de estado y en el tamaño de cada respuesta:

for p in .env .git/HEAD .git/config backup.zip site.zip db.sql \
         dump.sql config.php.bak wp-config.php.bak phpinfo.php .DS_Store; do
  printf '%-22s ' "$p"
  curl -s -o /dev/null -w '%{http_code} %{size_download}\n' "https://yourcompany.com/$p"
done

Qué significan los resultados:

• 404 o 403 en todas las rutas es lo que quiere ver.
• 200 con contenido real es un hallazgo. En .git/HEAD, el contenido real se parece a ref: refs/heads/main. En .env, son líneas del tipo NAME=value.
• 200 con su página de inicio normal o una página de error personalizada suele ser un "soft 404". OWASP advierte que una coincidencia por sí sola no es un hallazgo: abra la respuesta y confirme qué contiene realmente.

Repita la comprobación en cada nombre de host que gestione, incluidos los de staging y los subdominios antiguos. Ahí es donde estos archivos sobreviven más tiempo, como se explica en nuestro artículo sobre servidores de staging y de pruebas olvidados. Los archivos web también pueden guardar copias de archivos que fueron accesibles en el pasado, así que un archivo que acaba de eliminar quizá ya lo haya visto alguien.

Si se expuso un secreto, cámbielo primero

Borrar el archivo detiene las nuevas descargas, pero no puede saber quién lo copió ya. Considere comprometido cada secreto de un archivo expuesto:

1. Cambie o revoque cada contraseña, clave de API y token del archivo. La guía de GitHub sobre eliminar datos sensibles da el mismo orden: primero revocar o cambiar el secreto, después limpiar el historial.
2. Elimine el archivo del servidor y de cualquier carpeta de copias dentro de la raíz web.
3. Revise los logs de acceso en busca de peticiones a esa ruta para saber si se descargó y cuándo.
4. Compruebe a qué daba acceso la clave: consolas en la nube, proveedores de pago, servicios de correo, y busque actividad que no sepa explicar.

Si los secretos se subieron a un repositorio, reescribir el historial (GitHub recomienda git-filter-repo) solo sirve cuando el propio secreto ya no es válido.

Cómo evitarlo

• Haga que la raíz de documentos apunte solo a la carpeta pública, nunca a la raíz del proyecto.
• Despliegue artefactos de compilación, no copias de trabajo. Un pipeline de CI que copia solo los archivos que necesita el sitio deja fuera .git y .env por diseño.
• Bloquee los archivos que empiezan por punto en el servidor web, como se muestra más abajo.
• Saque los secretos de los archivos siempre que pueda: use las variables de entorno de su plataforma o un gestor de secretos.
• No guarde nunca copias ni volcados en la raíz web. OWASP recomienda mantener los datos, los logs y los archivos de configuración donde el servidor web no pueda servirlos.
• Vuelva a comprobarlo tras cada cambio de infraestructura, incluidos los servidores nuevos detrás de un balanceador de carga.

Bloquear los archivos que empiezan por punto (conservando /.well-known/, que necesita la renovación de certificados) se hace así en nginx:

location ~ /\.(?!well-known) {
    deny all;
}

Y así en la configuración de un sitio en Apache:

RedirectMatch 404 /\.(?!well-known)

Una lista de comprobación breve

• Ejecute el bucle de curl anterior en cada nombre de host que posea.
• Confirme cada 200 leyendo el contenido.
• Cambie cualquier secreto que haya sido accesible en algún momento.
• Bloquee los archivos que empiezan por punto y las extensiones de copias en la configuración del servidor web.
• Pase los despliegues a un pipeline que solo publique archivos compilados.

Ya que está en la configuración del servidor, es buen momento para añadir las cabeceras de seguridad HTTP que toda web empresarial debería enviar.

Cómo ayuda Datahorses

Datahorses vigila su sitio web desde fuera tal como lo miraría un atacante, y señala los archivos .git, .env, copias de seguridad y archivos de configuración expuestos que los archivos web han registrado en sus dominios. No entramos en sus sistemas y no necesitamos accesos; su desarrollador recibe los pasos exactos para eliminar el archivo y cambiar lo que se filtró. Consulte cómo vigilamos y por qué no necesitamos accesos.