publicznie dostępne pliki wrażliwe

Publicznie dostępne pliki wrażliwe to pliki, które leżą w katalogu strony i dają się pobrać z przeglądarki, choć nie powinny: zrzuty bazy danych, archiwa kopii, pliki konfiguracyjne, katalogi systemów kontroli wersji. OWASP zwraca uwagę, że na serwerach WWW nierzadko zostają pliki zapomniane albo do niczego niepodlinkowane, z których można wyczytać ważne informacje o infrastrukturze albo dane logowania ^[6]. MITRE opisuje osobno dwa typowe przypadki: plik kopii zapasowej w miejscu dostępnym dla osób nieuprawnionych ^[4] i wystawione repozytorium kontroli wersji ^[5].

Jak działa

Plik wrażliwy nie musi być nigdzie podlinkowany, żeby dało się go pobrać. Wystarczy, że leży w katalogu obsługiwanym przez serwer WWW, a atakujący odgadnie jego nazwę. Nazwy są przewidywalne: backup.zip, baza.sql, wp-config.php.bak, .env, .git/HEAD. Sprawdzanie takich adresów łatwo zautomatyzować, więc robią to złośliwe boty i skanery.

RYS. 1Jak wycieka plik wrażliwy

Ważną rolę gra rozszerzenie. OWASP wyjaśnia, że archiwum .tar, .zip albo .gz ma inne rozszerzenie niż kod źródłowy, więc serwer nie wykona zawartego w nim kodu, tylko odda plik do pobrania ^[6]. Tak samo działa plik PHP z dopisaną końcówką .old albo .bak: serwer nie przekaże go do interpretera, tylko wyśle jego treść jako tekst.

Rodzaje

Wytyczne OWASP opisują, skąd biorą się takie pliki ^[6]: edytory tekstu tworzą automatyczne kopie, na przykład z tyldą na końcu nazwy; administratorzy robią ręczne kopie z końcówką .old albo archiwa; systemy plików zapisują migawki; kopiowanie w systemie Windows tworzy pliki z przedrostkiem „Copy of”.

Sekurak opisuje, że w skrajnych przypadkach, takich jak pozostawiony katalog .git lub .svn, pliki te dają dostęp do kodu źródłowego aplikacji ^[1]. Nawet gdy serwer nie pokazuje listy plików w katalogu i zwraca kod 403, sama odpowiedź inna niż 404 zdradza, że katalog istnieje ^[1]. MITRE dodaje, że metadane repozytorium mogą zawierać nazwy użytkowników, ścieżki, adresy IP i szczegółowe różnice między wersjami ^[5].

W WordPressie

W WordPressie najcenniejszym plikiem jest wp-config.php, bo zawiera dane dostępowe do bazy i klucze bezpieczeństwa. Sam plik jest wykonywany przez PHP i nie oddaje treści, ale jego kopia z inną końcówką już tak. Dokumentacja WordPressa zaleca przeniesienie wp-config.php katalog wyżej niż instalacja albo zablokowanie dostępu do niego regułą serwera ^[7]; szerzej opisuje to hasło utwardzanie pliku wp-config.php (wp-config hardening). Ten sam poradnik zaleca regularne kopie zapasowe całej instalacji i bazy w zaufanym miejscu ^[7], czyli poza katalogiem publicznym.

Drugim źródłem ryzyka są wtyczki do kopii zapasowych i migracji, które zapisują archiwa w wp-content. MITRE jako przykład słabości CWE-530 podaje CVE-2024-7315: wtyczkę WordPressa, która generowała nazwy plików kopii zapasowych bez wystarczającej losowości, co pozwalało atakującym je pobrać ^[4]. Zob. podatność we wtyczce. Gdy do tego dochodzi włączone listowanie katalogów (directory listing), nazw nie trzeba nawet zgadywać.

Zagrożenia i skutki

Jedno pobranie pliku wystarcza, by przejść od rekonesansu do włamania. OWASP wymienia ujawnienie kodu źródłowego, jawne nazwy użytkowników i hasła w starych plikach, podatności naprawione już w nowszej wersji, ale obecne w starej kopii, oraz szczegóły konfiguracji, takie jak ścieżki i struktury danych ^[6]. MITRE dodaje, że z kopii zapasowych atakujący może poznać zapytania do bazy, format parametrów przyjmowanych przez aplikację i architekturę serwisu ^[4].

Zrzut bazy strony WordPress zawiera zwykle dane klientów i skróty haseł, więc jego pobranie jest wyciekiem danych, a często także naruszeniem ochrony danych osobowych. Z wp-config.php atakujący dostaje dane uwierzytelniające do bazy danych.

Jak się bronić

• Kopie poza katalogiem WWW. MITRE zaleca politykę zakazującą trzymania kopii kodu aplikacji w katalogu głównym serwisu ^[4]. OWASP dodaje osobne katalogi niedostępne z sieci na pliki danych, logi i konfigurację ^[6].
• Bez edycji na produkcji. Zakaz edycji plików bezpośrednio na serwerze produkcyjnym ogranicza powstawanie automatycznych kopii ^[6].
• Bez repozytorium na serwerze. MITRE zaleca usuwać katalogi systemów kontroli wersji z serwerów produkcyjnych ^[5].
• Reguły serwera. Odmowa dostępu do plików kopii i ukrytych katalogów w konfiguracji serwera; zob. zabezpieczenia w .htaccess.
• Sekrety poza plikami w katalogu strony. zarządzanie sekretami ogranicza szkody, gdy plik jednak wycieknie.

Przykładowa reguła Apache odmawia dostępu do typowych plików kopii i ukrytych plików:

<FilesMatch "\.(bak|old|sql|zip|tar|gz|env)$|^\.">
  Require all denied
</FilesMatch>

Reguła jest tylko dodatkową warstwą. Plik o nazwie spoza listy nadal będzie dostępny, dlatego podstawą pozostaje trzymanie takich plików poza katalogiem strony i okresowe skanowanie podatności.

Historia i przykłady

Sekurak w listopadzie 2025 roku opisał znalezisko badacza Neo Security: publicznie dostępny plik BAK o wielkości 4 TB w usłudze Azure Blob Storage, zawierający kopię bazy danych SQL ^[3]. Plik nie był zaszyfrowany ^[3]. Właścicielem okazała się firma EY; po zgłoszeniu plik przestał być dostępny ^[3].

W serwisie Niebezpiecznik opisano eksperyment rozpoczęty w czerwcu 2023 roku: autor umieścił na swojej stronie pułapkowy backup.zip i widoczne repozytorium .git ^[2]. Przez osiem miesięcy dostał 11 e-maili o wystawionym repozytorium, w tym jeden automatyczny z serwisu wyszukującego takie przypadki ^[2].