Niedawno miałem problem polegający na tym, że nie mogłem zainstalować wtyczki WP Smush Pro, ponieważ nie mam instalacji ręcznej ani instalacji jednym kliknięciem dostępne opcje.

Natrafiłem na ten post , który sugerował zmianę ustawień w wp-config.php. Dodałem sugerowane ustawienia, ale te, które wydają się najważniejsze, to:

define("FS_METHOD", "direct");

Co chciałbym wiedzieć jakie są prawdziwe obawy związane z ustawieniem FS_METHOD na direct? Czy są jakieś inne alternatywy dla instalacji wtyczki?

Oto, co ma do powiedzenia oficjalna dokumentacja:

FS_METHOD wymusza metodę systemu plików. Powinna być tylko „bezpośrednia”, „ssh2″, ” ftpext ”lub„ ftpsockets ”. Ogólnie rzecz biorąc, powinieneś to zmienić tylko wtedy, gdy występują problemy z aktualizacją. Jeśli to zmienisz i nie pomoże, zmień to z powrotem / ponownie rusz to. W większości przypadków ustawienie go na „ftpsockets” zadziała, jeśli automatycznie wybrana metoda nie.

(Primary Preference) „direct” zmusza go do używania żądań Direct File I / O z PHP, to jest najeżony problemami związanymi z bezpieczeństwem na źle skonfigurowanych hostach. Jest to wybierane automatycznie w razie potrzeby.

Odpowiedź

Tak właśnie zrozumiałem ideę WordPress File API . Jeśli to źle, zagłosuj negatywnie 🙂

OK. 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 należał do użytkownika FTP. Ponieważ masz poświadczenia, możesz zmieniać te pliki za pośrednictwem protokołu FTP. Właściciel może zwykle uruchamiać, usuwać, modyfikować itp. Plik. Oczywiście możesz to zmienić, zmieniając uprawnienia do pliku .

Jeśli przesyłasz plik za pomocą PHP, użytkownik linuxa, którym jest wykonywanie PHP jest właścicielem tego 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 znajdujesz się na „słabo” skonfigurowanym hoście współdzielonym. Wiele osób prowadzi swoje strony internetowe w tym systemie. Powiedzmy, że tylko jeden użytkownik Linuksa wykonuje PHP dla wszystkich tych osób. Jeden z webmasterów na tym wspólnym hoście ma złe intencje. Widzi twoją stronę i wymyśla ścieżkę do twojej instalacji WordPress. 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!” mówi zły chłopiec. Zobaczmy, czy ten facet ustawił FS_METHOD na direct i pisze skrypt taki jak 

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

Ponieważ tylko jeden użytkownik używa PHP i ten użytkownik jest również używany przez złego chłopca, może on zmieniać / usuwać / uruchamiać pliki w Twoim systemie, jeśli załadowałeś je przez PHP i do tego dołączyłeś PHP użytkownik jako właściciel.

Twoja witryna została zhakowana.

Lub, jak jest napisane w Kodeksie:

W wielu systemach hostingowych serwer sieciowy działa jako inny użytkownik niż właściciel plików WordPress. W takim przypadku proces zapisujący pliki z użytkownika serwera WWW będzie miał pliki wynikowe należące do konta użytkownika serwera WWW zamiast do konta rzeczywistego użytkownika. Może to prowadzić do problemów z bezpieczeństwem w sytuacjach hostingu współdzielonego, gdy wielu użytkowników korzysta z tego samego serwera WWW dla różnych witryn.

Odpowiedź

Jakie jest ryzyko?

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

Jeśli jesteś na takim hoście i używasz WordPressa do zainstalowania wtyczki przy użyciu bezpośredniego dostępu do plików, wszystko Twoje pliki wtyczek będą należeć do apache. Prawowity użytkownik na tym samym serwerze mógłby cię zaatakować, pisząc skrypt PHP, który wstrzykuje zły kod do plików wtyczek. Przesyłają swój skrypt do własnej witryny i żądają jego adresu URL. Twój kod został pomyślnie przejęty, ponieważ ich skrypt działa jako apache, czyli ten sam, do którego należą pliki wtyczek.

Co oznacza FS_METHOD "direct" ma z tym coś wspólnego?

Gdy WordPress musi zainstalować pliki (np. wtyczkę), używa metody get_filesystem_method () funkcji, aby określić, jak uzyskać dostęp do systemu plików. Jeśli „t nie zdefiniujesz FS_METHOD, wybierze za Ciebie wartość domyślną, w przeciwnym razie użyje Twojego wyboru tak długo, jak będzie to miało sens.

Domyślne zachowanie spróbuje wykryć, czy „znajdujesz się w zagrożonym środowisku, takim jak jeden, który opisałem powyżej, i jeśli uzna, że „jesteś bezpieczny, użyje metody "direct". W tym przypadku WordPress utworzy pliki bezpośrednio przez PHP, powodując, że będą należeć do użytkownika apache (w tym przykładzie). W przeciwnym razie „wrócę do bezpieczniejszej metody, takiej jak monitowanie o podanie danych logowania SFTP i tworzenie plików we własnym imieniu.

FS_METHOD = "direct" prosi WordPress o ominięcie tego na -wykrywanie ryzyka i zawsze twórz pliki przy użyciu metody "direct".

W takim razie po co używać FS_METHOD = "direct"?

Niestety, logika WordPressa służąca do wykrywania zagrożonego środowiska jest błędna i generuje zarówno fałszywie dodatnie, jak i fałszywie ujemne wartości. Ups. Test polega na utworzeniu pliku i upewnieniu się, że należy on do tego samego właściciela, co katalog, w którym się znajduje. Założenie jest takie, że jeśli użytkownicy są tacy sami, PHP działa jako twoje własne konto i można bezpiecznie zainstalować wtyczki Jeśli są różne, WordPress zakłada, że PHP działa jako konto współdzielone i nie jest bezpieczne instalowanie wtyczek na tym koncie. Niestety oba te założenia są wyuczonymi przypuszczeniami, które często będą błędne.

Użyłbyś define("FS_METHOD", "direct" ); w scenariuszu fałszywie dodatnim, takim jak ten: jesteś częścią zaufanego zespołu, którego wszyscy członkowie przesyłają pliki za pośrednictwem własnego konta. PHP działa jako osobne użytkownika. WordPress zakłada, że jest to środowisko zagrożone i nie będzie domyślnie przełączać się na tryb "direct". W rzeczywistości jest on udostępniany tylko użytkownikom, którym ufasz i jako takim jest bezpieczny. W takim przypadku użyj define("FS_METHOD", "direct" );, aby wymusić na WordPressie bezpośrednie zapisywanie plików.

Komentarze

Odpowiedź

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

Możliwe jest również skonfigurowanie współdzielonego hostingu WP z nie współużytkowanymi użytkownikami wykonania PHP, innymi niż użytkownicy będący właścicielami plików / katalogów. W rezultacie otrzymujesz pliki należące do użytkownika 1, a kod PHP jest wykonywany jako php-user1.

W takiej sytuacji zhakowane wtyczki lub rdzeń kodu (a) nie mogą zapisywać (ani nawet odczytywać z w zależności od uprawnień) katalogi innych użytkowników; (b) nie może „napisać tego plików użytkownika, a więc nie może” dodać kodu trojana do rdzenia lub kodu wtyczki.

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

Jeśli ustawisz „bezpośrednio” w wp-config.php, a użytkownik wykonujący PHP nie ma uprawnień do zapisu, otrzymasz aktualizację Wiadomości nieudane i nie mają wyskakującego okienka z prośbą o podanie danych logowania do FTP.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *