Jakie obawy dotyczące bezpieczeństwa powinienem mieć przy ustawianiu FS_METHOD na „direct” w wp-config?

Ostatnio miałem problem z tym, że nie byłem w stanie zainstalować wtyczki WP Smush Pro, ponieważ nie mam dostępnych opcji instalacji ręcznej ani instalacji jednym kliknięciem.

Natknąłem się na ten post, który sugerował dostosowanie ustawień w wp-config.php. Dodałem sugerowane ustawienia, jednak najważniejsze wydaje się:

define('FS_METHOD', 'direct');

Co chciałbym wiedzieć, jest to, co realne obawy bym wokół ustawienie FS_METHODdo direct? Czy są jakieś alternatywy dla instalacji wtyczki?

Oto, co ma do powiedzenia oficjalna dokumentacja:

FS_METHOD wymusza metodę systemu plików. Powinien to być tylko „bezpośredni”, „ssh2”, „ftpext” lub „ftpsockets”. Zasadniczo należy to zmienić tylko w przypadku problemów z aktualizacją. Jeśli to zmienisz, a to nie pomoże, zmień to z powrotem / usuń. W większości przypadków ustawienie go na „ftpsockets” będzie działać, jeśli nie zostanie wybrana automatycznie wybrana metoda.

(Preferencje podstawowe) „bezpośredni” zmusza go do korzystania z bezpośrednich żądań we / wy pliku z poziomu PHP, jest to obarczone otwieraniem problemów bezpieczeństwa na źle skonfigurowanych hostach. Jest to wybierane automatycznie, gdy jest to właściwe.

Właśnie tak zrozumiałem ideę interfejsu API plików WordPress . Jeśli jest źle, proszę zgłoś się :)

W porządku. Jeśli prześlesz plik, ten plik ma właściciela. Jeśli prześlesz plik za pomocą FTP, zaloguj się, a plik będzie własnością użytkownika FTP. Ponieważ masz poświadczenia, możesz zmienić te pliki za pośrednictwem FTP. Właściciel może zwykle wykonać, usunąć, zmienić itp. Plik. Oczywiście możesz to zmienić, zmieniając uprawnienia do plików .

Jeśli prześlesz plik przy użyciu PHP, użytkownik linux, który wykonuje PHP, jest właścicielem pliku. Ten użytkownik może teraz edytować, usuwać, wykonywać itp. Plik. Jest to w porządku, o ile tylko ty jesteś użytkownikiem, który wykonuje PHP w twoim systemie.

Załóżmy, że korzystasz z „źle” skonfigurowanego hosta współdzielonego. Wiele osób prowadzi witryny PHP w tym systemie. Powiedzmy, że tylko jeden użytkownik Linuksa wykonuje PHP dla wszystkich tych osób. Jeden z webmasterów tego udostępnionego hosta ma złe intencje. Widzi twoją stronę i obiera ścieżkę do instalacji WordPressa. Na przykład WP_DEBUG ma wartość true i pojawia się komunikat o błędzie, taki jak

[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1

„Ha!” zły chłopiec mówi. Zobaczmy, czy ten facet ustawił FS_METHODsię directi pisze taki skrypt

<?php
unlink( '/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php' );
?>

Ponieważ tylko jeden użytkownik korzysta z PHP, a ten użytkownik jest również używany przez złego chłopca, może on zmieniać / usuwać / uruchamiać pliki w systemie, jeśli przesłałeś je za pośrednictwem PHP i przez to dołączasz użytkownika PHP jako właściciela.

Twoja strona została zhakowana.

Lub, jak napisano w Kodeksie:

W wielu systemach hostingowych serwer WWW działa jako inny użytkownik niż właściciel plików WordPress. W takim przypadku proces zapisujący pliki od użytkownika serwera WWW będzie miał pliki wynikowe będące własnością konta użytkownika serwera WWW zamiast rzeczywistego konta użytkownika. Może to prowadzić do problemu bezpieczeństwa w sytuacjach hostowania współdzielonego, gdy wielu użytkowników udostępnia ten sam serwer dla różnych witryn.

Jakie jest ryzyko?

Na źle skonfigurowanym współdzielonym hoście PHP każdego klienta będzie działać jako ten sam użytkownik (powiedzmy apachedo dyskusji). Ta konfiguracja jest zaskakująco powszechna.

Jeśli korzystasz z takiego hosta i używasz WordPress do zainstalowania wtyczki przy użyciu bezpośredniego dostępu do plików, wszystkie twoje pliki wtyczek będą należeć do apache. Uprawniony użytkownik na tym samym serwerze mógłby zaatakować cię, pisząc skrypt PHP, który wstrzykuje zły kod do twoich plików wtyczek. Przesyłają swój skrypt na własną stronę internetową i żądają jego adresu URL. Twój kod został pomyślnie naruszony, ponieważ jego skrypt działa jako apacheten sam, który jest właścicielem plików wtyczek.

Co to FS_METHOD 'direct'ma z tym wspólnego?

Kiedy WordPress musi zainstalować pliki (takie jak wtyczka), używa funkcji get_filesystem_method () w celu ustalenia sposobu uzyskania dostępu do systemu plików. Jeśli nie zdefiniujesz FS_METHOD, wybierze dla ciebie wartość domyślną, w przeciwnym razie użyje twojego wyboru tak długo, jak to ma sens.

Domyślne zachowanie spróbuje wykryć, czy znajdujesz się w zagrożonym środowisku, takim jak to, które opisałem powyżej, a jeśli uzna, że ​​jesteś bezpieczny, zastosuje tę 'direct'metodę. W takim przypadku WordPress utworzy pliki bezpośrednio przez PHP, powodując, że należą one do apacheużytkownika (w tym przykładzie). W przeciwnym razie powróci do bezpieczniejszej metody, takiej jak monitowanie o poświadczenia SFTP i tworzenie plików jako ty.

FS_METHOD = 'direct'prosi WordPressa o ominięcie wykrycia zagrożenia i zawsze tworzy pliki przy użyciu tej 'direct'metody.

Więc po co korzystać FS_METHOD = 'direct'?

Niestety, logika WordPress do wykrywania środowiska zagrożonego jest wadliwa i wytwarza zarówno fałszywie dodatnie, jak i fałszywie ujemne. Ups Test polega na utworzeniu pliku i upewnieniu się, że należy on do tego samego właściciela, co katalog, w którym mieszka. Zakłada się, że jeśli użytkownicy są tacy sami, PHP działa jako twoje własne konto i można bezpiecznie instalować wtyczki jako to konto. Jeśli są różne, WordPress zakłada, że ​​PHP działa jako konto współdzielone i instalowanie wtyczek jako tego konta nie jest bezpieczne. Niestety oba te założenia są wykształconymi domysłami, które często będą błędne.

Należałoby użyć define('FS_METHOD', 'direct' );w fałszywym pozytywnym scenariuszu taki jak ten: jesteś częścią zaufanego zespołu, którego członkowie wszystkich plików przesłać poprzez własny rachunek. PHP działa jako osobny użytkownik. WordPress przyjmie, że jest to środowisko zagrożone i nie przejdzie w 'direct'tryb domyślny . W rzeczywistości jest udostępniany tylko zaufanym użytkownikom i jako taki 'direct'tryb jest bezpieczny. W takim przypadku należy użyć, define('FS_METHOD', 'direct' );aby zmusić WordPress do bezpośredniego zapisywania plików.

Istnieje „dobrze skonfigurowana” sytuacja, w której „bezpośredni” doprowadzi do problemów.

Możliwe jest również skonfigurowanie współdzielonego hostingu WP z niepodzielonymi użytkownikami wykonującymi PHP, innymi niż użytkownicy posiadający pliki / katalogi. W rezultacie otrzymujesz pliki należące do user1, a kod PHP jest wykonywany jako php-user1.

W takiej sytuacji zhakowane wtyczki lub kod podstawowy (a) nie mogą zapisywać (lub nawet czytać, w zależności od uprawnień) katalogów innych użytkowników; (b) nie może zapisywać plików tego użytkownika, a zatem nie może dodawać kodu trojana do kodu podstawowego ani kodu wtyczki.

Więc jeśli hosting jest skonfigurowany w ten sposób, MUSISZ używać FTP do aktualizacji, a „bezpośrednie” nie będzie działać.

Jeśli ustawisz opcję „direct” w pliku wp-config.php, a użytkownik wykonujący PHP nie będzie miał uprawnień do zapisu, otrzymasz komunikaty o aktualizacji zakończonej niepowodzeniem i nie będzie wyskakujące okienko z prośbą o poświadczenia FTP.