Avoimet .env-, .git- ja varmuuskopiotiedostot: miten salaisuudet vuotavat verkkosivustoilta

Osa vahingollisimmista verkkosivustovuodoista ei vaadi lainkaan murtautumista. Tiedosto, jota ei koskaan ollut tarkoitettu kaikkien nähtäväksi, on verkkopalvelimen juurikansiossa, palvelin toimittaa sen mukisematta kenelle tahansa sitä pyytävälle, ja tiedostossa on tietokannan salasana, API-avain tai sivuston koko lähdekoodi.

Tavallisimmat 3 syyllistä ovat .env-tiedostot konfiguraation salaisuuksineen, .git-kansiot, jotka sisältävät koko repositorion historian, sekä varmuuskopiot, kuten site.zip, db.sql tai config.php.bak. OWASP Web Security Testing Guide mainitsee ne kaikki tyypillisinä paljastuneiden tunnusten ja lähdekoodin lähteinä.

Voitte tarkistaa oman sivustonne muutamassa minuutissa curl-komennolla.

Miten nämä tiedostot päätyvät näkyviin

• .env-tiedostot. Monet sovelluskehykset lukevat salaisuudet projektikansion .env-tiedostosta. Jos verkkopalvelimen juurihakemisto on projektikansio eikä sen public-alikansio, tiedosto tarjoillaan kuten mikä tahansa muu.
• .git-kansiot. Kun julkaisu tehdään ajamalla git clone tai git pull suoraan juurikansiossa, .git-hakemisto jää sivuston viereen. Sen avulla kuka tahansa voi koota lähdekoodin ja jokaisen aiemman commitin, myös salaisuudet, jotka "poistettiin" kauan sitten.
• Varmuuskopiot ja vedokset. Nopea zip ennen päivitystä, db.sql-vienti siirtoa varten, editorin kopio kuten index.php~ tai config.php.old. OWASP huomauttaa, että skriptin varmuuskopio voidaan tarjoilla tavallisena tekstinä suorittamisen sijaan, jolloin sen lähdekoodi paljastuu.
• Työkalujen jäänteet. phpinfo.php, .htpasswd, .DS_Store, Terraformin tilatiedostot ja lokitiedostot paljastuvat samalla tavalla.

Yhteinen tekijä on muokkaaminen tai julkaiseminen suoraan tuotantopalvelimella ilman vaihetta, jossa päätetään, mitä juurikansioon kuuluu.

Miten tarkistatte oman sivustonne

Hakekaa yleisimmät polut ja katsokaa kunkin vastauksen tilakoodi ja koko:

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

Mitä tulokset tarkoittavat:

• 404 tai 403 jokaiselle polulle on toivottu tulos.
• 200 ja todellinen sisältö on havainto. .git/HEAD-tiedostossa todellinen sisältö näyttää tältä: ref: refs/heads/main. .env-tiedostossa se on rivejä muotoa NAME=value.
• 200 ja tavallinen etusivunne tai oma virhesivu on yleensä niin sanottu "soft 404". OWASP varoittaa, että pelkkä osuma ei ole havainto: avatkaa vastaus ja varmistakaa, mitä se todella sisältää.

Toistakaa tarkistus jokaisella käyttämällänne palvelinnimellä, myös staging-ympäristöissä ja vanhoissa aliverkkotunnuksissa. Niissä tällaiset tiedostot säilyvät pisimpään, kuten kerromme artikkelissamme unohdetuista staging- ja testipalvelimista. Verkkoarkistoissa voi myös olla kopioita aiemmin näkyvissä olleista tiedostoista, joten juuri poistamanne tiedosto on voitu jo nähdä.

Jos salaisuus paljastui, vaihtakaa se ensin

Tiedoston poistaminen estää uudet lataukset, mutta ette voi tietää, kuka sen on jo kopioinut. Käsitelkää jokaista paljastuneen tiedoston salaisuutta vaarantuneena:

1. Vaihtakaa tai mitätöikää jokainen tiedoston salasana, API-avain ja tunniste. GitHubin ohje arkaluonteisten tietojen poistamisesta antaa saman järjestyksen: ensin salaisuuden mitätöinti tai vaihto, sitten historian siivous.
2. Poistakaa tiedosto palvelimelta ja kaikista juurikansion sisällä olevista varmuuskopiokansioista.
3. Käykää läpi pääsylokit kyseisen polun pyyntöjen osalta, jotta ymmärrätte, ladattiinko tiedosto ja milloin.
4. Selvittäkää, mihin avaimilla pääsi (pilvikonsolit, maksupalvelut, sähköpostipalvelut), ja etsikää niistä toimintaa, jota ette osaa selittää.

Jos salaisuuksia on commitoitu repositorioon, historian uudelleenkirjoitus (GitHub suosittelee git-filter-repo-työkalua) auttaa vasta sitten, kun itse salaisuus ei ole enää voimassa.

Miten tämän voi estää

• Määrittäkää juurihakemistoksi vain julkaistava kansio, ei koskaan projektin juurta.
• Julkaiskaa vain käännetyt tiedostot, älkää työkopiota. CI-putki, joka kopioi vain sivuston tarvitsemat tiedostot, pitää .git- ja .env-tiedostot poissa jo rakenteensa ansiosta.
• Estäkää pistetiedostot verkkopalvelimessa, kuten alla näytetään.
• Pitäkää salaisuudet mahdollisuuksien mukaan poissa tiedostoista: käyttäkää alustanne ympäristömuuttujia tai salaisuuksien hallintaa.
• Älkää koskaan säilyttäkö varmuuskopioita tai vedoksia juurikansiossa. OWASP suosittelee pitämään data-, loki- ja konfiguraatiotiedostot paikassa, josta verkkopalvelin ei voi niitä tarjoilla.
• Tarkistakaa uudelleen jokaisen infrastruktuurimuutoksen jälkeen, myös kun kuormantasaajan taakse tulee uusia palvelimia.

Pistetiedostojen esto (säilyttäen /.well-known/, jota varmenteen uusiminen tarvitsee) näyttää nginxissä tältä:

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

Ja Apachen sivustokonfiguraatiossa tältä:

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

Lyhyt tarkistuslista

• Ajakaa yllä oleva curl-silmukka jokaisella omistamallanne palvelinnimellä.
• Varmistakaa jokainen 200 lukemalla sisältö.
• Vaihtakaa jokainen salaisuus, joka on joskus ollut saatavilla.
• Estäkää pistetiedostot ja varmuuskopiopäätteet verkkopalvelimen konfiguraatiossa.
• Siirtäkää julkaisut putkeen, joka toimittaa vain käännetyt tiedostot.

Kun palvelimen konfiguraatio on muutenkin työn alla, on hyvä hetki lisätä HTTP-tietoturvaotsakkeet, jotka jokaisen yrityssivuston pitäisi lähettää.

Miten Datahorses auttaa

Datahorses valvoo verkkosivustoanne ulkoapäin samasta näkökulmasta kuin hyökkääjä ja nostaa esiin avoimet .git-, .env-, varmuuskopio- ja konfiguraatiotiedostot, jotka verkkoarkistot ovat tallentaneet verkkotunnuksistanne. Emme mene järjestelmiinne emmekä tarvitse pääsyoikeuksia. Kehittäjänne saa tarkat ohjeet tiedoston poistamiseen ja vuotaneiden tunnusten vaihtamiseen. Katsokaa, miten valvomme ja miksi pääsyoikeuksia ei tarvita.