Ekspozycja .htaccess.bak

Ekspozycja .htaccess.bak to parametr monitoringu stron internetowych, który sprawdza, czy pod adresem /.htaccess.bak serwer WWW oddaje treść kopii pliku konfiguracyjnego .htaccess, zamiast odmówić dostępu albo zgłosić brak pliku. Pomiar kończy się jednym z trzech wyników: kopia dostępna, niedostępna albo nie udało się uzyskać odpowiedzi. Pliki .htaccess to rozproszone pliki konfiguracyjne serwera Apache: umieszczone w katalogu dokumentów zmieniają konfigurację tego katalogu i wszystkich jego podkatalogów ^[1].

Jak działa

Nazwę pliku konfiguracyjnego wyznacza dyrektywa AccessFileName, domyślnie .htaccess ^[2]. O tym, które dyrektywy z pliku serwer uwzględni, decydują AllowOverride i AllowOverrideList ^[1]. Dokumentacja Apache zaleca umieszczanie konfiguracji w pliku głównym, a .htaccess przewiduje dla sytuacji, w których twórcy treści muszą zmieniać konfigurację bez uprawnień administratora, typowych dla hostingu z panelem ^[1]. WordPress używa .htaccess do sterowania tym, jak Apache podaje pliki z katalogu głównego, zwłaszcza do przyjaznych odnośników; podstawowy blok zaczyna się od # BEGIN WordPress i zawiera dyrektywy RewriteEngine i RewriteRule ^[8].

Kopia z dodatkowym rozszerzeniem nie jest dla serwera plikiem konfiguracyjnym, tylko zwykłym plikiem w katalogu dokumentów. OWASP opisuje, że ręczne kopie typu file.bak lub file.old są obsługiwane inaczej niż oryginał i zwykle podawane jako tekst ^[9].

Domyślny plik konfiguracyjny Apache zawiera jednak blok <Files ".ht*"> z dyrektywą Require all denied, opisany jako ochrona plików .htaccess i .htpasswd przed odczytem przez klientów ^[3]. W sekcji <Files> gwiazdka oznacza dowolny ciąg znaków ^[2], więc wzorzec obejmuje także .htaccess.bak. Debian stosuje w tym miejscu wyrażenie regularne <FilesMatch "^\.ht"> z tym samym opisem ^[4]. Wyrażenie nie ma kotwicy końca, więc również pasuje do kopii. Apache z konfiguracją domyślną odmawia zatem dostępu do .htaccess.bak, a wyciek wymaga innego serwera albo zmienionej konfiguracji.

RYS. 1.1Ta sama kopia, dwa serwery

Nginx. Nginx nie ma plików konfiguracyjnych na poziomie katalogu, takich jak .htaccess; całą konfigurację ustawia administrator na poziomie serwera ^[6]. Poradnik WordPressa dla nginx zaleca osobny blok location ~ /\. z deny all, który blokuje pliki ukryte, m.in. .htaccess, .htpasswd i .DS_Store ^[6]. Strona przeniesiona z Apache bez takiego bloku zostawia kopię w katalogu, którego żadna reguła nie chroni.

Zbyt wąska reguła. Przykład ochrony plików wrażliwych w dokumentacji WordPressa używa wzorca ^(wp-config\.php|\.htaccess|\.htpasswd|debug\.log)$ ^[8]. Kotwica końca sprawia, że wzorzec nie obejmuje .htaccess.bak. Kopia pozostaje chroniona tylko wtedy, gdy w konfiguracji głównej działa ogólna reguła dla .ht* ^[3].

Inna nazwa kopii. Plik skopiowany jako htaccess.bak albo htaccess.txt, bez kropki na początku, nie pasuje do wzorca .ht* ^{[2] [3]}.

Standardy i specyfikacje

• Apache HTTP Server, samouczek .htaccess wymienia dwa powody, by woleć plik główny: wydajność i bezpieczeństwo ^[1].
• Apache Core Features definiuje AccessFileName, AllowOverride i składnię wzorców w <Files> ^[2].
• OWASP WSTG-CONF-04 zalicza kopie i pliki bez odnośników pozostawione w katalogach serwera do źródeł wycieku informacji i zauważa, że stare kopie mogą zawierać błędy poprawione w nowszych wersjach ^[9].
• CWE-530 („Exposure of Backup File to an Unauthorized Control Sphere”) to kopia zapasowa zapisana w katalogu lub archiwum dostępnym dla nieuprawnionych; MITRE opisuje kopie przemianowane np. na rozszerzenie .~bk ^[10].

Zagrożenia i skutki

Ścieżka do pliku haseł. Plik .htaccess może włączać uwierzytelnianie; przykład w dokumentacji Apache zawiera AuthType Basic i ścieżkę AuthUserFile do pliku haseł ^[1]. Dokumentacja WordPressa podaje taki blok do ochrony wp-login.php, z pełną ścieżką bezwzględną do .htpasswd ^[8]. Moduł mod_authn_file wymaga, by plik haseł leżał poza drzewem dokumentów, bo inaczej klient może go pobrać ^[5]. Kopia pokazuje, gdzie ten plik leży.

Zapora aplikacji i ścieżki serwera. Wordfence ładuje swoją zaporę przed WordPressem przez dyrektywę php_value auto_prepend_file w .htaccess, z bezwzględną ścieżką do pliku wordfence-waf.php ^[7]. Kopia ujawnia więc obecność zapory, położenie jej pliku i układ katalogów na dysku.

Wyjątki dostępu. Dokumentacja WordPressa pokazuje ograniczanie dostępu do wybranych adresów IP dyrektywami Require ip w bloku <RequireAny> ^[8]. Odczytana kopia wskazuje, z których adresów zabezpieczenie jest pomijane.

RYS. 1.2Od kopii .htaccess do mapy zabezpieczeń

Nieaktualne reguły. Kopia sprzed zmiany pokazuje stan konfiguracji, który mógł zostać poprawiony. OWASP zwraca uwagę, że stara wersja pliku może zawierać błędy usunięte w nowej ^[9].

Przykłady

Sytuacja	Odpowiedź na GET /.htaccess.bak	Znaczenie
Apache z domyślnym blokiem <Files ".ht*"> [3]	403	kopia chroniona tą samą regułą co .htaccess
Apache w Debianie z <FilesMatch "^\.ht"> [4]	403	wyrażenie obejmuje kopię
Tylko reguła z kotwicą końca dla \.htaccess [8]	200 z dyrektywami	reguła nie obejmuje kopii
nginx bez bloku dla plików ukrytych [6]	200 z dyrektywami	nginx nie traktuje pliku jako konfiguracji
nginx z location ~ /\. i deny all [6]	403	plik istnieje, ale nie jest podawany
Kopia nazwana htaccess.bak, bez kropki [2]	zależy od serwera	poza wzorcem .ht*
Kopia z AuthUserFile i ścieżką w katalogu dokumentów [5]	200 z dyrektywami	plik haseł do pobrania pod znanym adresem