🛡Point SECU #6 : 3 Mythes sur le fichier wp-config.php

Salut à tous et bienvenue dans ce nouveau Point Sécu avec Julio.

Julio : Hello!

Alex : Aujourd’hui on va parler de trois mythes, de trois choses qu’on peut croire qu’il est important de faire, mais en fait… ce n’est pas bon !

Allez c’est parti !

Alors du coup voilà, comme je vous le disais, on va voir trois mythes liés à la sécurité WordPress et donc Julio, est-ce que tu peux nous en dire un petit peu plus ?

Julio : Oui ! Ces trois mythes que l’on retrouve dans beaucoup de tutoriels, aussi sur le codex, touchent tous les trois le fichier de configuration : le wp-config.php.

Ce n’est pas forcément mauvais, mais je dirais que c’est une sorte de fausse sécurité. C’est-à-dire que grâce à ça on va penser avoir sécurisé quelque chose, mais en fait non, ça n’aura potentiellement servi à rien.

Avoir la sensation d’être sécurisé c’est relativement dangereux, c’est comme si… je ne sais pas moi… vous mettiez un casque en mousse pour faire du vélo, ben non ça sert à rien, mais vous avez mis un casque…

Alex : Ou alors juste un sac à dos, au lieu d’avoir son sac avec un parachute dedans…..

Julio : Exactement, très bonne idée ! C’est un peu ce genre de chose ! Comme justement c’est assez technique, quand on n’a pas assez de connaissances, on se dit que l’on fait confiance, normal c’est un tutoriel, il n’y a pas de raisons.

Premier mythe : je déplace le fichier de configuration

Le premier dont vous aurez peut-être déjà entendu parler, serait de déplacer le fichier de configuration, donc vous le remontez d’un cran dans l’arborescence au niveau du FTP et ça permet de faire en sorte que le fichier de configuration ne se trouve pas à la racine.

Habituellement, si vous tapez le nom de votre site/wp-config.php, vous aurez une page blanche, ce n’est pas une erreur, c’est juste que le wp-config n’écrit rien, mais au moins il est chargé.

Si on déplace ce fichier, effectivement on aura une 404, puisque ce fichier n’existe plus, donc on va se dire : OK le fichier est sécurisé puisqu’il n’est plus là !

Oui et non… parce que de toute façon la page blanche, je ne peux rien en faire, déjà première chose. Le fait de le remonter ne va pas retarder une faille qui permet de le trouver.

Je prends l’exemple de Revolution Slider malheureusement qui, il y a quelques années, si je ne me trompe pas en 2014/2015, avait une faille qui permettait…

Alex : Revolution Slider c’est un plugin de slider qui était sur ThemeForest.

Julio : Il y est toujours, il a été corrigé depuis de cette faille bien sûr.

Le Rev Slider mettait dans le front de votre site web des images et le lien vers l’image était… on voyait en clair d’où elle venait l’image, donc ça, c’était un peu le problème.

Quelqu’un s’est dit : qu’est-ce qui se passe si je mets le chemin du wp-config ?

Qu’est-ce qui s’est passé… le fichier wp-config était visible et ça, c’est un peu grave quand même !

La différence, si on remonte d’un cran, c’est juste que techniquement dans le chemin on va rajouter devant ../ c’est-à-dire qu’on va encore remonter d’un cran et normalement un script qui cherche le wp-config va le chercher là où il est, puis va faire ../ puis recommence, jusqu’à ce qu’il le trouve.

Alex : Il peut remonter différents niveaux.

Julio : Il remontera de toute façon sur le vôtre. Donc en fait, ça fait une 404, mais qui n’était de toute façon pas méchante et le bot, le script, le trouvera de toute façon, il est toujours accessible en fait.

Juste qu’il n’est plus accessible via l’URL, mais on s’en fiche puisque de toute façon il n’était pas méchant !

Alex : Dans le cas où il y a une faille avant, c’est ça ?

Julio : Voilà ! S’il y a une faille, il le trouvera de toute façon et si vous l’avez déplacé et qu’il n’y a pas de faille… ben ça ne sert à rien !

Alex : OK. Alors la deuxième fausse croyance, enfin la deuxième mauvaise pratique.

Deuxième mythe : le “deny from all”

Julio : Eh bien toujours sur ce fichier, il arrive aussi dans des tutoriels de voir que pour “protéger” ce fichier il suffirait, dans le fichier htaccess, d’ajouter un “deny from all”.

C’est-à-dire que si une personne justement tape le nom de votre site /wp-config, au lieu de la page blanche, il n’a pas une 404, mais une 403, c’est un dire un message lui interdisant l’accès à ce fichier : c’est écrit habituellement : “Forbidden vous n’avez pas le droit d’accès à cette page”

Alex : On est tous tombés sur ces pages là un moment donné ou à un autre et là ça fait en sorte de le déclencher.

Julio : C’est ça, c’est un accès interdit à cette page. Encore une fois, ça a le même effet que la page blanche. Je n’avais de toute façon pas accès au contenu et de toute façon, même si j’ai accès à ce fichier comme je viens de le faire, je ne peux rien en faire.

Donc, est-ce que ça, c’est l’avoir protégé, là pour l’instant non ! Maintenant, reprenons le cas précédent : Rev Slider : peut-il accéder à ce fichier pour le télécharger ? OUI.

Donc ça ne sert à rien puisqu’il faut bien faire la séparation de : je suis du côté “front” dans le navigateur, j’accède à une URL et du côté Rev Slider je suis en PHP, je navigue directement sur le serveur pour aller chercher le fichier.

C’est deux choses différentes !

Penser que faire un “deny from all” côté navigateur empêche le PHP d’aller le chercher, ben non en fait, on est sur deux couches différentes et donc ça n’aura pas servi à empêcher l’accès à un script à ce fichier.

Ça aurait été bien… bien sûr ! ça ne sert pas à ça !

Alex : Il n’y a pas moyen d’empêcher le téléchargement, dès qu’on a l’URL d’un fichier ?

Julio : Non ! Puisque le fichier PHP on en a besoin, WordPress en a besoin… si WordPress peut le lire, tout script va pouvoir le lire.

Alex : ça marche OK

Julio : Ce qu’il faudrait faire ce serait de sécuriser notre fichier config encore plus loin là-dedans, je pense qu’on pourrait peut-être faire ça pour la fois prochaine ?

Alex : OK : Pourquoi pas !

Julio : Très bonne idée !

Alex : ça marche ! Et du coup, troisième mauvaise pratique ?

Troisième mythe : Julio le maître des clés !

Julio : Troisième point, alors là c’est même écrit dans le codex, ça sera recommandé par tout le monde, je pense.

Je vais un peu à l’encontre de ça, c’est à dire que les clés de sécurité : vous avez déjà vu dans votre fichier wp-config, il y a un petit bloc…

Alex : 6 ou 7, je crois

Julio : Oui un bon paquet, je crois, maintenant, 6 ou 8 je crois. Pour vous dire que, je ne sais même plus le chiffre parce que je ne les utilise pas ! En fait non je ne les utilise pas, je les supprime de mon fichier de configuration.

Dans les tutoriels vous lisez, il faut les remplir, il faut les remplir, c’est important, il ne faut pas laisser la phrase par défaut qui est “put your unique phrase here” il faut les changer, il faut en générer des nouvelles.

Non en vrai, en vrai ça ne sert à rien ! C’est assez bizarre de le dire, mais ça ne sert à rien.

Pourquoi ?

Déjà si vous laissez la phrase par défaut, ou si vous la supprimez, WordPress le sait, il sait si vous laissez la phrase par défaut, il vérifie.

Dans ces cas-là, il se dit, la personne ne l’a pas mis ou a laissé les valeurs par défaut à la place, je vais en créer en base de données, déjà si on fait ça, WordPress ira en base de données.

Le paragraphe qui suit est totalement indépendant de notre volonté, nous vous prions de nous excuser pour la gêne occasionnée.

Quand WordPress va essayer de lire une de ces clés, il ne va pas lire le fichier wp-config, il va utiliser une fonction qui prendra l’un ou l’autre, s’il le trouve en base de données, il va mettre la priorité sur la base de données, donc s’il ne le trouve pas dans un fichier, de toute façon ce n’est pas grave, il l’a déjà en base de données donc il n’y a pas de problèmes, s’il l’a en fichier, OK très bien, il l’a en fichier… euh…. je viens de dire une bêtise ! 

Reprenons notre lecture…

Il donne la priorité au fichier pardon, il donne la priorité au ficher et s’il ne le trouve pas en fichier, il le crée en base ou il le lit en base. Si jamais vous l’ajoutez de nouveau dans vos fichiers, effectivement c’est là où il va le reprendre en compte avec les nouvelles clés.

Si vous laissez la phrase par défaut, il le sait, il créera des clés en base de données. Finalement, ça ne sert pas à grand-chose ! On va peut-être rappeler à quoi servent les clés…

Alex : C’est ce que j’allais te demander : “À quoi servent ces fameuses clés ? Julio”

Julio : Les clés, à quoi servent-elles ? Elles servent déjà à faire en sorte que chaque installation de WordPress a des clés différentes.

À chaque fois qu’on l’installe, ça génère 64 caractères différents à chaque fois, pour chaque personne, pour chaque site web. Donc ça déjà on est certain que les installations ont des clés différentes et la clé va intervenir dans la création de nos jetons de sécurité.

Les jetons de sécurité c’est ce que vous avez peut être déjà vu : wpnonce, ça veut dire number once, un chiffre qui est utilisé une fois. C’est un jeton de sécurité et donc si on change un caractère de cette chaîne, le jeton va en être totalement changé, ça permet de ne pas pouvoir deviner le jeton d’un autre site web.

Alex : D’accord !

Julio : Donc voilà pourquoi il est important d’avoir des clés, mais le fait de les mettre dans le fichier wp-config ça sert à rien, parce qu’au pire, WordPress les recrée en base de données.

Après, moi je n’aime pas non plus les mettre en base de données, je me dis : si on peut voler mon fichier wp-config comme Rev SLider, je préfère les mettre en base ! OK !

Et maintenant si je me dis : et si quelqu’un arrive à lire ma base de données, il a mes clés, donc je les remets dans un fichier, non je ne veux pas non plus !

Donc, ce que j’ai fait dans SecuPress, j’ai fait en sorte que l’on crée un mu-plugin, c’est un plugin must use, qui sera toujours chargé par WordPress, qui se trouve dans le dossier /wp-content/mu-plugins par défaut, et ce script va nous générer des clés automatiquement et tous les mois ces clés vont être modifiées.

Ça ne les écrit nulle part, ni dans un nouveau fichier ni en base de données, elles sont juste générées via le code. C’est-à-dire qu’on ne peut pas les lire clairement nulle part, sauf si on a accès à du PHP et qu’on essaye de faire un echo vraiment de cette chaîne.

[clickToTweet tweet=”Si on a accès au PHP, de toute façon on a tout ce qu’on veut pour tout casser ! #Sécurité #WordPress ” quote=”Si on a accès au PHP, de toute façon on a tout ce qu’on veut pour tout casser ! Donc on s’en fiche de ces clés finalement !”]

Le fait de générer de nouvelles clés aléatoires, tous les mois, qui sont non visibles par un humain, ni dans un fichier, ni en base de données, moi personnellement ça m’a plu !

Alex : OK super ! J’espère qu’on ne vous a pas perdu ! mais en tout cas l’idée c’est de ne pas forcément croire que ces clés sont super importantes dans le fichier wp-config !

Julio : Pas de panique !

Alex : WordPress peut gérer et il y a SecuPress en back-up…

Julio : qui permet justement de générer ces clés pour vous !

Conclusion

Alex : OK super ! Merci d’avoir suivi cette vidéo, j’espère que vous en savez maintenant un petit peu plus sur la sécurité, vous pourrez briller dans les dîners de développeurs ou de freelances.

Abonnez-vous à la chaîne YouTube de WPMarmite et bien sûr allez voir sur SecuPress pour sécuriser votre site !

Julio : Et dites-nous dans les commentaires si les vidéos techniques vous intéressent. À plus !

Alex : Salut ! Ciao.

Alors ? Les mythes sont-ils bien démystifiés 🙂