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

135

L'une des meilleures pratiques de sécurité les plus courantes de nos jours semble être de déplacer wp-config.phpun répertoire plus haut que la racine du document de vhost . Je n'ai jamais vraiment trouvé une 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.

Mais, vous devez toujours laisser WordPress y accéder, vous devez donc développer open_basedirpour inclure le répertoire 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 essaie-t-elle uniquement d'éviter une situation dans laquelle du wp-config.phptexte brut serait affiché à quiconque le demanderait 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 compenserait pas 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 de nombreux é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.

Ian Dunn
la source
Il n'est vraiment pas nécessaire d'inscrire votre choix de réponses et de rejeter toutes les autres réponses, à l'intérieur de votre question. Comme vous pouvez le voir ci-dessous, le système de vote stackexchange est conçu pour voter les réponses qui ont un sens pour les gens, alors que les personnes qui posent la question devraient utiliser le mécanisme de "réponse acceptée" et vos propres votes positifs / négatifs.
Kzqai
6
Je ne fais pas cela pour 99% des questions que j'ai posées, mais je pensais que c'était approprié dans ce cas particulier. Il y a 8 réponses à la question, dont certaines sont assez longues / complexes, et d'autres qui ont beaucoup de votes positifs en dépit du fait qu'elles contiennent des informations inexactes ou qu'elles n'ajoutent rien à la conversation. Je pense que proposer une conclusion à mi-autorité est utile pour les personnes qui lisent le fil pour la première fois. Comme toujours, les lecteurs sont libres de se faire leur propre opinion. Je ne fais que donner mon opinion en tant que PO.
Ian Dunn
1
@Kzqai: Le "système de vote stackexchange" est un processus démocratique, et les participants sont souvent 1) peu clairs sur ce que le PO demande ou essaie de résoudre, et 2) ne comprennent pas la validité d'une réponse donnée. Une fois que les réponses sont arrivées et que les votes ont été exprimés, il est plus qu'utile de demander au PO de clarifier les réponses qui ont fourni une assistance. Après tout, le PO est le seul à le savoir et je souhaiterais que davantage de PO le fassent. Oui, les gens "votent pour les réponses qui ont un sens pour les gens", mais laissons le PO avoir le dernier mot quant à ce qui a du sens pour lui.
Mac

Réponses:

127

Réponse courte: oui

La réponse à cette question est un oui sans équivoque , et dire le contraire est totalement 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 fait de passer wp-config.phpà l'extérieur 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 le rediriger vers une autre URL (par exemple, site.staging.server.comvers 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 aux 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.phpdans la racine Web, une demande /wp-config.phpaurait téléchargé le fichier de configuration WordPress.
  • En wp-config.phpdehors de la racine Web, demande de /wp-config.phptélécharger un fichier totalement inoffensif. Le wp-config.phpfichier réel n'a pas pu être téléchargé.

Il est donc évident que le fait de wp-config.phpsortir de la racine Web présente des avantages réels en matière de sécurité .


Comment passer wp-config.phpà n’importe quel emplacement sur votre serveur

WordPress recherchera automatiquement un répertoire au-dessus de votre installation WordPress pour votre wp-config.phpfichier. 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.phpdans 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');

(Assurez-vous de remplacer le chemin ci-dessus par le chemin réel de votre wp-config.phpfichier déplacé .)

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

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

C'est ça!


Choisir des arguments contraires

Chaque argument contre le fait de wp-config.phpquitter la racine Web repose sur de fausses hypothèses.

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

La seule façon de voir le contenu de [ wp-config.php] est de contourner l'interpréteur PHP de votre serveur ... Si cela se produit, vous avez déjà un problème: vous avez un accès direct à votre serveur.

FAUX : 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 de 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.

FAUX : 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.phpest suffisant

Vous pouvez restreindre l'accès au fichier via votre configuration d'hôte virtuel ou .htaccess- en limitant efficacement l'accès extérieur au fichier de la même manière que le fait de passer à l'extérieur 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, non .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 de routine, telle qu'une mise à jour de panneau, par exemple, 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.phpn'est pas grave

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

FALSE : Les clés d’authentification et les sels peuvent être utilisés dans un nombre illimité d’attaques de piratage.

WTF : Même si les informations d'identification de la base de données étaient la seule chose à posséder wp-config.php, vous devriez être terrifié par l'attaque d'un attaquant.

Argument 5: le fait de wp-config.phpsortir de la racine Web rend un serveur moins sécurisé

Vous devez toujours laisser l'accès WordPress [ wp-config.php], vous devez donc développer open_basedirpour inclure le répertoire au-dessus de la racine du document.

FALSE : En supposant que wp-config.phpsoit présent httpdocs/, déplacez-le simplement ../phpdocs/et définissez-le open_basedirpour 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 tmp/répertoire utilisateur , si vous en avez un.)


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

Si la sécurité vous tient à cœur, vous vous déplacerez en wp-config.phpdehors de votre racine Web.

Aaron Adams
la source
1
Si vous avez un bug dans apache, linux ou dans le cerveau de l'administrateur, vous portez un toast dans tous les cas. Dans votre scénario, vous ne parvenez pas à expliquer pourquoi il est plus probable qu'une mauvaise configuration se produise à la racine du site Web plutôt qu'à un autre endroit du serveur. Un apache mal configuré peut probablement accéder à /../config.php aussi facilement que /config.php
Mark Kaplun
1
Vous n'êtes pas "du pain grillé en tout cas." Il est très probable , et même démontrable , qu’un bogue entraînerait la réinitialisation de la racine Web à sa valeur par défaut. Dans ce cas, vous n'êtes pas "grillé" - votre wp-config.phpsécurité est préservée. Et il est extrêmement improbable - à tel point qu’il soit pratiquement impossible - qu’un bogue aboutirait à ce que la racine Web soit arbitrairement réinitialisée dans le répertoire exact dans lequel vous avez placé votre wp-config.php.
Aaron Adams
1
@IanDunn En fait, il est facile de passer wp-config.phpà un endroit arbitraire. J'ai ajouté des instructions à ma réponse. il s’agit simplement de créer un mannequin wp-config.phpdans le répertoire WordPress référençant l’emplacement du réel.
Aaron Adams
3
Cette réponse est parfaite. Ma société d'hébergement Web a eu une défaillance de la matrice de disques. Quand tout fut dit et fait, ils restaurèrent le système PARTIELLEMENT. Il s'avère qu'ils ont utilisé une série de scripts cPanel / WHM pour reconstruire les fichiers httpd.conf qui l'avaient fait de manière incorrecte. Heureusement, j'avais déjà wp-config.php en dehors de la racine du document, mais si je n'avais pas le contenu, il aurait été utile pour le prendre. Oui rare, mais comme noté, les cas rares sont ce qui doit vous inquiéter. De plus, affirmer que "les gens simples d'esprit seraient perdus" est une mauvaise excuse pour avoir une sécurité MOINS.
Lance Cleveland
1
C'est un bon point, Aaron. Je suis encore un peu sceptique pour les raisons que j'ai mentionnées dans ce fil de commentaire, mais vous m'avez convaincu que cela avait plus de mérite que je ne le pensais au départ. À tout le moins, si cela est fait correctement, je ne pense pas que cela nuira à rien. J'ai toujours un problème avec le fait que la plupart des gens qui en font la promotion ne semblent pas en comprendre les raisons, et la façon dont ils l'enseignent conduit souvent au répertoire situé au-dessus de httpdocs, mais vous avez aidé à résoudre ces problèmes dans Ta Réponse.
Ian Dunn
40

Le plus important est qu’il wp-config.phpcontienne 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.phpn'imprime jamais rien à l'écran. Il ne définit que les différentes constantes utilisées tout au long de votre installation de WP. Ainsi, le seul moyen de voir le contenu de ce fichier consiste à contourner l'interpréteur PHP de vos serveurs: le .phpfichier est 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 qu'il n'y a aucun avantage à wp-configsortir de la racine du document du point de vue de la sécurité - pour les raisons ci-dessus et celles-ci:

  1. Vous pouvez restreindre l'accès au fichier via votre hôte virtuel config ou .htaccess, ce qui permet de limiter l'accès externe au fichier de la même manière que le fait de passer à l'extérieur de la racine du document.
  2. Vous pouvez vous assurer que les autorisations de fichiers sont strictes wp-configafin 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 wp-config.phpappartient le fichier. 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 cette installation WP, 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 publiez une fois par semaine, une sauvegarde par semaine est probablement suffisante.
  5. Vous avez votre site sous contrôle de version ( comme celui-ci ), ce qui signifie que même si un attaquant y 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 la base de données sont vraiment les seuls éléments sensibles dans la base de données wp-config, et comme vous y êtes attentif (voir 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 wp-configfait de sortir du document cède la place à la sécurité par l’obscurité - ce qui est vraiment un homme de paille.

chrisguitarguy
la source
2
Oui, c'est à peu près ce à quoi je pensais. Je suis heureux de savoir que je ne suis pas le seul :) J'aimerais laisser la question ouverte pendant un jour ou deux au cas où quelqu'un aurait un contre-argument convaincant, mais jusqu'à présent, cela semble être la bonne réponse à moi.
Ian Dunn
3
Correction mineure: le fait de déplacer le fichier wp-config.php hors de la racine du document ne présente aucun avantage en termes de sécurité . Il existe d'autres avantages, qui ne sont pas liés à la sécurité, et qui s'appliquent uniquement aux configurations inhabituelles.
Otto
4
Juste pour faire disparaître un mythe possible - n'est-ce pas possible, quelque chose pourrait mal tourner côté serveur -, auquel cas le code php est imprimé à l'écran?
Stephen Harris
3
@IanDunn Mais les meilleures réponses recommandent de le sortir complètement de cette hiérarchie et de la transformer en une autre, ce qui répond à votre préoccupation concernant les journaux, etc. Cette réponse ne répond pas au titre de votre question "bouge ... vraiment bénéfique" d’autres mesures de sécurité sont bénéfiques et essaient de vous rassurer de ne pas vous soucier de la sécurité. Tout le monde pense que leur maison est en sécurité jusqu'à ce qu'ils soient cambriolés. Après cela, ils font un meilleur travail. Certaines personnes ne se font jamais cambrioler, même si leur sécurité est faible, mais cela ne veut pas dire que c'est un bon conseil que d'avoir une sécurité moins élevée.
AndrewC
4
Ce sont des points positifs, mais mon plus gros problème est qu’il s’agit d’arguments correctifs et non d’arguments préventifs. La plupart d'entre eux disent que ce n'est pas un problème, car A) vous supposez que quelqu'un a géré l'utilisateur de base de données correctement et B) vous avez des sauvegardes. Que se passe-t-il lorsque vous utilisez quelque chose comme woocommerce ou que vous stockez des informations sensibles dans votre base de données? Alors tu es foutu.
Goldentoa11
25

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 conseil :

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 à toute personne surfant dessus:

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

Notez que le paramétrage des permissions 400 ou 440 sur wp-config.php peut empêcher les plugins d’écrire ou de les 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 (l’autorisation par défaut pour les fichiers dans le /home/userrépertoire).

c'est moi
la source
5
Max est la réponse. +1 pour lui. J'essaie simplement de l'étendre.
its_me
1
Aahan Krish, vous avez frappé dans le mille. Merci pour l'ajout.
Max Yudin
Donc, si vous utilisez htaccess pour refuser les requêtes HTTP à wp-config.php, cela n’at-il pas le même résultat que de le déplacer en dehors de la racine du document, mais sans exposer les journaux / sauvegardes / etc?
Ian Dunn
4
@IanDunn Dépend de la racine du document: (1) Si wordpress est hébergé dans un répertoire public_html, son déplacement en wp-config.phpdehors du répertoire signifie qu'il se trouvera dans le public_htmlrépertoire. Dans ce cas, vous devrez utiliser les règles htaccess pour refuser les requêtes HTTP à wp-config.php. (2) Si WordPress est installé directement dans le public_htmlrépertoire, un niveau supérieur => vous allez le déplacer dans le /home/userrépertoire. Dans ce cas, vous êtes assez en sécurité car le fichier est en dehors de la racine du document. Vous pouvez toujours définir les autorisations du fichier sur 600 (ou même plus strictes sur 440 ou 400).
its_me
@IanDunn Comme je l'ai dit, c'est ma compréhension de base et je ne suis pas un expert en sécurité. :)
its_me
17

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,

Sucuri
la source
Hé les gars, merci d'avoir ajouté vos pensées. Je pense que nous avons déjà abordé la plupart de ces points dans les autres réponses et leurs commentaires. 1) Oui, c'est possible, mais rare. 2) Oui, cela a des avantages, mais ils sont minimes; 3) Oui, c'est possible, mais il est peu probable que ce type de vulnérabilité se reproduise, et se protéger est un peu comme jouer à la taupe ou obliger les gens à enlever leurs chaussures dans les aéroports, car un imbécile a caché une bombe chaussure une fois. C'est réactionnaire et peu susceptible d'avoir des avantages futurs.
Ian Dunn
Dans les différentes discussions, la question a été affinée à partir de "Y at-il des avantages?" "Ok, il y a quelques avantages, mais compensent-ils les risques?" Le principal risque auquel je fais référence est le fait que vous devez étendre la portée de openbase_dir afin de permettre à PHP d’accéder aux scripts en dehors de la racine Web. De nombreuses configurations d'hébergement - y compris celles qui utilisent Plesk, ce qui est beaucoup - stockent des journaux, des sauvegardes, des zones FTP privées censées être isolées de la racine Web, etc. dans le répertoire situé au-dessus de la racine Web. Donc, donner à PHP l’accès à ce répertoire peut être une grave vulnérabilité.
Ian Dunn
15

Définitivement oui.

Lorsque vous déplacez wp-config.php hors 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 de serveur mieux entretenu et plus fiable. Bien que cela puisse être plus cher.

Max Yudin
la source
4
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. À la lumière de ces choses, pensez - vous toujours que ça vaut le risque d'exposer les journaux / sauvegardes / etc en raison de l'expansion open_basedirportée?
Ian Dunn
1
Je n'ai jamais eu -rwxaccès à des répertoires plus élevés que ceux public_htmlque je n'avais jamais connus open_basedir. Mes journaux sont dans un répertoire séparé, donc les sauvegardes le sont. Je pense que c'est ce que tous les hôtes partagés ont.
Max Yudin
Les hôtes varient énormément; il n'y a pas de structure de répertoire standard. Plesk (l'un des panneaux de contrôle les plus populaires pour les hôtes partagés) place les journaux dans /var/www/vhosts/example.com/statistics/logs et la racine du document est /var/www/vhosts/example.com/httpdocs. Déplacer wp-config.php vers /var/www/vhosts/exemple.com/wp-config.php nécessiterait l’octroi aux scripts de l’accès à l’ensemble du répertoire exemple.com.
Ian Dunn
Juste par curiosité, où sont stockés vos journaux et vos sauvegardes, sinon dans le répertoire du domaine? Sont-ils accessibles via un panneau de contrôle ou quelque chose?
Ian Dunn
1
Oui, via un panneau de contrôle.
Max Yudin
8

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 dans le répertoire parent. Supposons que vous avez une structure telle que / root / html, où html contient l'installation de 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 non dans le répertoire racine du serveur. Bien sûr, vous devez vous assurer que php peut également fonctionner dans ce dossier sécurisé.

Comme 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 includecommande PHP à 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 cela 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.

De plus, 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
Michael
la source
Hey Michael, merci de partager ça. Avez-vous déjà essayé dans un environnement réel pour vérifier que cela fonctionne? Je pense que la open_basedirdirective prend un arbre entier , donc pour pouvoir accéder à /root/securepartir de /root/html, vous devez définir open_basedirsur /root.
Ian Dunn
Pour que votre idée fonctionne, je pense que vous auriez besoin de configurer la structure de répertoires comme suit /root/httpdocs/config/accessible, où se trouvent les httpdocsjournaux, les sauvegardes, etc. configdétient wp-config.php, et accessibledétient WordPress et tout le contenu. Vous devrez modifier la configuration de vhost, etc. pour remapper la racine du document accessible. Cependant, je ne vois aucun avantage à refuser simplement les demandes HTTP à wp-config dans la configuration par défaut.
Ian Dunn
1
Selon php.net/manual/en/ini.core.php#ini.open-basedir : "Sous Windows, séparez les répertoires par un point-virgule. Sur tous les autres systèmes, séparez les répertoires par un signe deux-points. En tant que module Apache, Les chemins open_basedir des répertoires parents sont désormais automatiquement hérités. " Vous pouvez donc définir plusieurs répertoires sans qu'il soit nécessaire de les placer dans un seul arbre.
Michael
Je viens de tester cela et on dirait que tu as raison. Je ne suis toujours pas sûr des avantages en termes de sécurité que de refuser simplement l'accès au fichier via Apache, cependant.
Ian Dunn
@IanDunn a bien répondu à la réponse d'Aaron Adams
AndrewC
4

Il existe de nombreux thèmes et plugins mal écrits 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.

Mise à jour

Je veux clarifier les problèmes define()et expliquer 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 pour 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’affectation à nullécrasera les données en mémoire. Un attaquant doit récupérer l'image mémoire juste au moment où il $db_concontient les données sensibles. Et c’est très peu de temps dans l’exemple ci-dessus (si la classe Database_Handler n’en sauvegarde pas de copie).

Ralf912
la source
Cette réponse ne répond pas directement à la question. Tout auteur de plug-in peut avoir une journée bien remplie avec WordPress s’il vous convaincre d’installer son code et d’avoir une intention malveillante. Ce n'est pas différent que d'installer volontairement un virus sur votre système. Cet argument pour ne pas déplacer wp-config.php est inutile. Cela revient à dire que l'installation volontaire d'une voiture piégée dans votre voiture rend l'alarme de la voiture inutile. Techniquement vrai mais WTF?!?
Lance Cleveland
2
Non, ce n'est pas inutile. La question est la suivante: puis-je protéger le compte de la base de données en masquant le fichier wp-config.php. Et la réponse est clairement: non. C'est la même chose que si vous demandiez "Puis-je protéger ma voiture contre les voitures piégées avec un avertisseur de voiture?" Il n'y a aucun autre avantage à cacher votre wp-config pour protéger l'accès à la base de données ou l'accès ftp. Les deux sont dans la portée globale. Je suis certain que les attaquants disposent de davantage de moyens pour accéder aux vars globaux sans injecter de code.
Ralf912
Je ne vois pas "Puis-je protéger le compte de la base de données en masquant le fichier wp-config.php" dans la question d'origine. La question initiale était "est-il logique de déplacer le wp-config.php". La réponse est absolument oui, OMI. C'est comme si vous deviez verrouiller votre porte lorsque vous sortez. Dire "quelqu'un peut facilement casser une fenêtre et y entrer de toute façon, alors pourquoi s'embêter" ne répond pas au point fondamental de la question. La question posée par l’OMI était la suivante: "Vaut-il la peine de déployer des efforts supplémentaires pour déplacer wp-config.php? TOUT avantage de le faire?". Oui. À tout le moins, il empêche les pirates informatiques paresseux.
Lance Cleveland
2
L'une des meilleures pratiques de sécurité les plus courantes ... Vous avez manqué un point très (très, très) important: À quoi un attaquant est-il intéressé? Et ce n'est pas comment vous appelez votre wp-config.php. Un attaquant s'intéresse aux valeurs que vous avez définies dans votre wp-config. Saisir votre exemple avec la porte d'entrée: Cacher votre wp-config est la même chose que si vous verrouillez votre porte d'entrée, mais stockez tout votre or non protégé dans le jardin. Toutes les valeurs définies dans wp-config sont définies globalement . Ils sont donc tous accessibles en dehors de wp-config. Même si vous cachez votre wp-config, les valeurs sont toujours présentes.
Ralf912
1
Je pense que ceux qui plaident en faveur du déplacement essaient de se protéger contre les scénarios dans lesquels wp-config.php pourrait être affiché en texte brut via une requête HTTP, plutôt que des scénarios où il pourrait être exposé à un autre code PHP s'exécutant sur l'hôte.
Ian Dunn
-1

Outre les avantages en matière de sécurité, il vous permet également de conserver votre instance WordPress sous contrôle de version tout en conservant les fichiers WordPress principaux en tant que sous-module / externe. Voici comment Mark Jaquith a configuré son projet WordPress-Skeleton. Voir https://github.com/markjaquith/WordPress-Skeleton#assumptions pour plus de détails.

Emzo
la source
8
Il l'a configuré dans la racine du document, pas à l'extérieur, ce n'est donc pas pertinent pour cette question. La technique à propos de laquelle la question posée spécifie que vous déplacez wp-config.phpun répertoire au - dessus de la racine du document de vhost , pas seulement un répertoire au-dessus du dossier d'installation de WordPress. Le but est de le sortir du dossier lisible par les requêtes HTTP.
Ian Dunn