Welche Sicherheitsbedenken sollte ich haben, wenn FS_METHOD in wp-config auf "direct" gesetzt wird?

Ich hatte kürzlich ein Problem, bei dem ich das WP Smush Pro-Plugin nicht installieren konnte, weil mir die Optionen Manuelle Installation oder One-Click-Installation nicht zur Verfügung stehen.

Ich bin auf diesen Beitrag gestoßen, in dem vorgeschlagen wurde, die Einstellungen zu ändern wp-config.php. Ich habe die vorgeschlagenen Einstellungen hinzugefügt. Die wichtigste ist jedoch:

define('FS_METHOD', 'direct');

Was würde Ich mag es , wissen , was echte Bedenken sollte ich um Einstellung haben FS_METHODzu direct? Gibt es andere Alternativen zur Installation des Plugins?

Dies ist, was die offizielle Dokumentation zu sagen hat:

FS_METHOD erzwingt die Dateisystemmethode. Es sollte nur "direct", "ssh2", "ftpext" oder "ftpsockets" sein. Im Allgemeinen sollten Sie dies nur ändern, wenn Aktualisierungsprobleme auftreten. Wenn Sie es ändern und es hilft nicht, ändern Sie es zurück / entfernen Sie es. In den meisten Fällen funktioniert das Setzen auf 'ftpsockets', wenn die automatisch gewählte Methode dies nicht tut.

(Primary Preference) "direct" erzwingt die Verwendung von direkten Datei-E / A-Anforderungen aus PHP heraus. Dies ist mit Sicherheitslücken auf schlecht konfigurierten Hosts behaftet. Dies wird bei Bedarf automatisch ausgewählt.

So habe ich die Idee der WordPress-Datei-API verstanden . Wenn es falsch ist, bitte abstimmen :)

Okay. Wenn Sie eine Datei hochladen, hat diese 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.. Natürlich können Sie dies ändern, indem Sie die Dateiberechtigungen ändern .

Wenn Sie eine Datei mit PHP hochladen, besitzt der Linux-Benutzer, der PHP ausführt, 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 Leute aus. Einer der Webmaster auf diesem gemeinsam genutzten Host hat schlechte Absichten. Er sieht Ihre Seite und findet den Pfad zu Ihrer WordPress-Installation heraus. Beispielsweise wird WP_DEBUG auf true gesetzt und es wird eine Fehlermeldung wie angezeigt

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

"Ha!" der böse Junge sagt. Mal sehen, wenn dieser Kerl hat es FS_METHODauf directund er schreibt ein Skript wie

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

Da nur ein Benutzer PHP ausführt und dieser Benutzer auch vom Bad Boy verwendet wird, kann er die Dateien auf Ihrem System ändern / löschen / ausführen, wenn Sie sie über PHP hochgeladen haben und dadurch den PHP-Benutzer als Eigentümer angehängt haben.

Ihre Website wird gehackt.

Oder, wie es im Kodex heißt:

Bei vielen Hosting-Systemen wird der Webserver als ein anderer Benutzer als der Eigentümer der WordPress-Dateien ausgeführt. In diesem Fall enthält ein Prozess, der Dateien vom Webserver-Benutzer schreibt, die resultierenden Dateien, die dem Benutzerkonto des Webservers anstelle des tatsächlichen Benutzerkontos gehören. Dies kann zu einem Sicherheitsproblem in Situationen mit gemeinsamem Hosting führen, in denen mehrere Benutzer denselben Webserver für verschiedene Websites gemeinsam nutzen.

Was ist das Risiko?

Auf einem schlecht konfigurierten gemeinsam genutzten Host wird das PHP jedes Kunden als derselbe Benutzer ausgeführt (sagen wir apachezur Diskussion). Dieses Setup ist überraschend häufig.

Wenn Sie auf einem solchen Host arbeiten und das Plugin mit WordPress über den direkten Dateizugriff installieren, gehören alle Ihre Plugin-Dateien dazu apache. Ein legitimer Benutzer auf demselben Server könnte Sie angreifen, indem er ein PHP-Skript schreibt, das bösen Code in Ihre Plug-in-Dateien einfügt. Sie laden ihr Skript auf ihre eigene Website hoch und fordern deren URL an. Ihr Code wurde erfolgreich kompromittiert, da sein Skript wie apachedas Ihrer Plug-in-Dateien ausgeführt wird.

Was hat das FS_METHOD 'direct'damit zu tun?

Wenn WordPress Dateien (wie ein Plugin) installieren muss, verwendet es die Funktion get_filesystem_method () , um zu bestimmen, wie auf das Dateisystem zugegriffen werden soll . Wenn Sie dies nicht definieren FS_METHOD, wird eine Standardeinstellung für Sie ausgewählt, andernfalls wird Ihre Auswahl verwendet, sofern dies sinnvoll ist.

Das Standardverhalten versucht zu erkennen, ob Sie sich in einer gefährdeten Umgebung wie der oben beschriebenen befinden, und wenn es Sie für sicher hält, wird die 'direct'Methode verwendet. In diesem Fall erstellt WordPress die Dateien direkt über PHP, wodurch sie dem apacheBenutzer gehören (in diesem Beispiel). Andernfalls wird auf eine sicherere Methode zurückgegriffen, z. B. die Aufforderung zur Eingabe von SFTP-Anmeldeinformationen und das Erstellen der Dateien nach Ihren Wünschen.

FS_METHOD = 'direct'fordert WordPress auf, diese Risikoerkennung zu umgehen und Dateien immer mit dieser 'direct'Methode zu erstellen .

Warum dann benutzen FS_METHOD = 'direct'?

Leider ist die Logik von WordPress zum Erkennen einer gefährdeten Umgebung fehlerhaft und erzeugt sowohl falsch-positive als auch falsch-negative Ergebnisse. Hoppla. Der Test besteht darin, eine Datei zu erstellen und sicherzustellen, dass sie demselben Besitzer gehört wie das Verzeichnis, in dem sie sich befindet. Wenn die Benutzer identisch sind, wird PHP als Ihr eigenes Konto ausgeführt und Plugins können sicher als dieses Konto installiert werden. Wenn sie unterschiedlich sind, geht WordPress davon aus, dass PHP als gemeinsames Konto ausgeführt wird und es nicht sicher ist, Plugins als dieses Konto zu installieren. Leider sind beide Annahmen begründete Vermutungen, die häufig falsch sind.

Sie würden define('FS_METHOD', 'direct' );in einem falsch positiven Szenario wie diesem Folgendes verwenden: Sie sind Teil eines vertrauenswürdigen Teams, dessen Mitglieder alle Dateien über ihr eigenes Konto hochladen. PHP läuft als eigener Benutzer. WordPress geht davon aus, dass dies eine gefährdete Umgebung ist und nicht standardmäßig den 'direct'Modus verwendet. In Wirklichkeit wird es nur mit Benutzern geteilt, denen Sie vertrauen, und als solcher 'direct'Modus ist es sicher. In diesem Fall sollten Sie define('FS_METHOD', 'direct' );WordPress zwingen, Dateien direkt zu schreiben.

Es gibt eine "gut konfigurierte" Situation, in der "direkt" zu Problemen führen wird.

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 haben also die Dateien von user1 und der PHP-Code wird als php-user1 ausgeführt.

In dieser Situation können gehackte Plugins oder Kerncode (a) nicht in die Verzeichnisse anderer Benutzer schreiben (oder von diesen lesen, abhängig von den Berechtigungen). (b) kann die Dateien dieses Benutzers nicht schreiben und kann daher keinen Trojaner-Code zum Core- oder Plugin-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' einstellen und der PHP-Ausführungsbenutzer keine Schreibberechtigung hat, erhalten Sie Meldungen über fehlgeschlagene Aktualisierungen und es wird kein Popup-Fenster angezeigt, in dem Sie nach FTP-Anmeldeinformationen gefragt werden.