Blootgestelde .env-, .git- en back-upbestanden: zo lekken geheimen van websites

Sommige van de schadelijkste websitelekken ontstaan zonder enige hack. Een bestand dat nooit voor iedereen bedoeld was, staat in de webroot, de server stuurt het zonder morren naar iedereen die erom vraagt, en dat bestand bevat een databasewachtwoord, een API-sleutel of de volledige broncode van de site.

De 3 vaste verdachten zijn .env-bestanden met configuratiegeheimen, .git-mappen met de volledige geschiedenis van de repository, en back-upkopieën zoals site.zip, db.sql of config.php.bak. De OWASP Web Security Testing Guide noemt ze allemaal als typische bron van blootgestelde inloggegevens en broncode.

Met curl controleert u uw eigen site er in enkele minuten op.

Hoe deze bestanden zichtbaar worden

• .env-bestanden. Veel frameworks lezen geheimen uit een .env-bestand in de projectmap. Is de document root van de webserver de projectmap in plaats van de submap public, dan wordt het bestand geserveerd zoals elk ander bestand.
• .git-mappen. Wie uitrolt door git clone of git pull rechtstreeks in de webroot uit te voeren, laat de map .git naast de site staan. Daarmee kan iemand de broncode en elke eerdere commit reconstrueren, inclusief geheimen die lang geleden "verwijderd" zijn.
• Back-ups en dumps. Een snelle zip voor een update, een db.sql-export voor een migratie, een editorkopie zoals index.php~ of config.php.old. OWASP merkt op dat een back-up van een script als platte tekst kan worden geserveerd in plaats van te worden uitgevoerd, waardoor de broncode zichtbaar wordt.
• Restanten van tools. phpinfo.php, .htpasswd, .DS_Store, Terraform-statebestanden en logbestanden duiken op dezelfde manier op.

De rode draad is bewerken of uitrollen rechtstreeks op de productieserver, zonder een stap die bepaalt wat in de webroot thuishoort.

Zo controleert u uw eigen site

Vraag de meest voorkomende paden op en kijk naar de statuscode en de grootte van elk antwoord:

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

Wat de resultaten betekenen:

• 404 of 403 voor elk pad is wat u wilt zien.
• 200 met echte inhoud is een bevinding. Bij .git/HEAD ziet echte inhoud eruit als ref: refs/heads/main. Bij .env ziet u regels als NAME=value.
• 200 met uw gewone startpagina of een eigen foutpagina is meestal een "soft 404". OWASP waarschuwt dat een treffer op zich nog geen bevinding is: open het antwoord en ga na wat het werkelijk bevat.

Herhaal de controle op elke hostnaam die u gebruikt, ook staging en oude subdomeinen. Daar overleven zulke bestanden het langst, zoals we beschrijven in ons artikel over vergeten staging- en testservers. Webarchieven kunnen bovendien kopieën bewaren van bestanden die vroeger zichtbaar waren, dus een bestand dat u net hebt verwijderd, kan al door anderen gezien zijn.

Is een geheim uitgelekt, vervang het dan eerst

Het bestand verwijderen stopt nieuwe downloads, maar u kunt niet weten wie het al heeft gekopieerd. Beschouw elk geheim in een blootgesteld bestand als gecompromitteerd:

1. Vervang of trek in elk wachtwoord, elke API-sleutel en elk token uit het bestand. De richtlijn van GitHub over het verwijderen van gevoelige gegevens hanteert dezelfde volgorde: eerst het geheim intrekken of vervangen, daarna de geschiedenis opschonen.
2. Verwijder het bestand van de server en uit elke back-upmap binnen de webroot.
3. Bekijk de toegangslogs op verzoeken naar dat pad, zodat u weet of en wanneer het is gedownload.
4. Ga na waar de sleutel bij kon: cloudconsoles, betaalproviders, maildiensten, en zoek naar activiteit die u niet kunt verklaren.

Zijn geheimen in een repository gecommit, dan helpt het herschrijven van de geschiedenis (GitHub raadt git-filter-repo aan) pas als het geheim zelf niet meer geldig is.

Zo voorkomt u het

• Laat de document root alleen naar de publieke map wijzen, nooit naar de projectroot.
• Rol build-artefacten uit, geen werkkopieën. Een CI-pipeline die alleen de bestanden kopieert die de site nodig heeft, houdt .git en .env er per definitie buiten.
• Blokkeer dotfiles op de webserver, zoals hieronder.
• Houd geheimen waar mogelijk buiten bestanden: gebruik de omgevingsvariabelen van uw platform of een secrets manager.
• Bewaar nooit back-ups of dumps in de webroot. OWASP raadt aan gegevens, logs en configuratiebestanden op te slaan waar de webserver ze niet kan serveren.
• Controleer opnieuw na elke wijziging in de infrastructuur, ook bij nieuwe servers achter een load balancer.

Dotfiles blokkeren (met behoud van /.well-known/, dat nodig is voor het vernieuwen van certificaten) ziet er in nginx zo uit:

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

En zo in een Apache-siteconfiguratie:

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

Korte checklist

• Voer de curl-lus hierboven uit op elke hostnaam die u bezit.
• Bevestig elke 200 door de inhoud te lezen.
• Vervang elk geheim dat ooit bereikbaar was.
• Blokkeer dotfiles en back-upextensies in de configuratie van de webserver.
• Laat uitrollen via een pipeline verlopen die alleen gebouwde bestanden levert.

Nu u toch in de serverconfiguratie zit, is het een goed moment om de HTTP security headers toe te voegen die elke zakelijke website hoort te sturen.

Hoe Datahorses helpt

Datahorses bewaakt uw website van buitenaf, zoals een aanvaller ernaar zou kijken, en signaleert blootgestelde .git-, .env-, back-up- en configuratiebestanden die webarchieven op uw domeinen hebben vastgelegd. We gaan uw systemen niet binnen en hebben geen toegang nodig; uw ontwikkelaar krijgt de precieze stappen om het bestand te verwijderen en te vervangen wat uitlekte. Bekijk hoe wij bewaken en waarom geen toegang nodig is.