Prístupné súbory .env, .git a zálohy: ako z webov unikajú tajomstvá

Niektoré z najškodlivejších únikov z webov sa zaobídu úplne bez prieniku. V koreni webu leží súbor, ktorý nikdy nemal byť prístupný, server ho bez problémov pošle každému, kto si oň požiada, a v tom súbore je heslo k databáze, kľúč API alebo celý zdrojový kód webu.

Najčastejšie ide o 3 typy súborov: súbory .env s tajomstvami konfigurácie, priečinky .git, ktoré obsahujú celú históriu repozitára, a záložné kópie ako site.zip, db.sql alebo config.php.bak. OWASP Web Security Testing Guide ich všetky uvádza ako typické zdroje uniknutých prístupových údajov a zdrojového kódu.

Či ich váš web nevydáva, skontrolujete za pár minút pomocou curl.

Ako sa tieto súbory dostanú von

• Súbory .env. Mnohé frameworky čítajú tajomstvá zo súboru .env v priečinku projektu. Ak webový server používa ako koreň webu (document root) priečinok projektu namiesto podpriečinka public, súbor vydá ako ktorýkoľvek iný.
• Priečinky .git. Nasadzovanie cez git clone alebo git pull priamo v koreni webu nechá priečinok .git priamo vedľa stránok webu. Z neho sa dá poskladať zdrojový kód a každý starší commit vrátane tajomstiev, ktoré niekto „odstránil“ už dávno.
• Zálohy a výpisy. Rýchly zip pred aktualizáciou, export db.sql na migráciu, kópia z editora ako index.php~ alebo config.php.old. OWASP upozorňuje, že server môže zálohu skriptu namiesto vykonania poslať ako obyčajný text, a tým prezradí jej zdrojový kód.
• Zvyšky po nástrojoch. phpinfo.php, .htpasswd, .DS_Store, stavové súbory Terraformu a logy sa na webe objavujú tiež.

Spoločné majú to, že sa web upravuje alebo nasadzuje priamo na produkčnom serveri a nikto pritom nerozhoduje, čo do koreňa webu patrí.

Ako skontrolovať vlastný web

Pošlite požiadavky na najčastejšie cesty a sledujte stavový kód a veľkosť každej odpovede:

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

Čo výsledky znamenajú:

• Chcete vidieť 404 alebo 403 pre každú cestu.
• 200 so skutočným obsahom je nález. Pri .git/HEAD vyzerá skutočný obsah ako ref: refs/heads/main. Pri .env ako riadky NAME=value.
• 200 s vašou bežnou úvodnou stránkou alebo vlastnou chybovou stránkou je zvyčajne „mäkká 404“. OWASP upozorňuje, že samotná odpoveď 200 ešte nie je nález: otvorte ju a overte, čo naozaj obsahuje.

Kontrolu zopakujte na každej doméne a subdoméne, ktorú prevádzkujete, vrátane stagingu a starých subdomén. Práve tam takéto súbory prežívajú najdlhšie, ako opisujeme v článku o zabudnutých staging a testovacích serveroch. Webové archívy navyše môžu uchovávať kópie súborov, ktoré boli prístupné v minulosti, takže súbor, ktorý ste práve odstránili, už mohol niekto vidieť.

Ak tajomstvo uniklo, najprv ho zmeňte

Zmazanie súboru zastaví nové stiahnutia, no neviete, kto si ho už skopíroval. Každé tajomstvo v prístupnom súbore považujte za kompromitované:

1. Zmeňte alebo zneplatnite každé heslo, kľúč API a token v súbore. Návod GitHubu na odstránenie citlivých údajov uvádza rovnaké poradie: najprv tajomstvo zneplatniť alebo zmeniť, až potom čistiť históriu.
2. Odstráňte súbor zo servera aj z každého záložného priečinka v koreni webu.
3. Prejdite prístupové logy a hľadajte požiadavky na danú cestu, aby ste zistili, či a kedy si ho niekto stiahol.
4. Overte, kam sa dalo s kľúčom dostať (cloudové konzoly, platobné brány, poštové služby), a hľadajte tam aktivitu, ktorú neviete vysvetliť.

Ak sa tajomstvá dostali do repozitára, prepísanie histórie (GitHub odporúča git-filter-repo) má zmysel až vtedy, keď samotné tajomstvo už neplatí.

Ako tomu predísť

• Koreň webu (document root) nasmerujte len na verejný priečinok webu, nikdy na koreň projektu.
• Nasadzujte zostavený výsledok (build), nie pracovnú kópiu. CI pipeline, ktorá kopíruje len súbory potrebné pre web, nechá .git a .env mimo už zo svojej podstaty.
• Blokujte súbory začínajúce bodkou na webovom serveri, ako ukazujeme nižšie.
• Tajomstvá podľa možnosti nedržte v súboroch: použite premenné prostredia svojej platformy alebo správcu tajomstiev.
• Zálohy a výpisy nikdy neukladajte do koreňa webu. OWASP odporúča držať dáta, logy a konfiguračné súbory tam, odkiaľ ich webový server nemôže servírovať.
• Kontrolu zopakujte po každej zmene infraštruktúry, vrátane nových serverov za load balancerom.

Blokovanie súborov začínajúcich bodkou (okrem /.well-known/, ktorý potrebuje obnova certifikátov) vyzerá v nginx takto:

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

A takto v konfigurácii webu pre Apache:

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

Krátky kontrolný zoznam

• Spustite cyklus s curl z tohto článku na každej doméne a subdoméne, ktorú vlastníte.
• Každú odpoveď 200 overte prečítaním obsahu.
• Zmeňte každé tajomstvo, ktoré sa kedykoľvek dalo stiahnuť.
• V konfigurácii webového servera blokujte súbory začínajúce bodkou a prípony záloh.
• Nasadzovanie presuňte do pipeline, ktorá dodáva len zostavené súbory.

Keď už upravujete konfiguráciu servera, je to dobrá chvíľa doplniť bezpečnostné hlavičky HTTP, ktoré by mal posielať každý firemný web.

Ako pomáha Datahorses

Datahorses stráži váš web zvonku tak, ako by sa naň pozeral útočník, a upozorní na prístupné súbory .git, .env, zálohy a konfiguračné súbory, ktoré na vašich doménach zaznamenali webové archívy. Do vašich systémov nevstupujeme a nepotrebujeme žiadne prístupy. Váš vývojár dostane presné kroky, ako súbor odstrániť a zmeniť to, čo uniklo. Viac o tom, čo strážime a prečo nepotrebujeme prístupy.