Salut à tous et bienvenue dans ce nouveau “point sécu” avec Julio, dans lequel nous allons voir comment sécuriser le fichier wp-config de WordPress.
Allez c’est parti !
Alors, le fichier wp-config de WordPress, vous savez c’est un fichier vraiment très important, c’est un peu le coeur… enfin pas le coeur, mais la pierre angulaire de WordPress parce qu’il y a des informations très sensibles à l’intérieur.
Vos connexions à la base de données… et puis quoi d’autre ?
Julio : Il n’y a plus les clés de sécurité si vous suivez les vidéos.
Alex : C’est ça ! Donc voilà, il faut vraiment le protéger, parce que si quelqu’un met la main dessus, il a accès à tout votre site.
Julio : Donc ce fichier contient ce que l’on appelle des constantes PHP : c’est toutes les lignes qui commencent par “define”.
Il y a deux paramètres à l’intérieur de cette fonction PHP, le premier est le nom de la constante…
Alex : En majuscules…
Julio : Et le second c’est sa valeur. Donc quand je vais vous parler d’une constante PHP, vous savez que ça parle de cette fonction “define” suivie du premier mot qui est son nom.
Donc ce que l’on va faire évidemment, puisque c’est une vidéo qui va contenir du code, on va vous remettre chaque morceau de code dans la description.
En attendant, j’ai mon petit carnet, parce que je vais vous les lire, je vais vous en donner quelques-uns.
C’est des constantes qui vont vous permettre d’améliorer la sécurité.
Sommaire
allow_unfiltered_uploads
Je vais prendre la première pour vous donner un exemple : Il y a une constante qui s’appelle :
allow_unfiltered_uploads
En français : autoriser les téléchargements non filtrés.
Par défaut, elle n’est pas définie, c’est-à-dire que quelqu’un pourrait la définir, donc ce qui est intéressant, c’est de tout de suite la définir pour la mettre sur sa valeur “fausse” donc “false”.
Que fait cette constante ?
Si on autorisait l’upload non filtré, ça veut dire qu’en fait, on pourrait envoyer des fichiers qui normalement ne sont pas autorisés par WordPress.
Donc, ça représente forcément un danger.
Alex : Par exemple, quel type de fichier ?
Julio : On ne peut tout de même pas envoyer les PHP et les exécutables parce que ça WordPress, dans son code, les refuse. Pareil, je crois pour le swf.
Mais par exemple, je ne sais pas moi… il y a les fichiers svg.
Imaginons que quelqu’un dise “moi je veux ajouter le fichier svg”.
On pourrait très bien dire, ça fait partie des types de fichiers qui ne sont autorisés par exemple que pour les administrateurs, mais par pour un éditeur, or si cette constante n’était pas définie, on pourrait très bien dire : tous les rôles vont pouvoir le faire.
Tous les rôles qui ont le droit d’uploder ont le droit d’uploder n’importe quel type de fichier.
Donc, certains fichiers svg pourraient contenir du contenu malicieux, puisque finalement dedans, c’est un fichier XML – un fichier XML peut contenir du code à exécuter.
Tout ça pour dire que cette constante, si vous-même vous la paramétrez sur “faux”, vous interdisez instantanément l’upload des fichiers non filtrés, donc ça, c’est assez intéressant.
Voilà le genre de choses qu’on a.
On a un peu la même chose avec le HTML.
disallow_unfiltered_html
Celle-là est un peu moins connue et parfois elle peut poser problème, donc attention à votre besoin.
Je vous la donne, elle s’appelle :
disallow_unfiltered_html
Donc celle-ci c’est une double négation – désolé pour ceux qui n’aiment pas la double négation comme moi – c’est pour interdire le HTML non filtré.
Les administrateurs de WordPress, il faut le savoir, ont le droit de publier des contenus HTML non filtrés, c’est-à-dire que l’on peut…
C’est là où le problème pour moi va arriver, c’est qu’on peut ajouter dans un contenu d’un article une balise script, une balise iframe et ça beaucoup de personnes le font, pourquoi ?
Parce que beaucoup de personnes publient du contenu avec un compte administrateur.
Je pense que ce n’est pas le bon rôle : quand on est administrateur on administre, quand on est auteur, on crée du contenu et quand on est éditeur aussi.
En fait, le fait de pouvoir ajouter des iframes laisse la possibilité à d’autres iframes malicieuses d’être incluses dans des posts et ça, c’est moins bien.
La même chose pour des balises script évidemment, instantanément c’est du JavaScript qui est lancé, le JavaScript on peut faire des requêtes ajax, distantes, inclure des publicités, donc c’est relativement grave.
Un administrateur a les droits pour faire ça. Donc ça pour moi ce n’est pas normal, mais comme qu’il y a beaucoup de personnes qui le font, à vous de le savoir.
Si vous avez besoin tout de même de faire l’inclusion de scripts et de iframes, vous ne pourrez pas toucher à cette constante, mais si vous estimez comme moi que c’est quelque chose qui ne doit pas être fait, je vous invite à mettre la valeur “vraie” sur disallow_unfiltered_html
Si vous êtes dans le cas où vous vous dites : “effectivement c’est pas sécure, mais j’en ai besoin”, ce qu’il faut faire, c’est transformer les balises iframes en shortcodes et les scripts en shortcodes, comme ça, seul le shortcode pourra être utilisé dans le contenu de l’article et non plus directement une balise.
Alex : Et donc là, tout passe dans l’article même si on n’est pas administrateur.
Julio : Voilà exactement, ça veut dire qu’on l’autorise d’une façon correcte, on pourrait très bien même avoir une liste autorisée des sites web qui sont utilisables dans cette balise iframe.
Pour dire, attention, seuls YouTube, Vimeo… tout ce qui est vidéo sont autorisés en iframes, le reste je refuse.
Parce que ce qui se passe c’est que, des contenus publicitaires venant d’autres sites peuvent être inclus aussi et c’est pour moi là où arrive le danger en fait.
On peut encore en voir une autre.
disallow_file_edit
Celle-là elle est très très importante, je pense, c’est :
disallow_file_edit
Si vous allez dans le menu, vous avez extension ou apparence, et à l’intérieur, vous avez éditeur.
Cet éditeur pour moi, c’est quelque chose qui n’est pas normal.
Si on veut éditer du fichier PHP ou CSS, on doit éditer via le FTP, d’accord…
Alex : Sur le serveur…
Julio : Le “F” de FTP ça veut dire fichier, alors que le HT ça veut dire hyper texte, donc si on édite du texte, très bien on est dans le WordPress => Administration.
Si on touche aux fichiers, alors on va sur le FTP. Dans ce cas-là on peut modifier les fichiers.
Le gros risque de laisser cet éditeur, c’est qu’il peut être détourné pour modifier des fichiers PHP, pour inclure directement du contenu malicieux et là, là c’est une horreur, là c’est vraiment très grave.
Il y a eu une faille, je crois, il y deux ans de cela en 2015, où via un commentaire, ça a ajouté du JavaScript qui allait cliquer à la place de l’administrateur dans cet éditeur pour remplacer le contenu du plugin par défaut “Hello Dolly” par une porte dérobée – une back door – qui validait ensuite ce fichier, “Hello Dolly” devenait une back door
C’est assez énorme, j’ai un article là-dessus sur SecuPress qui explique un peu comment ça s’est passé.
Donc, si, simplement les gens avaient disallow_file_edit sur “true” (valeur vraie) personne ne pouvait se faire pirater, tous les gens qui n’avaient pas ça, on pu se faire pirater.
Alex : D’accord !
Julio : Vous voyez, juste par une ligne de code dans un wp-config, il est possible d’éviter une vague de failles, c’est quand même assez énorme.
J’en ai d’autres, je pense qu’on va encore les ajouter en description.
Alex : Ouais ça marche… Allez, le petit carnet se referme !
Julio : Je le garde, c’est mon secret !
Alex : Vous retrouverez tout en description, il y a les morceaux de codes pour vous aider à y voir plus clair avec les différentes constantes du wp config.
Peut-être un petit mot sur le préfixe de base de données avant de repartir.
Julio : Allez, sur le préfixe de base de données en bonus.
Le préfixe de la base de données, comme on l’a dit dans une vidéo précédente, n’allez pas le modifier directement dans la base.
N’ouvrez pas phpMyAdmin pour aller dire, tiens je vais aller modifier mon préfixe.
Vous avez peut-être entendu dans des tutoriels, dans des vidéos : il faut changer le préfixe de base de données pour ne pas que ce soit wp_ c’est-à-dire la valeur par défaut.
Ce qui manque dans ces vidéos c’est le “pourquoi” : pourquoi est-ce qu’il faut le changer en fait ?
C’est relativement simple, il y a une faille qui s’appelle SQL injection, qui va donc permettre à un attaquant d’injecter du code d’une requête de base de données quelque part chez vous.
Ce qui va lui permettre d’insérer des contenus ou de récupérer des contenus.
Donc il peut très bien récupérer les données clients. C’est quelque chose qu’il faut évidemment éviter.
Sauf que pour ça, il a besoin de connaître le nom des tables et pour connaître le nom des tables – il connaît les noms des tables parce qu’ils sont dans WordPress, mais il lui faut aussi le préfixe pour avoir le nom complet.
Par défaut, il va tester wp_ en espérant que personne ne l’ait changé. Donc, si vous êtes dans ce cas là, il y a un risque potentiel, si vous l’avez changé, dès sa première requête, ça fonctionne plus, il ne va pas pouvoir continuer, il va très vite s’apercevoir que pour lui c’est terminé, il s’arrête.
Donc changez-le, en sachant que vous le faites pour bloquer les possibles injections SQL.
Alex : OK ! Bon ben maintenant je pense que c’est clair !
Julio : Maintenant c’est clair.
Alex : SecuPress, ça fait ça, c’est ça ?
Julio : ça le fait aussi
Alex : Il y a des petits plugins qui font ça aussi tous seuls;
Formez-vous à WordPress en 3 mois
Apprenez à concevoir des sites WordPress sécurisés, rapides et conformes aux obligations légales avec la formation à distance la plus généreuse du marché (éligible au CPF).
Pour conclure
Merci d’avoir suivi cette vidéo, j’espère que votre wp config.php sera plus sécurisé.
En attendant, n’oubliez pas de vous abonner à la chaîne YouTube de WPMarmite et de mettre des pouces bleus un petit peu partout…
Et puis allez voir sur secupress.me pour sécuriser davantage votre site.
Voilà, merci de nous avoir suivis et à très bientôt pour une prochaine vidéo.
Ciao ! Salut !
Vous voilà bien paré pour configurer aux petits oignons votre fichier wp-config