6 bezpiecznych testów podatności strony i ochrony przed wyciekiem

Bezpieczeństwo firmowej infrastruktury cyfrowej to kwestia, o której właściciele mniejszych biznesów często przypominają sobie dopiero w momencie wystąpienia problemów. Pliki, które nigdy nie powinny być publicznie dostępne, mogą czasami w wyniku błędów wdrożeniowych trafić do głównego katalogu serwera. Mowa tu o pozostawionym katalogu .git, plikach konfiguracyjnych środowiska czy archiwach z kopiami zapasowymi po migracji danych.

Przewodnik OWASP Web Security Testing Guide zwraca uwagę na konkretne ryzyko związane z kopiami plików, takimi jak stare wersje skryptów. Serwer może zwrócić je jako czysty tekst zamiast je wykonać, co bezpośrednio wydostaje wrażliwy kod źródłowy na zewnątrz. Publikowany przez zespół HackerMe materiał opisuje sześć niezależnych od dostawcy metod weryfikacji, które pozwalają sprawdzić stan bezpieczeństwa publicznych serwisów i własnych systemów.

Przed przystąpieniem do jakichkolwiek działań należy pamiętać o podstawowych zasadach bezpieczeństwa. Zawsze wysyłaj zapytanie o pojedynczy, mały plik dla danej ścieżki i na tym poprzestań, nie pobierając całych wystawionych repozytoriów. Wszelkie znalezione realne sekrety traktuj jako skompromitowane, pamiętając, że samo usunięcie pliku nie cofa faktu jego wcześniejszego ujawnienia. Część testów jest bezpieczna dla dowolnej publicznej strony, podczas gdy inne należy wykonywać wyłącznie na systemach własnych lub posiadając pisemną zgodę na testy.

1. Odczyt pliku robots.txt na dowolnej publicznej stronie

Pierwsza metoda jest w pełni bezpieczna dla każdej publicznej witryny internetowej, ponieważ odczytuje jedynie te informacje, które serwis i tak publikuje dla wszystkich użytkowników. Sprawdzenie polega na pobraniu pliku robots.txt za pomocą prostego zapytania, na przykład przy użyciu polecenia curl -s https://example.com/robots.txt.

Podczas analizy należy szukać linii z instrukcją Disallow, które wskazują wrażliwe ścieżki, takie jak /backup, /admin czy /old. Znalezienie takich wpisów oznacza, że plik robots.txt bywa wykorzystywany do ukrywania poufnych miejsc. Zgodnie z normą RFC 9309 zasady te nie stanowią formy autoryzacji dostępu, a jawne wymienianie ścieżek czyni je publicznie odkrywalnymi.

2. Sprawdzenie metadanych Git dla własnych systemów

Repozytorium Git przechowuje całą swoją historię w katalogu .git, w tym magazyn obiektów. Ten test, przeznaczony wyłącznie dla własnych serwisów, polega na wysłaniu żądania do małych plików tekstowych za pomocą poleceń curl sprawdzających odpowiednio plik HEAD oraz początek pliku config.

Oczekiwanym wynikiem dla bezpiecznej witryny jest kod odpowiedzi 404 lub 403, przy czym treść nie powinna zawierać żadnych danych repozytorium. Jeśli HEAD zwraca linię typu ref: refs/heads/main lub config ujawnia sekcję rdzeniową, oznacza to poważny problem. Jeśli katalog jest odczytywalny, należy założyć, że cała historia oraz wszystko, co kiedykolwiek zostało do niej zatwierdzone, może zostać pobrane. Powiązany temat opisaliśmy w artykule „Certyfikat SSL a strona „Niezabezpieczona” – przyczyny i mixed content”.

3. Kontrola plików środowiskowych i konfiguracyjnych

Kolejny krok dotyczy plików takich jak .env, .env.production, .env.local, config.php.bak czy wp-config.php.bak, które mogą ujawniać klucze dostępowe. Test wykonuje się pętlą zapytań sprawdzającą odpowiednie ścieżki dla posiadanej domeny. Więcej o tym, jak to wpływa na pozycjonowanie i widoczność w Google, znajdziesz w opisie usługi.

Prawidłowa odpowiedź serwera dla każdej z tych ścieżek to kod 404 lub 403. Znalezieniem podatności jest dowolny kod 200, który zwraca rzeczywiste linie typu KLUCZ=wartość lub kod konfiguracyjny. Warto zachować ostrożność, ponieważ niektóre serwery zwracają kod 200 ze stroną ogólną dla każdej nieznanej ścieżki. Zawsze należy porównać treść z zapytaniem o ścieżkę, która na pewno nie istnieje.

4. Wyszukiwanie kopii zapasowych, archiwów i kopii edytora

OWASP publikuje listę powszechnie pozostawianych rozszerzeń, takich jak tylda, bak, txt, src, dev, old, inc, orig, copy, tmp czy swp, stosowanych przed, po lub zamiast właściwego rozszerzenia pliku. Testowanie najlepiej zacząć od nazw odpowiadających własnym plikom, sprawdzając na przykład backup.zip lub starsze wersje plików źródłowych.

Oczekiwany rezultat to ponowne uzyskanie kodu błędu 403 lub 404. Znaleziskiem jest natomiast odpowiedź o kodzie 200, której rozmiar odpowiada archiwum lub plikowi źródłowemu. W takiej sytuacji należy natychmiast usunąć plik oraz zbadać drogę, jaką trafił on na serwer produkcyjny.

5. Weryfikacja listowania katalogów na serwerze

Ostatni z opisywanych testów dla własnych systemów skupia się na folderach, które zazwyczaj przechowują pliki użytkowników lub elementy budowy aplikacji, takich jak /uploads/, /backup/ czy /static/. Prawidłowa konfiguracja serwera powinna zwrócić kod 403, 404 lub normalną stronę, nie generując automatycznie spisu plików.

Zagrożenie pojawia się wtedy, gdy serwer wyświetla stronę zatytułowaną Index of wraz z wykazem wszystkich znajdujących się tam zasobów. Taka sytuacja drastycznie ułatwia enumerację plików i przeszukiwanie struktury katalogów przez osoby niepowołane. Jeśli chcesz kompleksowo zadbać o stabilność i poprawność konfiguracji, sprawdź nasze profesjonalne usługi tworzenia stron internetowych, które powstają z zachowaniem najwyższych standardów bezpieczeństwa.

Warto pamiętać, że czysty wynik przeprowadzonych testów nie udowadnia absolutnego bezpieczeństwa całego systemu. Brak wykrycia jawnych plików w sprawdzonych miejscach nie oznacza, że sekrety nie zostały ukryte w innych lokalizacjach, na przykład w spakowanym kodzie JavaScript lub bezpośrednio w publicznej odpowiedzi interfejsu API. Ponadto odgadywanie nazw plików pozwala znaleźć wyłącznie to, o co celowo zapytał osoba przeprowadzająca test.

Co to oznacza dla małej firmy?

Dla właściciela małej firmy kwestie bezpieczeństwa technicznego przekładają się bezpośrednio na stabilność biznesu oraz unikanie kosztownych kryzysów wizerunkowych. Wyciek danych konfiguracyjnych, kluczy dostępowych czy kodu źródłowego może prowadzić do przejęcia witryny przez niepowołane osoby, co na lokalnym rynku na Śląsku – w takich miastach jak Katowice, Bielsko-Biała czy Czechowice-Dziedzice – może zniszczyć lata budowania zaufania klientów.

Regularne audyty oraz poprawna konfiguracja serwerów chronią przed sytuacjami, w których poufne informacje firmowe trafiają do sieci w wyniku drobnych błędów wdrożeniowych. Dbanie o te aspekty podczas codziennego prowadzenia strony internetowej czy sklepu online pozwala skupić się na rozwoju biznesu, mając pewność, że cyfrowa infrastruktura firmy jest odpowiednio zabezpieczona przed podstawowymi zagrożeniami.

Podsumowanie

Bezpieczeństwo witryny internetowej opiera się na sumie drobnych, poprawnie wykonanych kroków konfiguracyjnych i regularnej kontroli. Przeprowadzenie sześciu opisanych testów pozwala szybko zidentyfikować najbardziej oczywiste luki, takie jak wystawione pliki .git, środowiskowe czy stare kopie zapasowe. Choć czysty wynik nie gwarantuje stuprocentowej odporności na każdy rodzaj ataku, systematyczna weryfikacja znacząco podnosi poziom ochrony każdej małej firmy.