Ich hatte kürzlich ein Problem, bei dem ich das WP Smush Pro-Plugin nicht installieren konnte, weil ich keine manuelle Installation oder One-Click-Installation habe Optionen verfügbar.
Ich bin auf in diesem Beitrag gestoßen, in dem vorgeschlagen wurde, die Einstellungen in wp-config.php zu ändern. Ich habe die vorgeschlagenen Einstellungen hinzugefügt, aber die wichtigste scheint zu sein:
define("FS_METHOD", "direct");
Was ich gerne wissen würde Welche wirklichen Bedenken sollte ich haben, wenn ich FS_METHOD auf direct setze? Gibt es andere Alternativen zur Installation des Plugins?
Dies ist, was die offizielle Dokumentation zu sagen hat:
FS_METHOD erzwingt die Dateisystemmethode. Sie sollte nur „direkt“, „ssh2″, “ ftpext „oder“ ftpsockets „. Im Allgemeinen sollten Sie dies nur ändern, wenn Aktualisierungsprobleme auftreten. Wenn Sie es ändern und es nicht hilft, ändern Sie es zurück / wieder verschieben. In den meisten Fällen funktioniert das Setzen auf „ftpsockets“, wenn die automatisch ausgewählte Methode dies nicht tut.
(Primäreinstellung) „direct“ erzwingt die Verwendung von Direct File I / O-Anforderungen aus PHP Dies wird bei Bedarf automatisch ausgewählt, wenn Sicherheitsprobleme auf schlecht konfigurierten Hosts auftreten.
Antwort
So habe ich die Idee der WordPress-Datei-API verstanden. Wenn es falsch ist, stimmen Sie bitte ab 🙂
Okay. Wenn Sie eine Datei hochladen, hat diese Datei einen Eigentümer. Wenn Sie Ihre Datei mit FTP hochladen, melden Sie sich an und die Datei gehört dem FTP-Benutzer. Da Sie über die Anmeldeinformationen verfügen, können Sie diese Dateien über FTP ändern. Der Eigentümer kann die Datei normalerweise ausführen, löschen, ändern usw. Sie können dies natürlich ändern, indem Sie die Dateiberechtigungen ändern.
Wenn Sie eine Datei mit PHP hochladen, ist dies der Linux-Benutzer Das Ausführen von PHP besitzt die Datei. Dieser Benutzer kann nun die Datei bearbeiten, löschen, ausführen usw. Dies ist in Ordnung, solange nur Sie der Benutzer sind, der PHP auf Ihrem System ausführt.
Nehmen wir an, Sie befinden sich auf einem „schlecht“ konfigurierten gemeinsam genutzten Host. Viele Leute betreiben ihre PHP-Websites auf diesem System. Nehmen wir an, nur ein Linux-Benutzer führt PHP für all diese Personen aus. Einer der Webmaster auf diesem gemeinsam genutzten Host hat schlechte Absichten. Er sieht Ihre Seite und findet den Weg zu Ihrer WordPress-Installation heraus. Zum Beispiel wird WP_DEBUG auf true gesetzt und es gibt eine Fehlermeldung wie
[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1 „Ha!“ sagt der böse Junge. Mal sehen, ob dieser Typ FS_METHOD auf direct gesetzt hat und ein Skript wie
Da nur ein Benutzer PHP ausführt und dieser Benutzer auch vom bösen Jungen verwendet wird, kann er die Dateien auf Ihrem System ändern / löschen / ausführen, wenn Sie sie über PHP hochgeladen und damit das PHP angehängt haben Benutzer als Eigentümer.
Ihre Website wird gehackt.
Oder, wie im Codex angegeben:
Bei vielen Hosting-Systemen wird der Webserver als anderer Benutzer ausgeführt als der Eigentümer der WordPress-Dateien. Wenn dies der Fall ist, hat ein Prozess, der Dateien vom Webserver-Benutzer schreibt, die resultierenden Dateien, die dem Benutzerkonto des Webservers gehören, anstelle des tatsächlichen Benutzerkontos. Dies kann zu einem Sicherheitsproblem in gemeinsam genutzten Hosting-Situationen führen, in denen mehrere Benutzer denselben Webserver für verschiedene Websites gemeinsam nutzen.
Antwort
Was ist das Risiko?
Auf einem schlecht konfigurierten gemeinsam genutzten Host wird das PHP jedes Kunden als derselbe Benutzer ausgeführt (sagen wir apache zur Diskussion). Dieses Setup ist überraschend häufig.
Wenn Sie sich auf einem solchen Host befinden und WordPress verwenden, um das Plugin mit direktem Dateizugriff zu installieren, alle Ihre Plugin-Dateien gehören zu apache. Ein legitimer Benutzer auf demselben Server kann Sie angreifen, indem er ein PHP-Skript schreibt, das bösen Code in Ihre Plugin-Dateien einfügt. Sie laden ihr Skript auf ihre eigene Website hoch und fordern deren URL an. Ihr Code wurde erfolgreich kompromittiert, da das Skript als apache ausgeführt wird, derselbe, dem Ihre Plugin-Dateien gehören.
Was bedeutet FS_METHOD "direct" hat damit zu tun?
Wenn WordPress Dateien (z. B. ein Plugin) installieren muss, verwendet es die get_filesystem_method () Funktion, um zu bestimmen, wie auf das Dateisystem zugegriffen werden soll. Wenn Sie FS_METHOD nicht definieren, wird ein Standard für Sie ausgewählt, andernfalls wird Ihre Auswahl verwendet, solange dies sinnvoll ist.
Das Standardverhalten versucht festzustellen, ob Sie sich in einer gefährdeten Umgebung wie der befinden eine, die ich oben beschrieben habe, und wenn es denkt, dass Sie „sicher sind, wird es die "direct" -Methode verwenden. In diesem Fall erstellt WordPress die Dateien direkt über PHP, sodass sie dem Benutzer apache gehören (in diesem Beispiel). Andernfalls wird auf eine sicherere Methode zurückgegriffen, z. B. Sie werden aufgefordert, SFTP-Anmeldeinformationen einzugeben und die Dateien so zu erstellen, wie Sie es möchten.
FS_METHOD = "direct" fordert WordPress auf, dies bei zu umgehen -Risikoerkennung und immer Dateien mit der Methode "direct" erstellen.
Warum dann FS_METHOD = "direct"?
Leider ist die WordPress-Logik zum Erkennen einer gefährdeten Umgebung fehlerhaft und erzeugt sowohl falsch-positive als auch falsch-negative Ergebnisse. Hoppla. Der Test beinhaltet das Erstellen einer Datei und das Sicherstellen, dass sie demselben Eigentümer gehört wie das Verzeichnis, in dem sie sich befindet. Wenn die Benutzer identisch sind, wird PHP als Ihr eigenes Konto ausgeführt und es ist sicher, Plugins als solche zu installieren Wenn sie sich unterscheiden, geht WordPress davon aus, dass PHP als freigegebenes Konto ausgeführt wird und es nicht sicher ist, Plugins als dieses Konto zu installieren. Leider handelt es sich bei beiden Annahmen um fundierte Vermutungen, die häufig falsch sind.
Sie würden define("FS_METHOD", "direct" ); in einem falsch positiven Szenario wie diesem verwenden: Sie sind Teil eines vertrauenswürdigen Teams, dessen Mitglieder alle Dateien über ihr eigenes Konto hochladen. PHP wird separat ausgeführt Benutzer. WordPress geht davon aus, dass dies eine gefährdete Umgebung ist, und verwendet nicht standardmäßig den Modus "direct". In Wirklichkeit wird es nur für Benutzer freigegeben, denen Sie vertrauen, und als solche "direct" ist sicher. In diesem Fall sollten Sie define("FS_METHOD", "direct" ); verwenden, um WordPress zu zwingen, Dateien direkt zu schreiben.
Kommentare
- Vielen Dank Sie @mark, es war sehr nützlich! Möglicherweise müssen Sie den Link
get_filesystem_method()auf diesen Link aktualisieren: developer.wordpress.org/reference/functions/…
Antwort
Es gibt eine“ gut konfigurierte “ Situation, in der „direkt“ zu Problemen führt.
Es ist auch möglich, gemeinsam genutztes WP-Hosting mit nicht gemeinsam genutzten PHP-Ausführungsbenutzern zu konfigurieren, die sich von den Benutzern mit Datei- / Verzeichnisbesitz unterscheiden. Sie erhalten also die Dateien, die Benutzer1 gehören, und der PHP-Code wird als PHP-Benutzer1 ausgeführt.
In dieser Situation können gehackte Plugins oder Kerncode (a) nicht in (1) schreiben (oder sogar lesen) , abhängig von den Berechtigungen) Verzeichnisse anderer Benutzer; (b) kann die Dateien dieses Benutzers nicht schreiben und kann dem Kern- oder Plugin-Code keinen Trojaner-Code hinzufügen.
Wenn das Hosting also so eingerichtet ist , MÜSSEN Sie FTP für Updates verwenden und „direct“ funktioniert nicht.
Wenn Sie in wp-config.php „direct“ festlegen und der PHP-Ausführungsbenutzer keine Schreibberechtigung hat, erhalten Sie „Update“ Fehlgeschlagene Nachrichten und kein Popup, in dem Sie nach FTP-Anmeldeinformationen gefragt werden.