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 WP Smush Pro, car les options d'installation manuelle ou d'installation en un clic ne sont pas disponibles.

Je suis tombé sur ce message qui suggérait de peaufiner les paramètres 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 je voudrais savoir est ce que les préoccupations réelles aurais - je mettre autour FS_METHODde 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 l’ API WordPress File . 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 modifiant les autorisations de fichier .

Si vous téléchargez un fichier en utilisant 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 leurs sites Web PHP sur ce système. Disons qu'un seul utilisateur 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. Permet de voir, si ce mec est réglé FS_METHODsur directet il écrit un script comme

<?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 sur votre système si vous les avez téléchargés via PHP et que l'utilisateur PHP est connecté 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. Dans ce cas, un processus écrivant des fichiers à partir de l'utilisateur du serveur Web aura les fichiers résultants détenus par le compte d'utilisateur du serveur Web à la place 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é, chaque client PHP s'exécutera comme le même utilisateur (disons apachepour la discussion). Cette configuration est étonnamment commune.

Si vous êtes sur un tel hôte et utilisez WordPress pour installer le plug-in en utilisant l'accès direct aux fichiers, 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 sous apachele même nom que celui de vos fichiers de plug-in.

Qu'est-ce que cela FS_METHOD 'direct'a à voir avec ça?

Lorsque WordPress doit installer des fichiers (un plugin, par exemple), il utilise la fonction get_filesystem_method () pour déterminer le mode d'accès au système de fichiers. Si vous ne le définissez pas, FS_METHODil choisira une valeur par défaut, sinon il utilisera votre sélection aussi longtemps que cela aura du sens.

Le comportement par défaut essaiera de détecter si vous vous trouvez dans un environnement à risque tel que celui décrit ci-dessus, et s'il pense être en sécurité, il utilisera la 'direct'méthode. Dans ce cas, WordPress créera les fichiers directement via PHP, les faisant appartenir à l' apacheutilisateur (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 de toujours créer des fichiers à l'aide de la 'direct'méthode.

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 réside. L’hypothèse est que si les utilisateurs sont identiques, PHP est exécuté en tant que votre propre compte et il est prudent d’installer les plugins en tant que ce compte. S'ils diffèrent, WordPress suppose que PHP est exécuté en tant que compte partagé et il n'est pas prudent d'installer des plugins en tant que ce compte. Malheureusement, ces deux hypothèses sont des suppositions éclairées qui seront souvent fausses.

Vous utiliseriez define('FS_METHOD', 'direct' );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 en 'direct'mode. En réalité, il est uniquement partagé avec des utilisateurs de confiance 'direct'. Ce mode est donc sécurisé. Dans ce cas, vous devez define('FS_METHOD', 'direct' );forcer WordPress à écrire directement des fichiers.

Il y a une situation «bien configurée» où «direct» peut engendrer des problèmes.

Il est également possible de configurer un hébergement WP partagé avec des utilisateurs d'exécution PHP non partagés, différents des utilisateurs propriétaires de fichiers / répertoires. Donc, vous vous retrouvez 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 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 les fichiers de cet 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.