web-dev-qa-db-fra.com

Le déplacement de wp-config hors de la racine Web est-il vraiment bénéfique?

Une des meilleures pratiques de sécurité les plus courantes de nos jours semble être déplaçant wp-config.php dans un répertoire plus élevé que la racine du document de vhost . Je n'ai jamais vraiment trouvé de bonne explication à cela, mais je suppose que c'est pour minimiser le risque qu'un script malveillant ou infecté sur la racine du site Web ne lise le mot de passe de la base de données.

Cependant, vous devez toujours laisser WordPress y accéder. Vous devez donc développer open_basedir pour inclure le répertoire situé au-dessus de la racine du document. Cela n’atteint-il pas tout l’objet et expose-t-il potentiellement les journaux du serveur, les sauvegardes, etc. aux attaquants?

Ou bien la technique tente-t-elle uniquement d'éviter une situation dans laquelle wp-config.php serait affiché en texte brut à toute personne demandant http://example.com/wp-config.php, au lieu d'être analysé par le moteur PHP? Cela semble être une occurrence très rare, et cela ne l'emporterait pas sur les inconvénients de l'exposition des journaux/sauvegardes/etc. aux requêtes HTTP.

Peut-être est-il possible de le déplacer en dehors de la racine du document dans certaines configurations d'hébergement sans exposer d'autres fichiers, mais pas dans d'autres configurations?

Conclusion: Après beaucoup d’échanges sur cette question, deux réponses sont apparues qui, à mon avis, devraient être considérées comme faisant autorité. Aaron Adams plaide en faveur du déplacement de wp-config, et chrisguitarguy fait de même. Ce sont les deux réponses que vous devriez lire si vous débutez dans le fil et que vous ne voulez pas tout lire. Les autres réponses sont redondantes ou inexactes.

securitycustomizationwp-config
131
Ian Dunn

Réponse courte: oui

La réponse à cette question est un sans équivoque oui , et dire le contraire est complètement irresponsable .

Réponse longue: un exemple concret

Permettez-moi de donner un exemple très réel, tiré de mon serveur très réel, où le déplacement de wp-config.php hors de la racine Web empêchait spécifiquement la capture de son contenu .

L'insecte:

Jetez un coup d’œil à cette description d’un bogue dans Plesk (corrigée dans 11.0.9 MU # 27):

Plesk réinitialise le transfert de sous-domaine après la synchronisation de l'abonnement avec le plan d'hébergement (117199)

Cela semble inoffensif, non?

Eh bien, voici ce que j'ai fait pour déclencher ce bug:

  1. Configurez un sous-domaine pour qu'il redirige vers une autre URL (par exemple, site.staging.server.com à site-staging.ssl.server.com).
  2. Modification du plan de service de l'abonnement (par exemple, sa configuration PHP).

Lorsque j’ai fait cela, Plesk a réinitialisé le sous-domaine sur les valeurs par défaut: servir le contenu de ~/httpdocs/, sans interprète (par exemple, PHP) actif.

Et je n'ai pas remarqué. Pendant des semaines.

Le résultat:

  • Avec wp-config.php dans la racine Web, une demande à /wp-config.php aurait téléchargé le fichier de configuration WordPress.
  • Avec wp-config.php en dehors de la racine Web, une demande de /wp-config.php a téléchargé un fichier totalement inoffensif. Le vrai fichier wp-config.php n'a pas pu être téléchargé.

Il est donc évident que le fait de déplacer wp-config.php en dehors de la racine Web procure de véritables avantages en matière de sécurité dans le monde réel .

Comment déplacer wp-config.php vers n’importe quel emplacement de votre serveur

WordPress recherchera automatiquement un répertoire au-dessus de votre installation WordPress pour votre fichier wp-config.php. Si c'est là que vous l'avez déplacé, vous avez terminé!

Mais que faire si vous l'avez déplacé ailleurs? Facile. Créez un nouveau wp-config.php dans le répertoire WordPress avec le code suivant:

<?php

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Location of your WordPress configuration. */
require_once(ABSPATH . '../phpdocs/wp-config.php');

(Veillez à remplacer le chemin ci-dessus par le chemin réel de votre fichier wp-config.php déplacé.)

Si vous rencontrez un problème avec open_basedir, ajoutez simplement le nouveau chemin d'accès à la directive open_basedir dans votre configuration PHP:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

C'est tout!

Choisir des arguments contraires

Tout argument contre le déplacement de wp-config.php hors de la racine Web repose sur de fausses hypothèses.

Argument 1: Si PHP est désactivé, ils sont déjà présents.

Le seul moyen de voir le contenu de [wp-config.php] est de contourner votre interprète de serveurs PHP… Si cela se produit, vous avez déjà un problème: ils ont un accès direct à votre serveur.

FALSE: Le scénario que je décris ci-dessus est le résultat d'une mauvaise configuration, pas d'une intrusion.

Argument 2: La désactivation accidentelle PHP est rare et donc insignifiante.

Si un attaquant a suffisamment d'accès pour modifier le gestionnaire PHP, vous êtes déjà voué à l'échec. D'après mon expérience, les modifications accidentelles sont très rares et dans ce cas, il serait facile de changer le mot de passe.

FALSE: Le scénario que je décris ci-dessus est le résultat d'un bogue dans un logiciel serveur commun affectant une configuration de serveur commune. C’est loin d’être "rare" (et d’ailleurs, sécurité, c’est se soucier de ce scénario rare).

WTF: Changer le mot de passe après une intrusion n'aide guère si des informations sensibles ont été collectées pendant l'intrusion. Vraiment, pensons-nous toujours que WordPress n'est utilisé que pour les blogs occasionnels, et que les attaquants ne s'intéressent qu'à la défiguration? Nous allons nous préoccuper de la protection de notre serveur, pas seulement de la restauration après que quelqu'un se soit introduit.

Argument 3: Refuser l'accès à wp-config.php est suffisant

Vous pouvez limiter l'accès au fichier via votre configuration d'hôte virtuel ou .htaccess - ce qui limite efficacement l'accès externe au fichier de la même manière que le fait de le faire en dehors de la racine du document.

FALSE: Imaginez que les valeurs par défaut de votre serveur pour un hôte virtuel soient: pas de PHP, pas de .htaccess, allow from all (ce qui n’est guère inhabituel dans un environnement de production). Si votre configuration est en quelque sorte réinitialisée au cours d'une opération courante - par exemple, une mise à jour de panneau _ - tout reviendra à son état par défaut et vous serez exposé.

Si votre modèle de sécurité échoue lorsque les paramètres sont réinitialisés par défaut, vous avez besoin de davantage de sécurité.

WTF: Pourquoi quelqu'un recommanderait-il spécifiquement moins de couches de sécurité? Les voitures chères n'ont pas seulement des serrures; ils ont également des alarmes, des immobilisateurs et des suiveurs GPS. Si quelque chose mérite d'être protégé, faites-le correctement.

Argument 4: l'accès non autorisé à wp-config.php n'est pas grave

Les informations de base de données sont vraiment le seul élément sensible dans [wp-config.php].

FALSE: Les clés d'authentification et les sels peuvent être utilisés dans n'importe quel nombre d'attaques de piratage potentielles.

WTF: Même si les informations d'identification de la base de données étaient la seule chose dans wp-config.php, vous devriez être terrifié d'un attaquant mettant la main dessus.

Argument 5: Déplacer wp-config.php hors de la racine Web rend un serveur moins sécurisé

Vous devez toujours laisser WordPress accéder à [wp-config.php]. Vous devez donc développer open_basedir pour inclure le répertoire situé au-dessus de la racine du document.

FALSE: En supposant que wp-config.php est dans httpdocs/, déplacez-le simplement vers ../phpdocs/ et configurez open_basedir pour inclure uniquement httpdocs/ et phpdocs/. Par exemple:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

(N'oubliez pas de toujours inclure /tmp/, ou votre répertoire utilisateur tmp/, si vous en avez un.)

Conclusion: les fichiers de configuration doivent toujours toujours toujours être situés en dehors de la racine Web.

Si vous vous souciez de la sécurité, vous déplacerez wp-config.php en dehors de votre racine Web.

122
Aaron Adams

Le plus important est que le wp-config.php contient des informations sensibles: votre nom d'utilisateur/mot de passe de base de données, etc.

Donc, l’idée: déplacez-le en dehors de la racine du document et vous n’aurez plus à vous soucier de rien. Un attaquant ne pourra jamais accéder à ce fichier à partir d'une source externe.

Voici toutefois le problème: wp-config.php n'imprime jamais rien à l'écran. Il ne définit que les différentes constantes utilisées tout au long de votre installation WP. Ainsi, le seul moyen de voir le contenu de ce fichier consiste à contourner les interprètes de votre serveur PHP: le fichier .php sera restitué sous forme de texte brut. Si cela se produit, vous avez déjà un problème: ils ont un accès direct à votre serveur (et probablement des droits d'accès root) et peuvent faire ce qu'ils veulent.

Je vais aller de l'avant et dire il n'y a aucun avantage à déplacer wp-config en dehors de la racine du document du point de vue de la sécurité - pour les raisons susmentionnées et pour les raisons suivantes:

  1. Vous pouvez restreindre l'accès au fichier via votre configuration d'hôte virtuel ou .htaccess, ce qui permet de limiter l'accès externe au fichier de la même manière que le fait de se déplacer en dehors de la racine du document.
  2. Vous pouvez vous assurer que les autorisations de fichier sont strictes sur wp-config afin d'empêcher tout utilisateur sans privilèges suffisants de lire le fichier, même s'il obtient un accès (limité) à votre serveur via SSH.
  3. Vos informations sensibles, les paramètres de base de données, ne sont utilisés que sur un seul site. Ainsi, même si un attaquant obtenait l'accès à ces informations, le seul site qui en résulterait serait l'installation de WordPress à laquelle appartient le fichier wp-config.php. Plus important encore, cet utilisateur de base de données ne dispose que des autorisations de lecture et d'écriture sur la base de données de ce WP install et rien d'autre - pas d'accès pour accorder des autorisations à d'autres utilisateurs. Autrement dit, si un attaquant parvient à accéder à votre base de données, il vous suffit de restaurer à partir d'une sauvegarde (voir le point 4) et de modifier l'utilisateur de la base de données.
  4. Vous sauvegardez souvent. Il s’agit souvent d’un terme relatif: si vous publiez 20 articles tous les jours, vous feriez mieux de les sauvegarder tous les jours ou tous les deux jours. Si vous postez une fois par semaine, une sauvegarde par semaine est probablement suffisante.
  5. Votre site est sous contrôle de version ( comme ceci ), ce qui signifie que même si un attaquant avait accès, vous pouvez facilement détecter les modifications de code et les restaurer. Si un attaquant a accès à wp-config, il a probablement joué avec autre chose.
  6. Les informations de base de données sont vraiment les seuls éléments sensibles dans wp-config, et comme vous y êtes attentif (voir les points 3 et 4), ce n'est pas une grosse affaire. Les sels et autres peuvent être changés à tout moment. La seule chose qui se produit est que cela invalide les cookies des utilisateurs connectés.

Pour moi, le déplacement de wp-config hors de la racine du document est empreint de sécurité par obscurité - ce qui en fait un homme de paille.

40
chrisguitarguy

Je pense que Max est une réponse bien informée, et c'est un aspect de l'histoire. Le WordPress Codex a plus de conseils :

Assurez-vous également que vous seul (et le serveur Web) pouvez lire ce fichier (cela signifie généralement une autorisation 400 ou 440).

Si vous utilisez un serveur avec .htaccess, vous pouvez le mettre dans ce fichier (tout en haut) pour interdire l’accès à quiconque le recherchant:

<files wp-config.php>
order allow,deny
deny from all
</files>

Notez que le paramétrage de l'autorisation 400 ou 440 sur wp-config.php peut empêcher les plugins d'écrire ou de le modifier. Un cas réel, par exemple, serait la mise en cache de plugins (W3 Total Cache, WP Super Cache, etc.). Dans ce cas, je choisirais 600 (autorisation par défaut pour les fichiers du répertoire /home/user).

25
its_me

Quelqu'un nous a demandé de briller, et je vais répondre ici.

Oui, l'isolement de votre fichier wp-config.php du répertoire racine de votre site présente des avantages en termes de sécurité.

1- Si votre gestionnaire PHP est cassé ou modifié d'une manière ou d'une autre, vos informations de base de données ne seront pas exposées. Et oui, j'ai vu cela se produire plusieurs fois sur des hôtes partagés lors des mises à jour de serveur. Oui, le site sera cassé pendant cette période, mais vos mots de passe seront intacts.

2- Les meilleures pratiques recommandent toujours d'isoler les fichiers de configuration des fichiers de données. Oui, c'est difficile à faire avec WordPress (ou n'importe quelle application Web), mais le déplacer vers le haut crée un peu d'isolement.

3- N'oubliez pas la vulnérabilité PHP-CGI, où tout le monde peut passer le? -S dans un fichier et voir la source. http://www.kb.cert.org/vuls/id/520827

À la fin, ce sont de petits détails, mais ils aident à minimiser les risques. Particulièrement si vous êtes dans un environnement partagé, où tout le monde peut accéder à votre base de données (tout ce dont ils ont besoin est un utilisateur/un mot de passe).

Mais ne laissez pas de petites distractions (optimisations prématurées) se faire jour pour vraiment sécuriser un site:

1- Gardez-le toujours à jour

2- Utilisez des mots de passe forts

3- Restreindre l'accès (via les autorisations). Nous avons un post à ce sujet ici:

http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html

merci,

17
Sucuri

Définitivement oui.

Lorsque vous déplacez wp-config.php en dehors du répertoire public, vous l'empêchez de lire à l'aide du navigateur lorsque le gestionnaire php est modifié de manière malveillante (ou accidentelle!).

La lecture de votre identifiant/mot de passe de base de données est possible lorsque le serveur est à peine infecté par une faute d'administrateur boiteux. Imposez une amende à l’administrateur et obtenez un hôte serveur mieux entretenu et plus fiable. Bien que cela puisse être plus cher.

15
Max Yudin

Je tiens simplement à préciser, à des fins de discussion, que le déplacement de votre fichier wp_config.php ne signifie pas nécessairement que vous devez le déplacer uniquement vers le répertoire parent. Supposons que vous ayez une structure telle que/root/html, où html contient l'installation WP et tout votre contenu HTML. Au lieu de déplacer wp_config.php vers/root, vous pouvez le déplacer vers quelque chose comme/root/secure ..., qui se trouve à la fois hors du répertoire html et également dans le répertoire racine du serveur. Bien sûr, vous devez vous assurer que php peut également fonctionner dans ce dossier sécurisé.

Étant donné que WP ne peut pas être configuré pour rechercher wp_config.php dans un dossier frère tel que/root/secure, vous devez effectuer une étape supplémentaire. J'ai laissé le fichier wp_config.php dans/root/html et ai découpé les parties sensibles (connexion à la base de données, sel, préfixe de table) et les ai déplacées dans un fichier séparé appelé config.php. Ensuite, vous ajoutez la commande PHP include à votre wp_config.php, comme ceci: include('/home/content/path/to/root/secure/config.php');

C'est essentiellement ce que j'ai fait dans ma configuration. Maintenant, sur la base de la discussion ci-dessus, je suis encore en train d’évaluer si c'est nécessaire ou même une bonne idée. Mais je voulais juste ajouter que la configuration ci-dessus est possible. Il n'expose pas vos sauvegardes ni les autres fichiers racine. Tant que le dossier sécurisé n'est pas configuré avec sa propre URL publique, il ne peut pas être parcouru.

En outre, vous pouvez limiter l'accès au dossier sécurisé en créant un fichier .htaccess avec:

order deny,allow
deny from all
allow from 127.0.0.1
8
Michael

Il y a beaucoup de mauvais thèmes écrits et de plugins qui permettent aux utilisateurs d’injecter du code (rappelez-vous le problème de sécurité avec Timthumb). Si je suis un attaquant, pourquoi devrais-je rechercher le fichier wp-config.php? Il suffit d'injecter ce code:

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

Vous pouvez essayer de cacher votre wp-config.php. Tant que WordPress rend toutes les informations sensibles accessibles de manière globale, il ne sert à rien de cacher le fichier wp-config.php.

La mauvaise partie de wp-config.php n’est pas qu’elle contient des données sensibles. La mauvaise partie est de définir les données sensibles comme une constante accessible globale.

Mettre à jour

Je veux clarifier les problèmes avec define() et pourquoi c'est une mauvaise idée de définir les données sensibles comme une constante globale.

Il y a beaucoup de façons d'attaquer un site web. L'injection de script n'est qu'un moyen d'attaquer un site Web.

En supposant que le serveur comporte une vulnérabilité qui permet à un attaquant d'accéder à un vidage de la mémoire. L’attaquant trouvera dans le vidage de la mémoire toutes les valeurs de toutes les variables. Si vous définissez une constante accessible globale, elle doit rester en mémoire jusqu'à la fin du script. En créant une variable au lieu d'une constante, il y a de fortes chances que le garbage collector écrase (ou libère) la mémoire une fois que la variable n'est plus utilisée.

Un meilleur moyen de protéger les données sensibles est de les supprimer immédiatement après les avoir utilisées:

$db_con = new stdClass();
$db_con->db_user = 'username';
$db_con->password = 'password';
$db_con->Host = 'localhost';

$db_handler = new Database_Handler( $db_con );

$db_con = null;

Après avoir utilisé les données sensibles, l'attribution à null écrasera les données en mémoire. Un attaquant doit récupérer l'image mémoire juste au moment où $db_con contient les données sensibles. Et cela est très peu de temps dans l'exemple ci-dessus (si la classe Database_Handler n'en sauvegarde pas de copie).

4
Ralf912