blokada wykonywania PHP w katalogu uploads

Blokada wykonywania PHP w katalogu uploads to reguła serwera WWW, która zabrania uruchamiania plików .php w katalogu przeznaczonym na media, w WordPressie wp-content/uploads. Nawet gdy atakujący zdoła wgrać tam skrypt, serwer go nie wykona. OWASP zaleca, by katalog na przesłane pliki nie miał uprawnień do wykonywania, a wszystkie obsługi skryptów były z niego usunięte ^[2]. Jest to jeden z typowych elementów, z których składa się utwardzanie (hardening) WordPressa ^[6].

Jak działa

Blokada odpowiada na słabość CWE-434: produkt pozwala wgrać lub przesłać pliki niebezpiecznego typu, które są potem automatycznie przetwarzane w jego środowisku ^[1]. W zestawieniu CWE Top 25 za 2024 rok słabość ta zajęła 10. miejsce ^[3]. MITRE ilustruje ją przykładem w PHP: formularz zapisuje plik bez sprawdzenia typu, atakujący wgrywa malicious.php i wykonuje polecenia systemowe, wywołując ten plik z parametrem w adresie ^[1].

Taki skrypt to webshell. MITRE ATT&CK definiuje go jako skrypt umieszczony na publicznie dostępnym serwerze WWW, który daje przeciwnikowi dostęp do serwera jako bramy do sieci ^[8]. Według OWASP webshell pozwala wykonywać polecenia, przeglądać pliki systemu i zasoby lokalne oraz atakować inne serwery ^[2].

Blokada przerywa łańcuch w ostatnim kroku. Plik może leżeć na dysku, ale żądanie HTTP do niego kończy się odmową zamiast wykonania kodu, co pokazuje schemat poniżej.

RYS. 1Webshell w uploads z blokadą i bez niej

Odmiany

Sposób wdrożenia zależy od serwera WWW, bo Apache i nginx inaczej przyjmują konfigurację katalogową.

Apache. Dyrektywy z pliku .htaccess obowiązują w katalogu, w którym plik leży, i we wszystkich podkatalogach ^[5]. Dokumentacja Apache przypomina jednak, że domyślna wartość AllowOverride to None, a wtedy pliki .htaccess są całkowicie ignorowane ^[5]. Poradnik LH.pl podaje regułę umieszczaną w pliku .htaccess w katalogu uploads ^[7]:

# wp-content/uploads/.htaccess
<Files *.php>
deny from all
</Files>

nginx. Dokumentacja WordPressa zaznacza, że nginx nie ma plików konfiguracji na poziomie katalogu, takich jak .htaccess w Apache ^[4]. Regułę trzeba więc dopisać do konfiguracji serwera. Dokumentacja podaje blok, który działa także w instalacjach w podkatalogu i w sieci Multisite ^[4]:

location ~* /(?:uploads|files)/.*\.php$ {
    deny all;
}

W WordPressie

Katalog wp-content/uploads musi być zapisywalny dla serwera, bo trafiają do niego media wgrywane przez użytkowników. To czyni go naturalnym celem. LH.pl pisze, że ataki na strony WordPressa często wykorzystują mniej zabezpieczone foldery do uruchomienia szkodliwych skryptów, a takim folderem jest właśnie wp-content/uploads ^[7].

Drogą wejścia zwykle jest podatność we wtyczce typu wgranie dowolnego pliku (arbitrary file upload). OWASP opisuje obejścia filtrów, takie jak podwójne rozszerzenia w rodzaju file.php.jpg ^[2], oraz podmianę nagłówka Content-Type przez serwer pośredniczący, która pokonuje kontrolę opartą tylko na tym nagłówku ^[2]. Blokada na poziomie serwera działa niezależnie od tego, czy kontrola we wtyczce zawiodła.

Wtyczki bezpieczeństwa potrafią dopisać reguły same. Sucuri opisuje opcję, która blokuje wykonywanie PHP w wp-content/uploads, wp-content i wp-includes, dodając zestaw reguł do pliku .htaccess w każdym z tych katalogów ^[6]. Szerzej reguły tego typu opisuje hasło zabezpieczenia w .htaccess.

Zagrożenia i skutki

Bez blokady udane wgranie pliku PHP oznacza zwykle zdalne wykonanie kodu (RCE). OWASP ocenia skutki tej podatności jako wysokie, bo kod może zostać wykonany w kontekście serwera ^[2]. Z webshella atakujący może zostawić tylną furtkę (backdoor), wstrzyknąć złośliwe oprogramowanie (malware) do plików strony albo przejść do innych serwisów na tym samym koncie hostingowym.

Blokada ma też granice:

• dotyczy bezpośrednich żądań HTTP do pliku; nie powstrzyma skryptu, który dołączy wgrany plik przez include, na przykład przy podatności LFI (Local File Inclusion);
• w konfiguracji Apache z AllowOverride None reguła w .htaccess nie działa wcale ^[5];
• na nginx plik .htaccess niczego nie zmienia, reguła musi trafić do konfiguracji serwera ^[4];
• niektóre motywy i wtyczki potrzebują wykonywania PHP w tym katalogu, więc po wdrożeniu mogą działać nieprawidłowo ^[7]. Sucuri przewiduje w takim przypadku listę wyjątków ^[6].

Jak się bronić

Blokada jest jedną z kilku warstw. OWASP zaleca filtrowanie i sprawdzanie treści każdego wgrywanego pliku oraz listę dozwolonych rozszerzeń zamiast przyjmowania nazwy pliku wprost ^[2]. Zaleca też, by przez formularze wgrywania nie dało się podmienić plików konfiguracyjnych, takich jak .htaccess czy web.config ^[2]. MITRE proponuje przechowywanie wgranych plików całkowicie poza katalogiem dokumentów serwera i serwowanie ich innym mechanizmem ^[1].

MITRE ATT&CK przeciw webshellom zaleca zasadę najmniejszych uprawnień: tylko uprawnione konta powinny móc modyfikować katalog WWW ^[8]. W WordPressie oznacza to przemyślane uprawnienia plików. Uzupełnieniem jest monitorowanie integralności plików, które pokaże nowy plik .php w katalogu na media, oraz WAF, który może zatrzymać samo wgranie.

Po wdrożeniu warto sprawdzić, czy reguła działa: wgrać testowy plik PHP o nieszkodliwej treści i otworzyć go w przeglądarce. Oczekiwany wynik to odmowa dostępu, a nie wykonanie skryptu ani pobranie jego źródła.