Welche Sicherheitsbedenken sollte ich haben, wenn ich FS_METHOD in “wp-config” auf “Direkt” setze?

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

Ich stieß auf diesen Beitrag, der vorschlug, die Einstellungen in wp-config.php . Ich habe die vorgeschlagenen Einstellungen hinzugefügt, aber die, die am wichtigsten zu sein scheint, ist:

define('FS_METHOD', 'direct');

Was ich gerne wissen würde, ist, welche wirklichen Sorgen ich haben sollte, um FS_METHOD zu direct ? Gibt es noch andere Alternativen zur Installation des Plugins?

Dies ist, was die offizielle Dokumentation zu sagen hat:

FS_METHOD erzwingt die Dateisystemmethode. Es sollte nur “direkt”, “ssh2”, “ftpext” oder “ftpsockets” sein. Im Allgemeinen sollten Sie dies nur ändern, wenn Sie ein Update-Problem haben. Wenn Sie es ändern und es nicht hilft, ändern Sie es zurück / entfernen Sie es. In den meisten Fällen funktioniert die Einstellung auf “ftpsockets”, wenn die automatisch gewählte Methode nicht funktioniert.

(Primärpräferenz) “direkt” zwingt es, direkte Datei-E / A-Anfragen aus PHP zu verwenden, dies ist mit dem Öffnen von Sicherheitsproblemen auf schlecht konfigurierten Hosts behaftet. Diese werden bei Bedarf automatisch ausgewählt.

Solutions Collecting From Web of "Welche Sicherheitsbedenken sollte ich haben, wenn ich FS_METHOD in “wp-config” auf “Direkt” setze?"

Dies ist nur, wie ich die Idee der WordPress File API verstanden habe . Wenn es falsch ist, bitte downvote 🙂

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 Besitzer 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 Shared Host. Viele Leute betreiben ihre PHP-Websites auf diesem System. Nehmen wir an, dass nur ein Linux-Benutzer PHP für all diese Leute ausführt. Einer der Webmaster auf diesem Shared Host hat schlechte Absichten. Er sieht Ihre Seite und er findet den Weg zu Ihrer WordPress-Installation. 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 gesetzt FS_METHOD und 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 von dem bösen Buben benutzt 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 wurde gehackt.

Oder wie es im Codex heißt:

Bei vielen Hosting-Systemen läuft der Webserver als anderer Benutzer als der Eigentümer der WordPress-Dateien. Wenn dies der Fall ist, wird ein process, der Dateien vom Webserverbenutzer schreibt, die resultierenden Dateien im Besitz des Benutzerkontos des Webservers anstelle des Benutzerkontos des Benutzers haben. Dies kann zu einem Sicherheitsproblem in Shared-Hosting-Situationen führen, in denen mehrere Benutzer denselben Webserver für verschiedene Sites verwenden.

Was ist das Risiko?

Auf einem schlecht konfigurierten Shared Host wird das PHP jedes Kunden als derselbe Benutzer ausgeführt (sagen wir apache zur Diskussion). Diese Einrichtung ist überraschend üblich.

Wenn Sie sich auf einem solchen Host befinden und WordPress verwenden, um das Plugin mit direktem Dateizugriff zu 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ösartigen Code in Ihre Plugin-Dateien injiziert. Sie laden ihr Skript auf ihre eigene Website hoch und fordern ihre URL an. Ihr Code wurde erfolgreich kompromittiert, da sein Skript als apache , derselbe, dem Ihre Plug-in-Dateien gehören.

Was hat FS_METHOD 'direct' damit zu tun?

Wenn WordPress Dateien installieren muss (z. B. ein Plugin), verwendet es die function get_filesystem_method () , um zu bestimmen, wie auf das Dateisystem zugegriffen werden soll . Wenn Sie FS_METHOD nicht definieren, FS_METHOD es einen Standard für Sie auswählen, andernfalls wird Ihre Auswahl so lange verwendet, wie es 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 es die 'direct' Methode verwenden. In diesem Fall erstellt WordPress die Dateien direkt über PHP, wodurch sie zum apache Benutzer gehören (in diesem Beispiel). Andernfalls wird auf eine sicherere Methode zurückgegriffen, z. B. um SFTP-Anmeldeinformationen anzufordern und die Dateien wie Sie zu erstellen.

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

Warum dann FS_METHOD = 'direct' ?

Leider ist die Logik von WordPress zur Erkennung einer Risikoumgebung errorshaft und erzeugt sowohl falsch-positive als auch falsch-negative Ergebnisse. Hoppla. Der Test beinhaltet das Erstellen einer Datei und das Sicherstellen, dass sie zu demselben Besitzer wie das Verzeichnis gehört, in dem sie sich befindet. Wenn die Benutzer identisch sind, läuft PHP als Ihr eigenes Konto und es ist sicher, Plugins als dieses Konto zu installieren. Wenn sie anders sind, nimmt WordPress an, dass PHP als ein gemeinsames Konto läuft und es nicht sicher ist, Plugins als dieses Konto zu installieren. Leider sind beide Annahmen Annahmen, die oft falsch sind.

Sie würden define( FS_METHOD = 'direct' ); In einem falschen positiven Szenario wie diesem: Sie sind Teil eines vertrauenswürdigen Teams, dessen Mitglieder alle Dateien über ihr eigenes Konto hochladen. PHP läuft als eigener separater Benutzer. WordPress wird davon ausgehen, dass dies eine gefährdete Umgebung ist und wird nicht auf den 'direct' Modus wechseln. In Wirklichkeit wird es nur mit Benutzern geteilt, denen Sie vertrauen, und so ist 'direct' Modus sicher. In diesem Fall sollten Sie define( FS_METHOD = 'direct' ); um WordPress zu zwingen, Dateien direkt zu schreiben.

Es gibt eine “gut konfigurierte” Situation, in der “direkt” zu Problemen führt.

Es ist auch möglich, Shared-WP-Hosting mit nicht gemeinsam genutzten PHP-Ausführungsbenutzern zu konfigurieren, die sich von den Benutzern der Datei- / Verzeichniseigentümer 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 Core-Code (a) nicht in die Rechte anderer Benutzer schreiben (oder sogar von ihnen lesen, abhängig von den Berechtigungen); (b) kann die Dateien dieses Benutzers nicht schreiben und kann daher keinen trojanischen Code zum core- oder Plugin-Code hinzufügen.

Wenn das Hosting so eingerichtet ist, MÜSSEN Sie FTP für Updates verwenden und “direkt” funktioniert nicht.

Wenn Sie ‘direkt’ in wp-config.php setzen und der PHP-Ausführungsbenutzer keine Schreibberechtigung hat, erhalten Sie Update-Failed-Nachrichten und haben kein Pop-Up, das nach FTP-Zugangsdaten fragt.

Ich habe die Dateisystemangelegenheiten gründlich überprüft. Die meisten Leute, ich schätze das ‘suexec’ Paradigma: ein ftpuser , ein webuser (alias Apache , wwwuser , http oder ähnliches). Beide sind typischerweise in derselben Gruppe.

Wenn der Webuser den Download direkt austriggers und dann die Dateien ablegt (also wird er der Besitzer), denke ich, dass damit nichts falsch ist.

Wenn Sie immer noch Dateien (dh Updates) von Ihrem ftpuser (lesen Sie: von Ihrem FTP-Client) ändern wollen, stellen Sie sicher, dass Sie in Ihrer wp-config gute Standard-Dateirechte (das Gegenteil von umask ) haben:

 define('FS_CHMOD_DIR', 0770); define('FS_CHMOD_FILE', 0660); 

Halten Sie die Welt (andere Leute auf Ihrem Shared Hosting, mögliche Eindringlinge) so weit wie möglich frei, aber erlauben Sie “den anderen” Ihres zwei Accounts, um die Datei auch zu bearbeiten. (Eine viel bessere Strategie als fortgesetzt war die Zeit auf Chown und Chmod, aus meiner Erfahrung)

Kurz gesagt: Ich sehe keine Sicherheitslücke in der direkten Methode.

In der Tat ist es eine gute Lösung, wenn die Methode ‘ftpext’ fehlschlägt, wahrscheinlich wegen fehlender FTP-Konfiguration von Ihrem Hosting-Provider. (Verräterisches Zeichen, das viele Leute zu haben scheinen: ‘PHP Warnung: array_keys () erwartet, dass Parameter 1 array ist, boolean gegeben’))