Veřejné .env, .git, phpinfo a server-status: kontrola a náprava

Proč veřejný systémový soubor představuje problém

Produkční web má zveřejňovat pouze soubory určené návštěvníkům. Konfigurace aplikace, repozitář a diagnostika patří mimo veřejný kořen nebo za spolehlivé řízení přístupu. Pouhé neodkazování na adresu ji nechrání — automatizované skenery běžné názvy zkoušejí přímo.

Veřejný audit CoderPro tyto citlivé ani diagnostické adresy záměrně nezkouší. Následující postup je určený vlastníkovi nebo správci webu, který má ke kontrole oprávnění a dokáže případný nález bezpečně vyřešit.

Jaké informace mohou jednotlivé cesty odhalit

Co udělat při potvrzené expozici

1. 01

   Okamžitě odeberte veřejný přístup

   Soubor přesuňte mimo document root, odstraňte z produkce nebo přístup zablokujte na vrstvě webserveru či hostingu.

2. 02

   Otočte potenciálně odhalená tajemství

   Změňte hesla, API tokeny, aplikační secret a přístupové klíče. Nestačí změnit jen obsah souboru na serveru.

3. 03

   Zrušte staré relace a oprávnění

   Podle typu úniku odvolejte aktivní tokeny, zkontrolujte uživatele a omezte účty na nejnižší potřebná práva.

4. 04

   Prověřte logy a historii

   Zjistěte, jak dlouho byl zdroj dostupný a zda jej někdo stahoval. Počítejte s tím, že běžné přístupové logy nemusí dokazovat úplnou absenci zneužití.

5. 05

   Vyhodnoťte incident

   Pokud mohly uniknout osobní údaje nebo klientská data, zapojte odpovědnou osobu a postupujte podle právních a smluvních povinností.

Nejspolehlivější ochrana začíná strukturou nasazení

Veřejný kořen nastavte jen na adresář s veřejnými assety a vstupním souborem aplikace, například public/. Konfigurace, vendor balíčky, logy, zálohy, Git metadata a zdrojový kód pak leží o úroveň výš a webserver je nemůže přímo servírovat.

/var/www/example/
├── .env                 # mimo veřejný kořen
├── .git/                # mimo veřejný kořen
├── config/
├── src/
├── var/
└── public/              # jediný document root
    ├── index.php
    └── assets/

Doplňková blokace na webserveru

Pokud na sdíleném hostingu nemůžete změnit document root, použijte blokaci jako další vrstvu. Po změně vždy ověřte, že hosting příslušné direktivy skutečně respektuje.

Apache / .htaccess

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule (^|/)\.env([./]|$) - [F,L,NC]
  RewriteRule (^|/)\.git(/|$) - [F,L,NC]
  RewriteRule (^|/)(info|phpinfo)\.php$ - [F,L,NC]
</IfModule>

Nginx

location ~ (^|/)\.env([./]|$) {
    deny all;
}

location ~ (^|/)\.git(/|$) {
    deny all;
}

location ~* ^/(info|phpinfo)\.php$ {
    deny all;
}

server-status nemusí být skutečný soubor. Jde o handler modulu Apache. Pokud jej potřebujete pro monitoring, omezte jej na autorizované uživatele nebo důvěryhodnou síť. Jinak modul či příslušnou lokaci vypněte. Na sdíleném hostingu může být potřeba zásah podpory poskytovatele.

Bezpečné ověření po opravě

Kontrolujte pouze web, k jehož testování máte oprávnění. U každé cesty sledujte stav i tělo odpovědi — některé weby vracejí vlastní HTML chybovou stránku se stavem 200.

curl -i https://example.com/.env
curl -i https://example.com/.git/config
curl -i https://example.com/info.php
curl -i https://example.com/phpinfo.php
curl -i https://example.com/server-status

• Odpověď 404 je vhodná pro zdroj, který na produkci nemá existovat.
• Odpověď 403 je přijatelná, pokud musí zdroj zůstat a řízení přístupu je spolehlivé.
• Tělo nesmí obsahovat konfiguraci, Git metadata, phpinfo ani Apache status.
• Po rotaci ověřte, že stará hesla a tokeny již nejsou platné.