Scanner voor gevoelige bestanden

Hoe deze controle werkt

Scanaris vraagt een lijst paden op waar vaak bestanden achterblijven die nooit op een publieke server zouden moeten staan: .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 en .DS_Store. Een 200 is niet genoeg om iets te markeren: veel single-page-applicaties antwoorden op elk pad met 200 en hun HTML. Daarom controleert de scanner dat de inhoud er echt uitziet, bijvoorbeeld dat een .env regels SLEUTEL=waarde bevat en geen HTML is, of dat .git/HEAD begint met ref:. De ernst hangt af van het bestand: kritiek voor .env, databasedumps en private sleutels; hoog voor .git en serverconfiguraties; laag voor .DS_Store of een Dockerfile.

Wat een aanvaller hiermee doet

Hetzelfde als de scanner, maar tegen alle bestaande domeinen. Een bereikbare .env levert in één keer de databasegegevens, de betaalsleutels en de e-mailtokens. Een blootgestelde .git-map laat het hele repository downloaden met een commandoregeltool, met de volledige geschiedenis, inclusief sleutels die in een latere commit zijn verwijderd. Een backup.sql is je hele database, met gebruikers en gehashte wachtwoorden. Het is een van de eenvoudigst te misbruiken en ernstigste fouten.

Waarom het gebeurt

Twee oorzaken. De eerste is de hele projectmap deployen in plaats van de outputmap van de build: alles in het repository wordt serveerbaar. De tweede is een webserver (nginx, Apache, IIS) die een map serveert waarin ook ontwikkeld wordt of back-ups worden gemaakt. Platforms als Vercel of Netlify publiceren alleen de outputmap, waardoor deze fout daar meestal neerkomt op bestanden die per ongeluk naar public/ zijn gekopieerd.

Hoe je het oplost

• Verwijder het bestand en roteer alles wat erin stond. Als een .env bereikbaar was, is elke sleutel erin gecompromitteerd, ook al heeft niemand je gewaarschuwd.
• Deploy alleen de buildoutput (dist/, .output/, .next/), nooit de projectroot. In Express moet express.static naar die map wijzen.
• Blokkeer de paden op de server als tweede barrière. In nginx: location ~ /\.(?!well-known) { deny all; } blokkeert alles wat met een punt begint behalve .well-known; voeg regels toe voor *.sql, *.yml en *.log. In Apache het equivalent met FilesMatch en Require all denied.
• Controleer de map public/ van je project: daar hoort niets te staan behalve afbeeldingen, lettertypen of bestanden die bedoeld zijn om te downloaden.
• Bekijk de toegangslogs op verzoeken naar /.env of /.git met antwoord 200 om te weten of iemand er eerder was dan jij.

Controleer of het is opgelost

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://jouwdomein.com/$p"
done

Verwacht: 404 of 403 op allemaal. Een 200 bij een SPA kan de gebruikelijke HTML zijn: open het en bevestig dat het niet het echte bestand is.

Veelgestelde vragen

Mijn site geeft op elk pad 200 terug. Krijg ik valse positieven?

Nee. De scanner valideert de inhoud voordat hij een bevinding opent; een generieke HTML telt niet als .env.

Waarom is .DS_Store een bevinding als het geen geheimen bevat?

Omdat het de namen van de bestanden in de map opsomt, ook die je vanaf geen enkele pagina koppelt. Het is een gratis kaart voor wie back-ups of vergeten bestanden zoekt. Lage ernst, maar de moeite om te verwijderen.

En de .well-known-paden?

Die moeten bereikbaar zijn: daar leven security.txt, domeinverificaties en certificaten. De nginx-regel in het voorbeeld sluit ze uit van de blokkade.