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.

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.

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.

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).

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,

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.

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

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).

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.