Skaner wrażliwych plików

Jak działa ta kontrola

Scanaris odpytuje listę ścieżek, pod którymi często zostają pliki, których nigdy nie powinno być na publicznym serwerze: .env, .env.local, .env.production, .git/config, .git/HEAD, wp-config.php, config.json, docker-compose.yml, backup.sql, phpinfo.php, .npmrc, Dockerfile, .gitlab-ci.yml, .aws/credentials, .ssh/id_rsa, web.config, adminer.php i .DS_Store. Samo 200 nie wystarczy, żeby coś oznaczyć: wiele aplikacji jednostronicowych odpowiada 200 swoim HTML-em na dowolną ścieżkę. Dlatego skaner sprawdza, czy zawartość wygląda na prawdziwą, na przykład czy .env ma linie KLUCZ=wartość i nie jest HTML-em, albo czy .git/HEAD zaczyna się od ref:. Waga zależy od pliku: krytyczna dla .env, zrzutów bazy danych i kluczy prywatnych; wysoka dla .git i konfiguracji serwera; niska dla .DS_Store czy Dockerfile.

Co atakujący z tym robi

To samo co skaner, ale wobec wszystkich istniejących domen. Dostępny .env oddaje za jednym razem poświadczenia bazy danych, klucze płatności i tokeny poczty. Wystawiony katalog .git pozwala pobrać całe repozytorium narzędziem z wiersza poleceń, z pełną historią, łącznie z kluczami usuniętymi w późniejszym commicie. backup.sql to cała Twoja baza, z użytkownikami i zahaszowanymi hasłami. To jeden z najprostszych do wykorzystania i najpoważniejszych błędów.

Dlaczego tak się dzieje

Dwie przyczyny. Pierwsza to wdrażanie całego katalogu projektu zamiast katalogu wyjściowego builda: wszystko, co jest w repozytorium, staje się serwowalne. Druga to serwer WWW (nginx, Apache, IIS) serwujący katalog, w którym też się rozwija kod albo robi kopie zapasowe. Platformy jak Vercel czy Netlify publikują tylko katalog wyjściowy, dlatego tam ten błąd sprowadza się zwykle do plików skopiowanych przez pomyłkę do public/.

Jak to naprawić

• Usuń plik i zrotuj wszystko, co zawierał. Jeśli .env był dostępny, każdy klucz w środku jest skompromitowany, nawet jeśli nikt Cię nie ostrzegł.
• Wdrażaj tylko wynik builda (dist/, .output/, .next/), nigdy katalog główny projektu. W Expressie express.static musi wskazywać na ten katalog.
• Zablokuj ścieżki na serwerze jako drugą barierę. W nginx: location ~ /\.(?!well-known) { deny all; } blokuje wszystko zaczynające się od kropki poza .well-known; dodaj reguły dla *.sql, *.yml i *.log. W Apache odpowiednik przez FilesMatch i Require all denied.
• Przejrzyj katalog public/ projektu: nie powinno tam być niczego poza obrazami, czcionkami lub plikami przeznaczonymi do pobrania.
• Zajrzyj do logów dostępu w poszukiwaniu żądań do /.env lub /.git z odpowiedzią 200, żeby wiedzieć, czy ktoś dotarł tam przed Tobą.

Sprawdź, czy naprawione

for p in .env .env.local .git/config .git/HEAD config.json backup.sql docker-compose.yml .npmrc; do
  printf "%-20s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://twojadomena.com/$p"
done

Oczekiwane to 404 lub 403 wszędzie. 200 w SPA może być zwykłym HTML-em: otwórz go i potwierdź, że to nie prawdziwy plik.

Często zadawane pytania

Moja strona zwraca 200 na wszystkich ścieżkach. Będą fałszywe alarmy?

Nie. Skaner waliduje zawartość, zanim otworzy znalezisko; generyczny HTML nie liczy się jako .env.

Dlaczego .DS_Store to znalezisko, skoro nie zawiera sekretów?

Bo wypisuje nazwy plików w katalogu, łącznie z tymi, do których nie linkujesz z żadnej strony. To darmowa mapa dla kogoś, kto szuka kopii zapasowych lub zapomnianych plików. Niska waga, ale warto go usunąć.

A ścieżki .well-known?

Te muszą być dostępne: tam żyją security.txt, weryfikacje domeny i certyfikaty. Reguła nginx z przykładu wyłącza je z blokady.