it-swarm.com.de

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 Smush Pro-Plug-In WP nicht installieren konnte, da mir die Optionen für die manuelle Installation oder die One-Click-Installation nicht zur Verfügung stehen.

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

define('FS_METHOD', 'direct');

Was ich wissen möchte, ist, welche realen Bedenken ich haben sollte, 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. 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.

29
crmpicco

So habe ich die Idee der WordPress File 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 alle diese Personen 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, ob dieser Typ FS_METHOD auf direct gesetzt hat und 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 und per hochgeladen haben Dies fügte den Benutzer PHP als Eigentümer hinzu.

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.

26
websupporter

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 auf einem solchen Host arbeiten und das Plugin mit WordPress über den direkten Dateizugriff installieren, gehören alle Ihre Plugin-Dateien zu 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 als Apache ausgeführt wird, derselbe, der Ihre Plug-in-Dateien besitzt.

Was hat 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 FS_METHOD nicht definieren, wird eine Standardeinstellung für Sie ausgewählt, andernfalls wird Ihre Auswahl verwendet, sofern dies sinnvoll ist.

Mit dem Standardverhalten wird try ermittelt, ob Sie sich in einer gefährdeten Umgebung wie der oben beschriebenen befinden. Wenn Sie der Meinung sind, dass Sie sicher sind, wird die Methode 'direct' verwendet. In diesem Fall erstellt WordPress die Dateien direkt über PHP, wodurch sie dem Benutzer Apache gehören (in diesem Beispiel). Andernfalls wird auf eine sicherere Methode zurückgegriffen, beispielsweise 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 immer Dateien mit der 'direct'-Methode zu erstellen.

Warum dann FS_METHOD = 'direct' verwenden?

Leider ist die Logik von WordPress zum Erkennen einer gefährdeten Umgebung fehlerhaft und erzeugt sowohl falsch-positive als auch falsch-negative Ergebnisse. Hoppla. Bei dem Test wird eine Datei erstellt und sichergestellt, dass sie demselben Besitzer gehört wie das Verzeichnis, in dem sie sich befindet. Bei identischen Benutzern wird PHP als Ihr eigenes Konto ausgeführt und ist sicher für Installieren Sie Plugins als dieses Konto. 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 verwenden: Sie sind Teil eines vertrauenswürdigen Teams, dessen Mitglieder alle Dateien über ihr eigenes Konto hochladen. PHP wird als eigener Benutzer ausgeführt. WordPress geht davon aus, dass dies eine gefährdete Umgebung ist und verwendet nicht standardmäßig den 'direct' -Modus. In Wirklichkeit wird es nur mit Benutzern geteilt, denen Sie vertrauen, und als solche ist der 'direct'-Modus sicher. In diesem Fall sollten Sie define('FS_METHOD', 'direct' ); verwenden, um WordPress zum direkten Schreiben von Dateien zu zwingen.

12
Mark

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

Es ist auch möglich, freigegebenes WP Hosting mit nicht freigegebenen PHP Ausführungsbenutzern zu konfigurieren, die sich von den Benutzern mit Datei-/Verzeichnisbesitz unterscheiden. Sie haben also die Dateien von user1 und der Code PHP wird als php-user1 ausgeführt.

In dieser Situation können gehackte Plug-ins oder der Kerncode (a) nicht in die Verzeichnisse anderer Benutzer schreiben (oder von diesen lesen, abhängig von den Berechtigungen). (b) kann keine this Benutzerdateien 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' festlegen und der Benutzer, der die Ausführung von PHP ausführt, keine Schreibberechtigung hat, werden Meldungen über fehlgeschlagene Aktualisierungen angezeigt und es wird kein Popup-Fenster angezeigt, in dem Sie nach FTP-Anmeldeinformationen gefragt werden.

0
Danny