zabezpieczenia w .htaccess

Zabezpieczenia w .htaccess to reguły dopisane do pliku .htaccess serwera Apache, które ograniczają dostęp do wrażliwych plików i katalogów WordPressa. Plik .htaccess jest rozproszonym plikiem konfiguracyjnym: dyrektywy umieszczone w katalogu działają w nim i we wszystkich podkatalogach ^[1]. WordPress używa go do obsługi przyjaznych adresów, a właściciel strony może w nim dopisać reguły blokujące na przykład wp-config.php, xmlrpc.php albo wykonywanie PHP w katalogu uploads ^{[3] [6]}. To jedna z technik, które składają się na utwardzanie (hardening) strony.

Jak działa

Apache przy każdym żądaniu szuka plików .htaccess w katalogu docelowym i we wszystkich katalogach nadrzędnych, a następnie stosuje znalezione dyrektywy w kolejności ^[1]. Plik w podkatalogu może nadpisać ustawienia z katalogu wyżej ^[1]. To, które dyrektywy są honorowane, określa w głównej konfiguracji serwera dyrektywa AllowOverride; jej domyślna wartość None oznacza, że pliki .htaccess są całkowicie ignorowane ^[1]. Według dokumentacji Apache pliki .htaccess stosuje się tam, gdzie użytkownik nie ma uprawnień roota, na przykład na hostingu zarządzanym z panelem cPanel lub Plesk ^[1].

Drogę żądania do chronionego pliku pokazuje schemat poniżej.

RYS. 1Żądanie do chronionego pliku

Reguły stojące przed WordPressem zatrzymują żądanie, zanim uruchomi się PHP. Dlatego dokumentacja wymienia je jako drugą warstwę ochrony dla skryptów, do których nikt nie powinien sięgać bezpośrednio ^[2].

Składniki

Najczęściej stosowane reguły zestawia tabela.

Przykładowy zestaw obronnych reguł w składni Apache 2.4:

# Reguły własne — poza blokiem # BEGIN WordPress
<Files "wp-config.php">
Require all denied
</Files>

<Files "xmlrpc.php">
Require all denied
</Files>

Options -Indexes

Blokada wykonywania PHP trafia do osobnego pliku .htaccess w katalogu wp-content/uploads:

# wp-content/uploads/.htaccess
<FilesMatch "\.php$">
Require all denied
</FilesMatch>

W WordPressie

Blok # BEGIN WordPress. WordPress sam zapisuje swoje reguły przepisywania adresów między znacznikami # BEGIN WordPress i # END WordPress ^[3]. Dokumentacja ostrzega, że WordPress może nadpisać wszystko, co znajduje się między tymi znacznikami, dlatego własne reguły trzeba umieszczać poza nimi ^[2]. LH.pl zaleca przed edycją skopiować plik na komputer i zachować dodatkową kopię ^[6].

Składnia Apache 2.2 i 2.4. W wielu poradnikach, także polskich, reguły są zapisane dyrektywami Order, Allow i Deny ^[6]. W Apache 2.4 kontrolę dostępu przejął moduł mod_authz_host, a stare dyrektywy należy zastąpić nowymi; zgodność zapewnia jedynie moduł mod_access_compat ^[4]. Odpowiednikiem Order deny,allow i Deny from all jest Require all denied ^[4]. Dokumentacja Apache ostrzega przed mieszaniem starych i nowych dyrektyw w tej samej konfiguracji ^[4].

Serwer Nginx. Nginx nie ma plików konfiguracyjnych na poziomie katalogu, takich jak .htaccess ^[5]. Na takim serwerze reguły o tym samym celu, na przykład zakaz wykonywania plików PHP w katalogu uploads albo blokadę plików ukrytych, wpisuje się do konfiguracji serwera ^[5]. Plik .htaccess skopiowany na taki serwer nie chroni więc niczego.

Wtyczki. Część wtyczek bezpieczeństwa działa jak zapora, zmieniając .htaccess i ograniczając dostęp na poziomie Apache, zanim żądanie trafi do WordPressa ^[2].

Znaczenie

Reguły w .htaccess realizują kilka odrębnych zabezpieczeń, z których każde ma własne hasło:

• utwardzanie pliku wp-config.php (wp-config hardening) — plik z danymi dostępowymi do bazy jest niedostępny z przeglądarki;
• listowanie katalogów (directory listing) — wyłączone przez Options -Indexes;
• blokada wykonywania PHP w katalogu uploads — webshell wgrany przez błąd formularza nie uruchomi się;
• ochrona XML-RPC przed atakami siłowymi (brute-force);
• biała lista adresów IP (IP allowlisting) dla strony logowania.

Dokumentacja Apache wskazuje też ograniczenia. Jeśli jest dostęp do głównej konfiguracji serwera, wszystkie reguły powinny trafić tam, bo pliki .htaccess obciążają serwer przy każdym żądaniu ^[1]. Z punktu widzenia bezpieczeństwa zezwolenie na .htaccess oznacza, że użytkownicy mogą zmieniać konfigurację serwera ^[1]. Plik zapisywalny przez WordPress może więc zmienić także napastnik, który przejął stronę.

Dobre praktyki

• Własne reguły umieszczać poza blokiem # BEGIN WordPress ^[2] i zachować kopię pliku przed zmianą ^[6].
• Pisać reguły w składni Apache 2.4 (Require) i nie mieszać jej ze starą ^[4].
• Blokady zakładać wąsko, na konkretne pliki. Dokumentacja WordPressa zauważa, że rozbudowane przepisywanie adresów w .htaccess i Basic Auth na całym katalogu wp-admin bywają zawodne i psują wtyczki korzystające z AJAX ^[7]; zabezpieczenie całego wp-admin może zablokować admin-ajax.php ^[2].
• Po wdrożeniu sprawdzić działanie: wgrać testowy plik PHP do uploads i spróbować go otworzyć ^[5].
• Tam, gdzie to możliwe, filtrować ruch wcześniej, na poziomie WAF lub CDN, zanim dotrze do serwera ^[7].
• Sprawdzić uprawnienia plików: dokumentacja dopuszcza zapis .htaccess przez serwer WWW tylko wtedy, gdy WordPress ma sam generować reguły przepisywania ^[2].

Historia i przykłady

Blokada plików tylko do dołączania, publikowana w dokumentacji utwardzania WordPressa, zawiera reguły dla wp-admin/includes/ i katalogu wp-includes/ z zastrzeżeniem, że w sieci Multisite reguła dla plików PHP w wp-includes zablokuje generowanie obrazów przez ms-files.php ^[2]. Pominięcie tej linii przywraca działanie kosztem słabszej ochrony ^[2]. Ten przykład dobrze pokazuje charakter zabezpieczeń w .htaccess: każda reguła wymaga sprawdzenia na konkretnej instalacji, najlepiej najpierw na środowisku testowym.