Scanner di file sensibili

Come funziona questo controllo

Scanaris richiede una lista di percorsi dove spesso restano file che non dovrebbero mai stare su un server pubblico: .env, .env.local, .env.production, .git/config, .git/HEAD, wp-config.php, config.json, docker-compose.yml, backup.sql, phpinfo.php, .npmrc, Dockerfile, .gitlab-ci.yml, .aws/credentials, .ssh/id_rsa, web.config, adminer.php e .DS_Store. Un 200 non basta a segnalare nulla: molte applicazioni a pagina singola rispondono 200 con il loro HTML a qualsiasi percorso. Per questo lo scanner verifica che il contenuto sembri reale, per esempio che un .env abbia righe CHIAVE=valore e non sia HTML, o che .git/HEAD inizi con ref:. La severità dipende dal file: critica per .env, dump del database e chiavi private; alta per .git e configurazioni del server; bassa per .DS_Store o un Dockerfile.

Cosa fa un attaccante con questo

Lo stesso dello scanner, ma contro tutti i domini esistenti. Un .env accessibile consegna in un colpo le credenziali del database, le chiavi di pagamento e i token email. Una directory .git esposta permette di scaricare l'intero repository con uno strumento da riga di comando, con tutta la cronologia, comprese le chiavi cancellate in un commit successivo. Un backup.sql è tutto il tuo database, con utenti e password cifrate. È uno dei difetti più semplici da sfruttare e più gravi.

Perché succede

Due cause. La prima è fare il deploy dell'intera cartella del progetto invece della cartella di output della build: tutto ciò che sta nel repository diventa servibile. La seconda è un server web (nginx, Apache, IIS) che serve una cartella in cui si sviluppa anche o si fanno backup. Piattaforme come Vercel o Netlify pubblicano solo la cartella di output, per questo lì questo difetto si riduce di solito a file copiati per sbaglio in public/.

Come sistemarlo

• Togli il file e ruota tutto ciò che conteneva. Se un .env è stato accessibile, ogni chiave al suo interno è compromessa anche se nessuno ti ha avvisato.
• Fai il deploy solo dell'output della build (dist/, .output/, .next/), mai della radice del progetto. In Express, express.static deve puntare a quella cartella.
• Blocca i percorsi sul server come seconda barriera. In nginx: location ~ /\.(?!well-known) { deny all; } blocca tutto ciò che inizia con un punto tranne .well-known; aggiungi regole per *.sql, *.yml e *.log. In Apache, l'equivalente con FilesMatch e Require all denied.
• Controlla la cartella public/ del tuo progetto: lì non deve esserci nulla che non sia un'immagine, un font o un file pensato per essere scaricato.
• Guarda i log di accesso cercando richieste a /.env o /.git con risposta 200 per sapere se qualcuno è arrivato prima di te.

Verifica che sia sistemato

for p in .env .env.local .git/config .git/HEAD config.json backup.sql docker-compose.yml .npmrc; do
  printf "%-20s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://tuodominio.com/$p"
done

L'atteso è 404 o 403 su tutti. Un 200 in una SPA può essere il solito HTML: aprilo e conferma che non sia il file reale.

Domande frequenti

Il mio sito restituisce 200 su tutti i percorsi. Segnalerà falsi positivi?

No. Lo scanner valida il contenuto prima di aprire un riscontro; un HTML generico non conta come .env.

Perché .DS_Store è un riscontro se non contiene segreti?

Perché elenca i nomi dei file della cartella, compresi quelli che non colleghi da nessuna pagina. È una mappa gratuita per chi cerca backup o file dimenticati. Severità bassa, ma conviene toglierlo.

E i percorsi .well-known?

Quelli devono essere accessibili: lì vivono security.txt, le verifiche di dominio e i certificati. La regola nginx dell'esempio li esclude dal blocco.