Jai récemment eu un problème où je nai pas pu installer le plugin WP Smush Pro car je nai pas linstallation manuelle ou linstallation en un clic options disponibles.

Je suis tombé sur ce message qui suggérait de modifier les paramètres dans wp-config.php. Jai ajouté les paramètres suggérés, mais celui qui semble être le plus important est:

define("FS_METHOD", "direct");

Ce que je voudrais savoir Quelles sont les véritables préoccupations que je devrais avoir en définissant FS_METHOD sur direct? Existe-t-il dautres alternatives à linstallation du plugin?

Voici ce que dit la documentation officielle:

FS_METHOD force la méthode du système de fichiers. Elle ne devrait être que « direct », « ssh2″,  » ftpext « ou » ftpsockets « . En règle générale, vous ne devez le modifier que si vous rencontrez des problèmes de mise à jour. Si vous le modifiez et que cela ne vous aide pas, modifiez déplacez-le. Dans la plupart des cas, le définir sur « ftpsockets » fonctionnera si la méthode choisie automatiquement ne fonctionne pas.

(Préférence principale) « direct » loblige à utiliser des requêtes dE / S directes sur fichier depuis PHP, cest plein de problèmes de sécurité sur les hôtes mal configurés, Ceci est choisi automatiquement le cas échéant.

Réponse

Voici comment jai compris lidée de l API de fichier WordPress . Si cest faux, merci de voter contre 🙂

Daccord. Si vous téléchargez un fichier, ce fichier a un propriétaire. Si vous téléchargez votre fichier avec FTP, vous vous connectez et le fichier appartiendra à lutilisateur FTP. Puisque vous avez les informations didentification, vous pouvez modifier ces fichiers via FTP. Le propriétaire peut généralement exécuter, supprimer, modifier, etc. le fichier. Bien sûr, vous pouvez changer cela en modifiant les autorisations de fichier .

Si vous téléchargez un fichier en utilisant PHP, lutilisateur Linux, qui est lexécution de PHP est propriétaire du fichier. Cet utilisateur peut maintenant éditer, supprimer, exécuter, etc. le fichier. Ce nest pas grave tant que vous seul êtes lutilisateur, qui exécute PHP sur votre système.

Supposons que vous êtes sur un hôte partagé « mal » configuré. Beaucoup de gens exploitent leurs sites Web PHP sur ce système. Disons quun seul utilisateur Linux exécute PHP pour toutes ces personnes. Lun des webmasters de cet hôte partagé a de mauvaises intentions. Il voit votre page et il trouve le chemin vers votre installation WordPress. Par exemple, WP_DEBUG est défini sur true et il y a un message derreur comme 

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

« Ha! » dit le mauvais garçon. Voyons voir si ce type a défini FS_METHOD sur direct et il écrit un script comme 

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

Etant donné quun seul utilisateur exécute PHP et que cet utilisateur est également utilisé par le bad boy, il peut modifier / supprimer / exécuter les fichiers sur votre système si vous les avez téléchargés via PHP et par ceci joint le PHP en tant que propriétaire.

Votre site a été piraté.

Ou, comme indiqué dans le Codex:

De nombreux systèmes dhébergement utilisent le serveur Web en tant quutilisateur différent de celui du propriétaire des fichiers WordPress. Dans ce cas, un processus décriture de fichiers à partir de lutilisateur du serveur Web aura les fichiers résultants appartenant au compte dutilisateur du serveur Web au lieu du compte de lutilisateur réel. Cela peut entraîner un problème de sécurité dans les situations dhébergement partagé, où plusieurs utilisateurs partagent le même serveur Web pour différents sites.

Réponse

Quel est le risque?

Sur un hôte partagé mal configuré, le PHP de chaque client s’exécutera comme le même utilisateur (disons apache pour discussion). Cette configuration est étonnamment courante.

Si vous « êtes sur un tel hôte et utilisez WordPress pour installer le plugin en utilisant laccès direct aux fichiers, tous vos fichiers de plugin appartiendront à apache. Un utilisateur légitime sur le même serveur pourrait vous attaquer en écrivant un script PHP qui injecte du code malveillant dans vos fichiers de plugin. Ils téléchargent leur script sur leur propre site Web et demandent son URL. Votre code a été compromis avec succès car leur script sexécute en tant que apache, le même qui possède vos fichiers de plug-in.

Que fait FS_METHOD "direct" à voir avec ça?

Lorsque WordPress a besoin dinstaller des fichiers (comme un plugin), il utilise get_filesystem_method () pour déterminer comment accéder au système de fichiers. Si vous ne définissez pas FS_METHOD, il choisira une valeur par défaut pour vous, sinon il utilisera votre sélection tant que cela a du sens.

Le comportement par défaut essaiera pour détecter si vous « êtes dans un environnement à risque comme le celui que jai décrit ci-dessus, et sil pense que vous êtes en sécurité, il utilisera la méthode "direct". Dans ce cas, WordPress créera les fichiers directement via PHP, les faisant appartenir à lutilisateur apache (dans cet exemple). Sinon, il « reviendra à une méthode plus sûre, telle que vous demander les informations didentification SFTP et créer les fichiers comme vous.

FS_METHOD = "direct" demande à WordPress de contourner cela à -détection des risques et toujours créer des fichiers en utilisant la méthode "direct".

Alors pourquoi utiliser FS_METHOD = "direct"?

Malheureusement, la « logique de WordPress pour détecter un environnement à risque est imparfaite et produit à la fois des faux positifs et des faux négatifs. Oups. Le test consiste à créer un fichier et à sassurer quil appartient au même propriétaire que le répertoire dans lequel il réside. Lhypothèse est que si les utilisateurs sont les mêmes, PHP fonctionne sous votre propre compte et il est prudent dinstaller des plugins comme cela Si elles « sont différentes, WordPress suppose que PHP fonctionne en tant que compte partagé et quil nest pas sûr dinstaller des plugins avec ce compte. Malheureusement, ces deux hypothèses sont des suppositions éclairées qui seront souvent fausses.

Vous utiliseriez define("FS_METHOD", "direct" ); dans un scénario de faux positifs comme celui-ci: vous faites partie dune équipe de confiance dont les membres téléchargent tous des fichiers via leur propre compte. PHP fonctionne comme son propre compte WordPress supposera quil sagit dun environnement à risque et ne passera pas par défaut en mode "direct". En réalité, il nest partagé quavec des utilisateurs de confiance et en tant que tel "direct" est sûr. Dans ce cas, vous devez utiliser define("FS_METHOD", "direct" ); pour forcer WordPress à écrire des fichiers directement.

Commentaires

Réponse

Il y a un » bien configuré  » situation où « direct » entraînera des problèmes.

Il est également possible de configurer lhébergement WP partagé avec des utilisateurs dexécution PHP non partagés, différents des utilisateurs propriétaires de fichiers / répertoires. Vous vous retrouvez donc avec les fichiers appartenant à user1 et le code PHP est exécuté en tant que php-user1.

Dans cette situation, les plugins piratés ou le code de base (a) ne peuvent pas écrire dans (ou même lire depuis , selon les permissions) les répertoires des autres utilisateurs; (b) ne peut « t écrire les fichiers de cet utilisateur » et ne peut donc « pas ajouter de code trojan au code du noyau ou du plugin.

Donc, si lhébergement est configuré comme ça , vous DEVEZ utiliser FTP pour les mises à jour et « direct » ne fonctionnera pas.

Si vous définissez « direct » dans wp-config.php et que lutilisateur dexécution PHP na pas lautorisation décriture, vous obtiendrez Update Échec des messages et aucune fenêtre contextuelle demandant les informations didentification FTP.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *