zabezpieczenie katalogu hasłem

Zabezpieczenie katalogu hasłem (HTTP Basic Authentication) to dodatkowe hasło, którego żąda sam serwer WWW, zanim przekaże żądanie do aplikacji. W WordPressie stosuje się je zwykle przed formularzem logowania albo katalogiem /wp-admin/. Dokumentacja WordPressa opisuje taką ochronę po stronie serwera jako drugą warstwę wokół panelu, ekranu logowania i plików ^[1]. Atakujący albo bot musi najpierw pokonać tę warstwę, a dopiero potem dociera do właściwych plików panelu ^[1].

Jak działa

Mechanizm opisuje RFC 7617. Schemat „Basic” przesyła dane uwierzytelniające jako parę identyfikator użytkownika i hasło, zakodowaną w Base64 ^[3]. Klient łączy identyfikator, dwukropek i hasło, a wynik koduje w Base64 ^[3]. Base64 to kodowanie, a nie szyfrowanie. Dlatego RFC zastrzega, że schemat nie jest bezpieczną metodą uwierzytelniania bez zewnętrznego zabezpieczenia, takiego jak TLS, bo identyfikator i hasło idą przez sieć otwartym tekstem ^[3].

Przeglądarka pokazuje wtedy własne okienko logowania, a nie formularz strony. Przebieg pierwszego wejścia pokazuje schemat poniżej.

RYS. 1Hasło serwera przed wp-login.php

Nazwa obszaru chronionego (realm) ma dwie funkcje. Przeglądarka pokazuje ją w oknie hasła i na jej podstawie decyduje, które hasło wysłać dla danego obszaru ^[4]. Po zalogowaniu w jednym obszarze przeglądarka sama ponawia to hasło dla innych miejsc na tym samym serwerze z tą samą nazwą ^[4].

Składniki

Konfiguracja składa się z pliku z hasłami i kilku dyrektyw serwera. W Apache można je umieścić w głównej konfiguracji albo w pliku .htaccess; druga droga wymaga, by serwer zezwalał na to dyrektywą AllowOverride AuthConfig ^[4]. Szerzej o tej drodze mówi hasło zabezpieczenia w .htaccess.

Plik z hasłami tworzy program htpasswd. Program zapisuje skróty haseł algorytmem bcrypt, zmodyfikowanym MD5, SHA-1 albo funkcją systemową crypt() ^[5]. Domyślny od wersji 2.2.18 jest MD5, a przełącznik -B wybiera bcrypt, który dokumentacja określa jako obecnie bardzo bezpieczny ^[5]. SHA-1 i klasyczny crypt() dokumentacja uznaje za niebezpieczne według dzisiejszych standardów ^[5]. Plik trzyma więc skróty, a nie hasła wprost.

Dokumentacja Apache zaleca, by plik z hasłami leżał w miejscu niedostępnym z sieci, tak by nikt nie mógł go pobrać ^[4]. Przykład: gdy strona jest serwowana z /usr/local/apache/htdocs, plik haseł można trzymać w /usr/local/apache/passwd ^[4].

W WordPressie

Sekurak w poradniku zabezpieczania WordPressa wskazuje standardowy mechanizm HTTP Basic Authentication jako jedną ze zmian w konfiguracji serwera, obok dopuszczania dostępu do panelu tylko z wybranych adresów IP ^[7]. Ta druga metoda to biała lista adresów IP.

Podstawowy problem dotyczy pliku admin-ajax.php. Leży on w katalogu /wp-admin/, a korzysta z niego także front strony. Dokumentacja WordPressa ostrzega, że samo zabezpieczenie katalogu /wp-admin/ może zepsuć część funkcji, na przykład obsługę AJAX w wp-admin/admin-ajax.php ^[1]. Nowszy rozdział o atakach siłowych idzie dalej. Wymienia BasicAuth na całym /wp-admin wśród starszych zaleceń, które psują wtyczki oparte na AJAX albo pogarszają wygodę ^[2]. Zaleca, by blokady na poziomie serwera obejmowały wąski zakres, na przykład /wp-login.php i /xmlrpc.php, oraz by opisać wyjątki potrzebne stronie ^[2].

Poniższy fragment jest ilustracją takiego wąskiego zakresu dla Apache. Ścieżka do pliku haseł jest przykładowa i leży poza katalogiem strony.

<Files "wp-login.php">
  AuthType Basic
  AuthName "Panel example.com"
  AuthUserFile "/home/example/.htpasswd"
  Require valid-user
</Files>

Gdy chroniony jest cały katalog /wp-admin/, wyjątek dla admin-ajax.php buduje się z dyrektywy Require all granted, która przepuszcza wszystkie żądania ^[8]. Dokumentacja WordPressa w przykładach dla serwera radzi też kierować odpowiedzi 401 i 403 do statycznych stron błędu ^[2].

Znaczenie i ograniczenia

Zysk polega na tym, że boty nie docierają do uwierzytelniania WordPressa. Dokumentacja podkreśla, że wiele ataków na WordPressa prowadzą automatycznie złośliwe boty ^[1]. Najczęstsze ataki dzieli na dwie grupy: żądania z ładunkiem dla znanych podatności oraz zgadywanie haseł metodą siłową ^[1]. Zabezpieczenie katalogu hasłem pomaga głównie na tę drugą grupę, obok takich środków jak limit prób logowania i ochrona przed atakami brute force.

Ograniczenia są trzy.

• Poufność zależy od HTTPS. Apache przypomina, że Basic wysyła hasło od klienta do serwera niezaszyfrowane i nie powinien chronić danych wrażliwych bez mod_ssl ^[4].
• Wspólne hasło. Sekurak zauważa, że gdy do panelu potrzebuje dostępu większa grupa osób, pojawia się pokusa współdzielenia poświadczeń, a rozwiązanie traci elastyczność ^[7]. Dla takich przypadków poradnik wskazuje uwierzytelnianie wieloskładnikowe ^[7].
• Nie łata podatności. Warstwa hasła nie chroni wtyczek dostępnych z frontu, w tym admin-ajax.php i REST API; zob. niezabezpieczony endpoint REST API.

Dobre praktyki

Rozdział WordPressa o atakach siłowych jako główne środki wymienia silne i unikalne hasła, menedżer haseł i uwierzytelnianie dwuskładnikowe dla wszystkich administratorów ^[2]. Zabezpieczenie katalogu hasłem jest dodatkiem do tych środków, a nie ich zamiennikiem.

1. Chroń wąski zakres: wp-login.php, ewentualnie xmlrpc.php, zamiast całego /wp-admin/ ^[2].
2. Wymuś HTTPS dla chronionego obszaru ^[3].
3. Twórz plik haseł z przełącznikiem -B (bcrypt) ^[5] i trzymaj go poza katalogiem publicznym ^[4].
4. Zmiany testuj najpierw na kopii strony; dokumentacja WordPressa zaleca sprawdzenie przykładów serwerowych na środowisku testowym przed produkcją ^[2].
5. Zapisz wyjątki, których strona potrzebuje, na przykład aplikacje mobilne, Jetpack albo SSO ^[2].