Quels problèmes de sécurité dois-je avoir lorsque FS_METHOD est défini sur "direct" dans wp-config?
J'ai récemment eu un problème qui m'a empêché d'installer le plug-in Smush Pro WP parce que les options Installation manuelle ou Installation en un clic ne sont pas disponibles.
Je suis tombé sur ce post qui m'a suggéré de peaufiner les paramètres dans wp-config.php. J'ai ajouté les paramètres suggérés, mais celui qui semble le plus important est:
define('FS_METHOD', 'direct');
Ce que j'aimerais savoir, c'est quelles préoccupations réelles devrais-je avoir à propos de la définition de FS_METHOD à direct? Existe-t-il d'autres alternatives à l'installation du plugin?
Voici ce que dit la documentation officielle:
FS_METHOD force la méthode du système de fichiers. Ce ne devrait être que "direct", "ssh2", "ftpext" ou "ftpsockets". En règle générale, vous ne devriez changer cela que si vous rencontrez des problèmes de mise à jour. Si vous le changez et que cela ne vous aide pas, changez-le/supprimez-le. Dans la plupart des cas, le réglage sur 'ftpsockets' fonctionnera si la méthode automatiquement choisie ne fonctionne pas.
(Préférence principale) "direct" l'oblige à utiliser les demandes d'E/S de fichier directes à partir de PHP. Cela entraîne de nombreux problèmes de sécurité sur des hôtes mal configurés. Cette option est automatiquement choisie, le cas échéant.
C’est bien ainsi que j’ai compris l’idée de la API de fichiers WordPress . Si c'est faux, s'il vous plait
D'accord. Si vous téléchargez un fichier, ce fichier a un propriétaire. Si vous téléchargez votre fichier via FTP, vous vous connectez et le fichier sera la propriété de l'utilisateur FTP. Puisque vous avez les informations d'identification, 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 changeant le autorisations sur les fichiers .
Si vous téléchargez un fichier à l'aide de PHP, l'utilisateur Linux qui exécute PHP est propriétaire du fichier. Cet utilisateur peut maintenant éditer, supprimer, exécuter, etc. le fichier. Ceci est acceptable tant que vous seul êtes l'utilisateur qui exécute PHP sur votre système.
Supposons que vous êtes sur un hôte partagé "mal" configuré. Beaucoup de gens utilisent leur PHP sites Web sur ce système. Disons qu'un seul utilisateur de Linux exécute PHP pour toutes ces personnes. L'un des webmasters de cet hôte partagé a de mauvaises intentions. Il voit votre page et il détermine le chemin de votre installation WordPress. Par exemple, WP_DEBUG est défini sur true et un message d'erreur tel que
[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1
"Ha!" le mauvais garçon dit. Voyons si ce mec a défini FS_METHOD sur direct et écrit un script du type
<?php
unlink( '/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php' );
?>
Comme un seul utilisateur exécute PHP et que cet utilisateur est également utilisé par le mauvais garçon, il peut modifier/supprimer/exécuter les fichiers de votre système si vous les avez téléchargés via PHP et par ceci attachait l'utilisateur PHP en tant que propriétaire.
Votre site est piraté.
Ou, comme il est dit dans le Codex:
Sur de nombreux systèmes d'hébergement, le serveur Web s'exécute en tant qu'utilisateur différent du propriétaire des fichiers WordPress. Lorsque c'est le cas, un processus écrivant des fichiers de l'utilisateur du serveur Web aura les fichiers résultants détenus par le compte d'utilisateur du serveur Web au lieu du compte de l'utilisateur réel. Cela peut entraîner un problème de sécurité dans les situations d'hébergement partagé, où plusieurs utilisateurs partagent le même serveur Web pour différents sites.
Quel est le risque?
Sur un hôte partagé mal configuré, tous les clients PHP seront exécutés avec le même utilisateur (disons Apache pour la discussion). Cette configuration est étonnamment commune.
Si vous êtes sur un tel hôte et utilisez WordPress pour installer le plug-in à l'aide d'un accès direct au fichier, tous vos fichiers de plug-in 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 plug-in. Ils téléchargent leur script sur leur propre site Web et demandent son URL. Votre code est compromis avec succès car leur script s'exécute en tant que Apache, le même qui possède vos fichiers de plug-in.
Qu'est-ce que FS_METHOD 'direct' a à voir avec cela?
Lorsque WordPress doit installer des fichiers (un plugin, par exemple), il utilise la fonction 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, sinon il utilisera votre sélection aussi longtemps que cela aura du sens.
Le comportement par défaut sera try pour détecter si vous vous trouvez dans un environnement à risque tel que celui décrit ci-dessus, et s'il 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 à l'utilisateur Apache (dans cet exemple). Sinon, une méthode plus sûre sera utilisée, telle que vous demander des informations d'identification SFTP et créer les fichiers en tant que vous.
FS_METHOD = 'direct' demande à WordPress de contourner cette détection de risque et always de créer des fichiers à l'aide de 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 à s’assurer qu’il appartient au même propriétaire que le répertoire dans lequel il se trouve. L’hypothèse est que si les utilisateurs sont identiques, PHP est exécuté en tant que votre propre compte et vous pouvez le sauvegarder en toute sécurité. installer des plugins en tant que compte. S'ils diffèrent, WordPress suppose que PHP est exécuté en tant que compte partagé et que l'installation de plug-ins avec ce compte n'est pas sûre. Malheureusement, ces deux hypothèses sont des suppositions éclairées qui seront souvent fausses.
Vous utiliseriez define('FS_METHOD', 'direct' ); dans un scénario faux positif tel que celui-ci: vous faites partie d'une équipe de confiance dont tous les membres téléchargent des fichiers via leur propre compte. PHP fonctionne comme son propre utilisateur séparé. WordPress supposera qu'il s'agit d'un environnement à risque et ne passera pas par défaut au mode 'direct'. En réalité, il est uniquement partagé avec des utilisateurs de confiance. Le mode 'direct' est donc sécurisé. Dans ce cas, vous devez utiliser define('FS_METHOD', 'direct' ); pour forcer WordPress à écrire des fichiers directement.
Il y a une situation "bien configurée" où "direct" peut engendrer des problèmes.
Il est également possible de configurer un hébergement partagé WP avec des utilisateurs d'exécution non partagés PHP, différents des utilisateurs propriétaires du fichier/répertoire. Donc, vous vous retrouvez avec les fichiers appartenant à l'utilisateur1 et le code PHP est exécuté en tant que php-user1.
Dans cette situation, les plugins piratés ou le code principal (a) ne peuvent pas écrire (ou même lire, en fonction des autorisations) dans les répertoires des autres utilisateurs; (b) ne peut pas écrire this fichiers de l'utilisateur et ne peut donc pas ajouter de code de cheval de Troie au code du noyau ou du plug-in.
Donc, si l'hébergement est configuré de cette façon, vous DEVEZ utiliser FTP pour les mises à jour et le mode "direct" ne fonctionnera pas.
Si vous définissez 'direct' dans wp-config.php et que l'utilisateur d'exécution PHP ne dispose pas de l'autorisation d'écriture, vous obtiendrez des messages Update Failed et aucune fenêtre contextuelle ne vous demandera des informations d'identification FTP.