Ujawniony plik .env — 30-minutowy plan reakcji na incydent | Scanthra

Scanthra · 6 min czytania · Zaktualizowano Maj 2026

Dlaczego ujawniony plik .env jest poważnym problemem

Plik .env zazwyczaj zawiera:

• Nazwę użytkownika, hasło i adres serwera bazy danych.
• Klucze API do Stripe, AWS, SendGrid, Mailgun, OpenAI…
• Sekrety do podpisywania tokenów JWT i sekrety klientów OAuth.
• Czasem dane logowania administratora lub hasło „DEV" użyte przy inicjalizacji.

Automatyczne skanery internetu, takie jak Shodan, BinaryEdge i dziesiątki botnetów zbierających dane logowania, stale odpytują /.env na milionach hostów. Jeśli twój plik jest publiczny, przyjmij, że ktoś już go odczytał. Koszt zmiany kluczy jest dużo niższy niż koszt wycieku danych.

Krok 1 — Zmień każdy sekret w pliku

Otwórz plik (lub jego kopię zapasową) i dla każdego wpisu:

• DB_PASSWORD — zmień hasło w bazie danych (ALTER USER … WITH PASSWORD … w PostgreSQL, ALTER USER … IDENTIFIED BY … w MySQL), a następnie zaktualizuj konfigurację aplikacji.
• Klucze API — dla każdego dostawcy wejdź do panelu → Klucze API → unieważnij wyciekły klucz, wygeneruj nowy, zaktualizuj konfigurację. Stripe, AWS i OpenAI obsługują rotację kluczy bez przerwy w działaniu.
• Sekrety JWT / sesji — zmień je, wiedząc, że wyloguje to wszystkich użytkowników. Zaplanuj to na okno niskiego ruchu, ale nie czekaj dłużej niż kilka godzin.
• Dane logowania SMTP / mailera — zmień natychmiast; wyciekłe dane SMTP to główny wektor spamu.

Użyj menedżera haseł lub managera sekretów (AWS Secrets Manager, Doppler, 1Password, Bitwarden) do wygenerowania nowych wartości. Nigdy nie używaj ponownie żadnego ze starych sekretów.

Krok 2 — Sprawdź, czy skradzione klucze były użyte

Zanim zapomnisz starych kluczy, sprawdź, czy ktoś z nich skorzystał, gdy były publicznie dostępne:

• Stripe: Panel → Deweloperzy → Zdarzenia. Filtruj według starego klucza. Szukaj obciążeń, zwrotów i zmian na koncie, których nie robiłeś(-aś).
• AWS: Historia zdarzeń CloudTrail filtrowana po ID wyciekłego klucza dostępu. Szukaj nowych użytkowników IAM, nowych instancji EC2, odczytów nieoczekiwanych zasobów S3 czy czegokolwiek z iam:* lub ec2:RunInstances.
• SendGrid / Mailgun: Sprawdź kanał aktywności pod kątem skoków ruchu, nowych szablonów i zmian IP.
• Baza danych: Logi audytowe (jeśli włączone) z nieoczekiwanymi zapytaniami; sprawdź pg_stat_activity pod kątem aktywnych sesji.

Jeśli znajdziesz coś podejrzanego: to potwierdzony incydent — eskaluj go, zapisz informacje, postępuj zgodnie ze swoim planem reagowania na incydenty i powiadom klientów, jeśli ich dane osobowe są zagrożone. Podmioty objęte zakresem NIS2 (dyrektywa UE o cyberbezpieczeństwie) muszą złożyć wczesne ostrzeżenie w ciągu 24 godzin.

Krok 3 — Trwale zablokuj ścieżkę

Ujawniony plik prawdopodobnie znajdował się w katalogu głównym aplikacji, bo katalog publiczny frameworka jest o jeden poziom za wysoko. Dwie warstwy ochrony są lepsze niż jedna:

Przenieś plik poza katalog publiczny:

mkdir /etc/myapp
mv /var/www/myapp/.env /etc/myapp/.env
chmod 600 /etc/myapp/.env
chown www-data:www-data /etc/myapp/.env

Zaktualizuj aplikację, żeby czytała z nowej ścieżki.

I zablokuj pliki ukryte na serwerze www:

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

# Apache
<FilesMatch "^\.">
  Require all denied
</FilesMatch>

Krok 4 — Zadbaj, żeby to się nie powtórzyło

• Używaj managera sekretów w produkcji — AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, Doppler. Plik .env staje się wtedy wygodą dla deweloperów, a nie artefaktem wdrożeniowym.
• Dodaj sprawdzenie w CI, które zrywa build, gdy .env trafia do repozytorium. git secrets, trufflehog lub gitleaks — każde z nich to obsługuje.
• Dodaj hook pre-commit z detect-secrets, żeby wycieki nie docierały nawet do main.
• Rotuj klucze regularnie. Co 6 miesięcy dla długotrwałych kluczy; natychmiast po odejściu kogoś z zespołu.

A co z historią Gita?

Jeśli plik .env był kiedykolwiek commitowany do publicznego repozytorium — choćby chwilowo, choćby lata temu — przyjmij, że sekrety wyciekły. Wyszukiwarka GitHub i tysiące narzędzi do zbierania danych treningowych już to mają. git filter-repo przepisuje historię, ale nadal musisz zmienić wartości, bo kopie istnieją poza twoją kontrolą.

Nudna lekcja

Ujawniony plik .env to jedno z najczęstszych wykryć Scanthra w projektach PHP, Laravel, Django, Rails i Node. Niemal zawsze przyczyną jest: „Postąpiłem(-am) zgodnie z tutorialem, który umieścił .env w katalogu projektu i zapomniałem(-am), że serwer serwuje stamtąd pliki statyczne." Przeniesienie pliku o jeden katalog wyżej — i dodanie reguły blokującej pliki ukryte — zamyka całą tę klasę problemu.

Jak Scanthra to wykrywa

Nasz moduł Ukryte pliki sprawdza wybraną listę ścieżek, w tym .env, .env.local, .env.production, .git/config, /backup.sql, /dump.sql, /wp-config.php.bak i inne. Uzupełniamy to sprawdzeniem nagłówków plików (ZIP, gzip, SQLite), żeby odróżnić prawdziwą kopię zapasową od strony błędu 404 zwracającej kod 200.