Soubory .env, .git a zálohy přístupné z webu: jak unikají tajné údaje

Některé z nejškodlivějších úniků z webů se obejdou úplně bez hackování. V kořeni webu leží soubor, který nikdy neměl být přístupný, server ho ochotně pošle každému, kdo si o něj řekne, a uvnitř je heslo k databázi, API klíč nebo celý zdrojový kód webu.

Obvykle jde o 3 druhy souborů: soubory .env s tajnými údaji z konfigurace, složky .git s celou historií repozitáře a záložní kopie jako site.zip, db.sql nebo config.php.bak. OWASP Web Security Testing Guide je všechny uvádí jako typické zdroje uniklých přístupových údajů a zdrojového kódu.

Svůj web na ně můžete zkontrolovat za pár minut pomocí curl.

Jak se tyto soubory dostanou ven

• Soubory .env. Mnoho frameworků čte tajné údaje ze souboru .env ve složce projektu. Pokud webový server jako kořenový adresář používá složku projektu, a ne její podsložku public, pošle soubor každému jako kterýkoli jiný.
• Složky .git. Když web nasazujete příkazem git clone nebo git pull přímo v kořeni webu, zůstane adresář .git hned vedle něj. Z něj lze zrekonstruovat zdrojový kód i každý dřívější commit, včetně tajných údajů, které byly „odstraněny“ už dávno.
• Zálohy a dumpy. Rychlý zip před aktualizací, export db.sql kvůli migraci, kopie z editoru jako index.php~ nebo config.php.old. OWASP upozorňuje, že server zálohu skriptu nemusí spustit, ale pošle ji jako prostý text, a prozradí tak jeho zdrojový kód.
• Pozůstatky nástrojů. Stejně se na web dostávají phpinfo.php, .htpasswd, .DS_Store, stavové soubory Terraformu a logy.

Společným jmenovatelem jsou úpravy a nasazování přímo na produkčním serveru, kde chybí krok, který by určil, co do kořene webu patří.

Jak zkontrolovat vlastní web

Vyzkoušejte nejběžnější cesty a u každé odpovědi sledujte stavový kód a velikost:

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

Co výsledky znamenají:

• U každé cesty chcete vidět 404 nebo 403.
• 200 se skutečným obsahem je nález. U .git/HEAD vypadá skutečný obsah jako ref: refs/heads/main, u .env jako řádky NAME=value.
• 200 s vaší běžnou úvodní stránkou nebo vlastní chybovou stránkou je obvykle „soft 404“. OWASP varuje, že samotná shoda ještě není nález: otevřete odpověď a ověřte, co skutečně obsahuje.

Kontrolu zopakujte pro každý název hostitele, který provozujete, včetně stagingu a starých subdomén. Právě tam takové soubory přežívají nejdéle, jak popisujeme v článku o zapomenutých staging a testovacích serverech. Webové archivy navíc mohou uchovávat kopie souborů, které byly přístupné v minulosti, takže soubor, který jste právě odstranili, už mohl někdo vidět.

Pokud tajný údaj unikl, nejdřív ho vyměňte

Smazáním souboru zastavíte další stahování, ale nevíte, kdo si ho už zkopíroval. Každý tajný údaj z přístupného souboru proto berte jako prozrazený:

1. Vyměňte nebo zneplatněte každé heslo, API klíč a token v souboru. Návod GitHubu k odstranění citlivých dat uvádí stejné pořadí: nejdřív tajný údaj zneplatnit nebo vyměnit, potom vyčistit historii.
2. Odstraňte soubor ze serveru i z každé záložní složky uvnitř kořene webu.
3. Projděte přístupové logy a vyhledejte požadavky na danou cestu, abyste zjistili, zda a kdy si soubor někdo stáhl.
4. Zkontrolujte, kam se s klíčem dalo dostat (cloudové konzole, platební brány, poštovní služby), a hledejte aktivitu, kterou neumíte vysvětlit.

Pokud se tajné údaje dostaly do commitu v repozitáři, přepsání historie (GitHub doporučuje git-filter-repo) má smysl až ve chvíli, kdy samotný tajný údaj přestal platit.

Jak tomu předejít

• Nasměrujte kořenový adresář webu jen na veřejnou složku, nikdy na kořen projektu.
• Nasazujte výstupy buildu, ne pracovní kopie. CI pipeline, která kopíruje jen soubory potřebné pro web, už ze své podstaty .git a .env na server nepustí.
• Na webovém serveru blokujte soubory začínající tečkou, jak ukazujeme níže.
• Kde to jde, nedržte tajné údaje v souborech: použijte proměnné prostředí vaší platformy nebo správce tajných údajů.
• Nikdy neukládejte zálohy ani dumpy do kořene webu. OWASP doporučuje ukládat data, logy a konfigurační soubory tam, odkud je webový server nemůže poskytnout.
• Kontrolu opakujte po každé změně infrastruktury, včetně nových serverů za load balancerem.

V nginx vypadá blokování souborů s tečkou (s výjimkou /.well-known/, kterou potřebuje obnova certifikátů) takto:

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

A takto v konfiguraci webu v Apache:

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

Krátký kontrolní seznam

• Spusťte výše uvedenou smyčku curl pro každý název hostitele, který vlastníte.
• U každé odpovědi 200 si přečtěte obsah a ověřte ji.
• Vyměňte každý tajný údaj, který byl kdy přístupný.
• Zablokujte v konfiguraci webového serveru soubory s tečkou a přípony záloh.
• Převeďte nasazování na pipeline, která na server dodá jen sestavené soubory.

Když už konfiguraci serveru upravujete, je to dobrá chvíle doplnit HTTP bezpečnostní hlavičky, které by měl posílat každý firemní web.

Jak pomáhá Datahorses

Datahorses hlídá váš web zvenčí tak, jak se na něj dívá útočník, a upozorní vás na přístupné soubory .git, .env, zálohy a konfigurační soubory, které webové archivy zaznamenaly na vašich doménách. Do vašich systémů nevstupujeme a žádné přístupy nepotřebujeme; váš vývojář dostane přesný postup, jak soubor odstranit a vyměnit, co uniklo. Podívejte se, co hlídáme a proč nepotřebujeme přístupy.