Les 5 principales failles de sécurité dans les installations WordPress

Votre installation WordPress peut être aussi sécurisée ou non que vous le souhaitez. Découvrez les cinq éléments les plus importants en matière de sécurité.

Les inquiétudes et les plaintes concernant la sécurité de WordPress ne sont pas nouvelles.

Si vous avez besoin d'un CMS et que vous consultez un fournisseur de services qui n'utilise pas WordPress, la sécurité est le principal problème dont vous entendez parler. Cela signifie-t-il que tout le monde devrait abandonner WordPress et passer à des générateurs de sites statiques ou à un CMS sans tête?

Non, car comme toutes les vérités de la vie, celle-ci a aussi de nombreux côtés.

WordPress est-il très peu sûr ?

Jetons un coup d'œil à quelques grands sites web qui ont été construits sur WordPress :

• TechCrunch
• The New Yorker
• BBC America
• Bloomberg
• MTV News
• PlayStation Blog

Alors, qu'est-ce qui fait que ces entreprises - aux poches absurdement profondes et à la main-d'œuvre époustouflante - ne passent pas à WordPress ? Si vous pensez que la réponse est le code hérité, détrompez-vous : pour ces noms, la sécurité des données et l'image publique sont infiniment plus importantes qu'une simple migration qui coûtera (selon mes estimations) moins de 200 000 dollars.

Leurs ingénieurs savent sûrement ce qu'ils font et ne voient pas de problèmes de sécurité fondamentaux et insolubles dans WordPress

Même moi, j'ai la chance de gérer une installation WordPress qui reçoit 3,5 à 4 millions de visiteurs par mois. Le nombre total de failles de sécurité au cours des huit dernières années ? Zéro !

Alors... WordPress est-il sûr ?

Je suis désolé si vous avez l'impression de troller, mais voici ma réponse :

Je dis cela parce que, comme toute vérité dans la vie, c'est compliqué. Pour parvenir à une réponse légitime, nous devons d'abord comprendre que WordPress (ou tout autre CMS préconstruit, d'ailleurs) n'est pas comme une armoire que l'on colle quelque part de façon permanente et que l'on n'a plus à s'en soucier.

Il s'agit d'un logiciel complexe avec de nombreuses dépendances :

• PHP, qui est le langage avec lequel il est construit
• Une machine publiquement visible qui héberge l'installation
• Le serveur web utilisé pour gérer les visiteurs (Apache, Nginx, etc.)
• La base de données utilisée (MySQL/MariaDB)
• Les thèmes (ensembles de fichiers PHP, CS et JS)
• Plugins (ensemble de fichiers PHP, CS et JS)
• Et bien d'autres encore, en fonction des objectifs de votre installation

En d'autres termes, une faille de sécurité à l'un de ces niveaux sera qualifiée de faille WordPress.

Si le mot de passe racine du serveur était admin123 et qu'il a été compromis, s'agit-il d'une faille de sécurité de WordPress ?

Si la version de PHP présente une faille de sécurité, ou si le nouveau plugin que vous avez acheté et installé contient une faille de sécurité flagrante, et ainsi de suite. En résumé : Si un sous-système est défaillant, il s'agit d'une faille de sécurité de WordPress.

Soit dit en passant, ne vous laissez pas convaincre que PHP, MySQL et Apache ne sont pas sûrs. Chaque logiciel présente des vulnérabilités, dont le nombre est stupéfiant dans le cas des logiciels libres (parce qu'ils sont disponibles pour que tout le monde puisse les voir et les analyser).

Ce que nous apprenons de tout cet exercice, c'est ceci :

Rien n'est sûr ou non sûr en soi. Ce sont les différents composants utilisés qui forment les maillons de la chaîne, la chaîne étant bien entendu aussi solide que le plus faible d'entre eux. Historiquement, l'étiquette "non sécurisé" de WordPress était une combinaison d'anciennes versions de PHP, d'hébergement partagé et d'ajout de plugins/thèmes provenant de sources non fiables.

En même temps, certains oublis assez courants rendent votre installation WordPress vulnérable à ceux qui savent comment les exploiter et qui sont déterminés. Et c'est de cela que traite cet article. Alors sans plus attendre (et sans argumentation circulaire), commençons.

Principales failles de WordPress que les pirates peuvent exploiter

Le préfixe de table de WordPress

La fameuse installation en 5 minutes est la meilleure chose qui soit arrivée à WordPress, mais comme tous les assistants d'installation, elle nous rend paresseux et laisse les choses par défaut.

Cela signifie que le préfixe par défaut pour vos tables WordPress est wp_, ce qui donne des noms de tables que tout le monde peut deviner :

• wp-users
• wp-options
• wp-posts

Considérons maintenant une attaque connue sous le nom d'injection SQL, où des requêtes de base de données malveillantes sont astucieusement insérées et exécutées à l'intérieur de WordPress (veuillez noter qu'il ne s'agit en aucun cas d'une attaque exclusive à WordPress/PHP).

Bien que WordPress dispose de mécanismes intégrés pour gérer ce type d'attaques, personne ne peut garantir qu'elles ne se produiront pas.

Ainsi, si d'une manière ou d'une autre, l'attaquant parvient à exécuter une requête telle que DROP TABLE wp_users ; DROP TABLE wp_posts ;, tous vos comptes, profils et messages seront effacés en un instant, sans aucune chance de récupération (à moins que vous n'ayez mis en place un système de sauvegarde, mais même dans ce cas, vous perdez certainement des données depuis la dernière sauvegarde).

Le simple fait de changer le préfixe lors de l'installation est un gros problème (qui ne demande aucun effort).

Quelque chose d'aléatoire comme sdg21g34_ est recommandé parce que c'est un non-sens et difficile à deviner (plus le préfixe est long, mieux c'est). La meilleure partie est que ce préfixe n'a pas besoin d'être mémorisable ; le préfixe est quelque chose que WordPress va sauvegarder, et vous n'aurez plus jamais à vous en soucier (tout comme vous ne vous souciez pas du préfixe par défaut wp_!).

L'URL de connexion par défaut

Comment savez-vous qu'un site web fonctionne sous WordPress ? L'un des signes révélateurs est l'affichage de la page de connexion de WordPress lorsque vous ajoutez "/wp-login.php" à l'adresse du site web.

Prenons l'exemple de mon site web (http://ankushthakur.com). Est-il sur WordPress ? Eh bien, allez-y et ajoutez la partie "login". Si vous êtes trop paresseux, voici ce qui se passe :

¯\_(ツ)_/¯

WordPress, c'est ça ?

Une fois que tout cela est connu, l'attaquant peut se frotter les mains de joie et commencer à appliquer des trucs méchants tirés de son Bag-O'-Doom sur une base alphabétique. Pauvre de moi !

La solution consiste à modifier l'URL de connexion par défaut et à ne la donner qu'aux personnes de confiance.

Par exemple, ce site web est également sur WordPress, mais si vous visitez http://geekflare.com/wp-login.php, tout ce que vous obtiendrez, c'est une profonde déception. L'URL de connexion est cachée et n'est connue que des administrateurs ?

Changer l'URL de connexion n'est pas sorcier non plus. Il vous suffit de télécharger ce plugin.

Félicitations, vous venez d'ajouter une couche supplémentaire de sécurité contre les attaques par force brute.

La version de PHP et du serveur web

Nous avons déjà évoqué le fait que tous les logiciels écrits (et en cours d'écriture) sont pleins de bogues qui n'attendent qu'à être exploités.

Il en va de même pour PHP.

Même si vous utilisez la dernière version de PHP, vous ne pouvez pas être sûr des vulnérabilités qui existent et qui pourraient être découvertes du jour au lendemain. La solution consiste à masquer un en-tête particulier envoyé par votre serveur web (vous n'avez jamais entendu parler des en-têtes ? lisez ceci!) lorsqu'un navigateur se connecte avec lui : x-powered-by.

Voici à quoi cela ressemble si vous consultez les outils de développement de votre navigateur préféré :

Comme nous pouvons le voir ici, le site web nous indique qu'il tourne sous Apache 2.4 et utilise la version 5.4.16 de PHP.

C'est déjà une tonne d'informations que nous transmettons sans raison, pour aider l'attaquant à réduire son choix d'outils.

Ces en-têtes (et d'autres similaires) doivent être cachés.

Heureusement, cela peut être fait rapidement ; malheureusement, des connaissances techniques sophistiquées sont nécessaires, car vous devrez plonger dans les entrailles du système et toucher à des fichiers importants. Je vous conseille donc de demander à votre hébergeur de site web de le faire pour vous ; s'il ne le fait pas, demandez à un consultant de le faire, bien que cela dépende en grande partie de votre hébergeur de site web pour savoir si son installation offre de telles possibilités ou non.

Si cela ne fonctionne pas, il est peut-être temps de changer d'hébergeur ou de passer à un VPS et d'engager un consultant pour les questions de sécurité et d'administration.

Le jeu en vaut-il la chandelle ? Vous seul pouvez en décider 🙂 .

Oh, et si vous voulez vous familiariser avec les en-têtes de sécurité, voici votre solution!

Nombre de tentatives de connexion

L'une des plus anciennes astuces du manuel du pirate informatique est l'attaque par dictionnaire.

L'idée est d'essayer un nombre ridiculement élevé (des millions, si possible) de combinaisons pour un mot de passe, jusqu'à ce que l'une d'entre elles réussisse. Étant donné que les ordinateurs sont rapides comme l'éclair dans ce qu'ils font, un schéma aussi stupide est raisonnable et peut donner des résultats dans un délai raisonnable.

Une défense courante (et extrêmement efficace) consiste à ajouter un délai avant d'afficher l'erreur. Cela fait attendre le destinataire, ce qui signifie que s'il s'agit d'un script employé par un pirate informatique, il mettra trop de temps à se terminer. C'est la raison pour laquelle votre ordinateur ou votre application préférée rebondit un peu avant de dire "Oups, le mauvais mot de passe !".

Quoi qu'il en soit, vous devez limiter le nombre de tentatives de connexion à votre site WordPress.

Au-delà d'un certain nombre de tentatives (disons cinq), le compte doit être verrouillé et ne doit pouvoir être récupéré que par l'intermédiaire de l'adresse électronique du titulaire du compte.

Heureusement, c'est un jeu d'enfant si vous trouvez un bon plugin.

HTTP contre HTTPS

Le certificat SSL dont votre vendeur vous rebat les oreilles est plus important que vous ne le pensez.

Il ne s'agit pas simplement d'un outil de réputation permettant d'afficher une icône de cadenas vert dans le navigateur avec la mention "Secure" ; en fait, l'installation d'un certificat SSL et le fait de forcer toutes les URL à fonctionner en "https" suffisent à faire passer votre site web du statut de livre ouvert à celui de parchemin crypté.

Si vous ne comprenez pas comment cela se produit, lisez ce que l'on appelle une attaque de l'homme du milieu.

Un autre moyen d'intercepter le trafic entre votre ordinateur et le serveur est le reniflage de paquets, qui est une forme passive de collecte de données et n'a même pas besoin de prendre la peine de se positionner au milieu.

Pour les sites qui fonctionnent en "HTTP", la personne qui intercepte le trafic réseau, vos mots de passe et vos numéros de carte de crédit apparaissent en clair.

Effrayant ? Très effrayant !

Mais une fois que vous avez installer un certificat SSL et que toutes les URL sont converties en "https", ces informations sensibles apparaissent sous la forme d'un charabia que seul le serveur peut décrypter. En d'autres termes, ne vous souciez pas de ces quelques dollars par an 🙂 .

Conclusion

La maîtrise de ces cinq éléments va-t-elle permettre de sécuriser votre site web de manière satisfaisante ?

Non, pas du tout. Comme le disent d'innombrables articles sur la sécurité, vous n'êtes jamais sûr à 100 %, mais il est possible d'éliminer une grande partie de ces problèmes avec un effort raisonnable. Vous pouvez envisager d'utiliser le nuage WAF de SUCURI pour protéger vos sites de manière holistique.