File .env, backup e configurazioni esposte: cosa controllare

Ci sono file che normalmente non dovrebbero mai essere accessibili direttamente dal browser.

Un esempio molto conosciuto è:

.env

Ma non è l'unico.

Nel corso dello sviluppo di un'applicazione possono finire nella directory pubblica anche:

config.php
database.php
backup.zip
site-backup.tar.gz
database.sql
config.php.bak
index.php.old

A volte rimangono lì per errore.

Ed è proprio questo il problema.

Il web server vede più cose di quelle che dovrebbe?

Quando un'applicazione viene pubblicata, esiste una directory che il web server espone agli utenti.

Ad esempio:

/var/www/example/public_html/

Tutto ciò che viene inserito nella directory pubblica deve essere considerato potenzialmente raggiungibile tramite HTTP, a meno che il server non ne impedisca esplicitamente l'accesso.

Un'applicazione potrebbe avere una struttura simile:

public_html/
├── index.php
├── assets/
├── uploads/
├── .env
├── backup.zip
└── config.php

La presenza di questi file non significa automaticamente che siano accessibili.

Ma è sicuramente qualcosa da verificare.

Perché .env è così delicato?

Molte applicazioni utilizzano file .env per conservare variabili di configurazione.

Un esempio potrebbe essere:

DB_HOST=localhost
DB_NAME=mydatabase
DB_USER=appuser
DB_PASSWORD=********
APP_ENV=production
API_KEY=********

Il contenuto reale varia in base all'applicazione, ma il principio è semplice:

un file di configurazione contenente segreti non dovrebbe essere servito dal web server.

Il problema diventa particolarmente serio se il file è direttamente scaricabile tramite:

https://example.com/.env

Lo stesso ragionamento vale per altri file di configurazione che possono contenere:

• password;
• token;
• chiavi API;
• credenziali database;
• percorsi interni;
• configurazioni dell'applicazione.

I backup sono un altro problema comune

Durante lo sviluppo o la manutenzione capita facilmente di creare copie temporanee:

index.php.bak
index.php.old
config.php~
backup.zip
website-backup.zip
database.sql

Il problema è che un backup può contenere molte più informazioni rispetto a una singola pagina.

Un archivio potrebbe includere:

/config
/app
/database
/uploads
/vendor

e quindi rivelare una parte significativa della struttura dell'applicazione.

Per questo i backup dovrebbero essere conservati in posizioni non pubbliche e gestiti con procedure appropriate.

Anche un file "vecchio" può essere pericoloso

Immaginiamo di avere:

login.php
login.php.old

La versione attuale potrebbe essere stata corretta mesi fa.

La vecchia copia potrebbe però contenere ancora:

• codice vulnerabile;
• configurazioni obsolete;
• credenziali;
• percorsi interni;
• informazioni sull'architettura.

Quindi eliminare una vulnerabilità dal file attuale non è sufficiente se una vecchia copia dello stesso codice rimane accessibile.

Non sono soltanto i file .env

Quando si parla di file sensibili, è facile concentrarsi esclusivamente su .env.

In realtà è necessario ragionare sul contesto.

Alcuni esempi di elementi che meritano una verifica sono:

.env
*.bak
*.old
*.backup
*.sql
*.zip
*.tar
*.gz
*.log

ma anche file specifici dell'applicazione:

config.php
settings.php
database.php
credentials.json

Non significa che ogni file con queste estensioni sia necessariamente vulnerabile.

Un archivio pubblico destinato al download, per esempio, può essere perfettamente legittimo.

Il punto è capire cosa contiene e perché è pubblico.

Come controllare una configurazione web

Una prima verifica può essere effettuata cercando file che non dovrebbero trovarsi nella directory pubblica.

Su un server Linux, ad esempio:

find /var/www/example/public_html -type f

Per cercare alcuni nomi particolarmente interessanti:

find /var/www/example/public_html \
  \( -name ".env" -o -name "*.bak" -o -name "*.old" -o -name "*.sql" -o -name "*.zip" \)

Questo controllo viene eseguito direttamente sul server.

Ma c'è anche un'altra domanda da porsi:

Questi file sono effettivamente raggiungibili da Internet?

Perché un file presente sul filesystem non è necessariamente un file pubblicamente accessibile.

Il controllo dall'esterno

Da un punto di vista di sicurezza esterna, ciò che interessa è il comportamento osservabile via HTTP.

Per esempio:

https://example.com/.env

oppure:

https://example.com/backup.zip

Un controllo di questo tipo deve essere effettuato esclusivamente su sistemi che si è autorizzati a verificare.

Anche la risposta HTTP deve essere interpretata correttamente.

Un:

HTTP/2 404

è un'indicazione diversa da:

HTTP/2 200
Content-Type: application/octet-stream

Ma anche un 200 non significa automaticamente che il contenuto sia sensibile.

Serve verificare cosa viene realmente restituito.

Attenzione ai falsi positivi

Questo è particolarmente importante nei security scanner.

Alcuni server restituiscono una pagina personalizzata anche quando la risorsa richiesta non esiste.

Per esempio:

GET /.env

potrebbe restituire:

HTTP/2 200

ma contenere semplicemente una pagina HTML del sito.

In questo caso lo status code da solo non è sufficiente.

Bisogna analizzare anche:

• Content-Type;
• dimensione della risposta;
• contenuto;
• fingerprint della pagina;
• eventuali redirect;
• comportamento del server.

È proprio per questo che una rilevazione automatica dovrebbe essere considerata un segnale da verificare, non una prova definitiva.

Come prevenire il problema

La soluzione migliore è evitare che i file sensibili vengano inseriti nella directory pubblica.

Una struttura più sicura può essere, ad esempio:

/var/www/example/
├── app/
├── config/
├── storage/
└── public_html/
    ├── index.php
    ├── assets/
    └── uploads/

In questo modo il document root contiene soltanto ciò che deve essere servito dal web server.

Naturalmente la struttura dipende dal framework e dall'architettura utilizzata, ma il principio rimane valido:

ciò che non deve essere pubblico non dovrebbe stare nella directory pubblica.

Una checklist per il controllo

Prima di mettere online un'applicazione, controlla:

• [ ] .env non è pubblicamente accessibile;
• [ ] file di configurazione sensibili non sono esposti;
• [ ] non ci sono backup nella directory pubblica;
• [ ] non ci sono dump del database accessibili;
• [ ] non sono presenti vecchie copie dei file;
• [ ] log e file temporanei non sono pubblici;
• [ ] gli archivi di backup vengono conservati fuori dal document root;
• [ ] le risposte HTTP vengono verificate, non soltanto gli status code;
• [ ] i file inutilizzati vengono rimossi.

Il problema dei file dimenticati

Questo tipo di esposizione è interessante perché spesso non nasce da una vulnerabilità sofisticata.

Può essere sufficiente:

"Faccio una copia prima di modificare il file."

oppure:

"Carico il backup sul server e poi lo sposto."

Il problema arriva quando quel file viene dimenticato.

Dopo settimane o mesi, nessuno potrebbe più ricordarsi che:

backup-2025.zip

si trova ancora nella directory pubblica.

Nel frattempo, però, il server continua a servirlo.

MiHakero e i file esposti

La sicurezza esterna serve anche a individuare questo genere di situazioni.

Non tutto ciò che viene rilevato è necessariamente una vulnerabilità critica, ma un file inatteso può rappresentare un'informazione importante da verificare.

L'obiettivo è semplice: sapere cosa è realmente pubblico prima che qualcun altro lo scopra.

Perché nella sicurezza web, a volte, il problema non è quello che abbiamo deciso di pubblicare.

È quello che abbiamo dimenticato di togliere.