L'une des meilleures pratiques de sécurité les plus courantes de nos jours semble être de déplacer wp-config.php
un 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_basedir
pour 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.php
texte 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.
la source
Réponses:
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):
Cela semble inoffensif, non?
Eh bien, voici ce que j'ai fait pour déclencher ce bug:
site.staging.server.com
verssite-staging.ssl.server.com
).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:
wp-config.php
dans la racine Web, une demande/wp-config.php
aurait téléchargé le fichier de configuration WordPress.wp-config.php
dehors de la racine Web, demande de/wp-config.php
télécharger un fichier totalement inoffensif. Lewp-config.php
fichier réel n'a pas pu être téléchargé.Il est donc évident que le fait de
wp-config.php
sortir 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 serveurWordPress recherchera automatiquement un répertoire au-dessus de votre installation WordPress pour votre
wp-config.php
fichier. 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:(Assurez-vous de remplacer le chemin ci-dessus par le chemin réel de votre
wp-config.php
fichier déplacé .)Si vous rencontrez un problème avec
open_basedir
, ajoutez simplement le nouveau chemin d'accès à laopen_basedir
directive dans votre configuration PHP:C'est ça!
Choisir des arguments contraires
Chaque argument contre le fait de
wp-config.php
quitter la racine Web repose sur de fausses hypothèses.Argument 1: Si PHP est désactivé, ils sont déjà présents
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
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.php
est suffisantFALSE : 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.php
n'est pas graveFALSE : 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.php
sortir de la racine Web rend un serveur moins sécuriséFALSE : En supposant que
wp-config.php
soit présenthttpdocs/
, déplacez-le simplement../phpdocs/
et définissez-leopen_basedir
pour inclure uniquementhttpdocs/
etphpdocs/
. Par exemple:(N'oubliez pas de toujours inclure
/tmp/
, ou votretmp/
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.php
dehors de votre racine Web.la source
wp-config.php
sé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é votrewp-config.php
.wp-config.php
à un endroit arbitraire. J'ai ajouté des instructions à ma réponse. il s’agit simplement de créer un mannequinwp-config.php
dans le répertoire WordPress référençant l’emplacement du réel.Le plus important est qu’il
wp-config.php
contienne 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 de WP. Ainsi, le seul moyen de voir le contenu de ce fichier consiste à contourner l'interpréteur PHP de vos serveurs: le.php
fichier 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-config
sortir de la racine du document du point de vue de la sécurité - pour les raisons ci-dessus et celles-ci: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.wp-config.php
appartient 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.wp-config
, il a probablement joué avec autre chose.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-config
fait de sortir du document cède la place à la sécurité par l’obscurité - ce qui est vraiment un homme de paille.la source
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 :
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/user
répertoire).la source
public_html
, son déplacement enwp-config.php
dehors du répertoire signifie qu'il se trouvera dans lepublic_html
ré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 lepublic_html
répertoire, un niveau supérieur => vous allez le déplacer dans le/home/user
ré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).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,
la source
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.
la source
open_basedir
portée?-rwx
accès à des répertoires plus élevés que ceuxpublic_html
que je n'avais jamais connusopen_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.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
include
commande 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:
la source
open_basedir
directive prend un arbre entier , donc pour pouvoir accéder à/root/secure
partir de/root/html
, vous devez définiropen_basedir
sur/root
./root/httpdocs/config/accessible
, où se trouvent leshttpdocs
journaux, les sauvegardes, etc.config
détientwp-config.php
, etaccessible
détient WordPress et tout le contenu. Vous devrez modifier la configuration de vhost, etc. pour remapper la racine du documentaccessible
. Cependant, je ne vois aucun avantage à refuser simplement les demandes HTTP à wp-config dans la configuration par défaut.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:
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:
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_con
contient 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).la source
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.
la source
wp-config.php
un 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.