La robustesse de la sécurité de votre installation WordPress est entièrement modulable selon vos exigences. Découvrez les cinq aspects cruciaux pour une protection optimale.
Les préoccupations et les critiques concernant la sécurité de WordPress ne sont pas nouvelles.
Si vous recherchez un CMS et sollicitez un prestataire qui n’utilise pas WordPress, la sécurité sera l’argument principal qu’il avancera. Faut-il pour autant abandonner WordPress au profit de générateurs de sites statiques ou de CMS headless ?
Non, car comme toute vérité, celle-ci comporte plusieurs facettes.
WordPress est-il réellement peu sécurisé ?
Examinons quelques grands sites web qui ont été construits avec WordPress :
- Tech Crunch
- Le New Yorker
- BBC America
- Bloomberg
- MTV News
- Blog PlayStation
Alors, pourquoi ces entreprises, dotées de moyens financiers colossaux et d’équipes talentueuses, ne délaissent-elles pas WordPress ? Si vous pensez que la raison est un code obsolète, vous vous trompez : pour ces entités, la sécurité des données et l’image de marque sont bien plus importantes qu’une simple migration, dont le coût est (à mon avis) inférieur à 200 000 $.
Leurs ingénieurs sont compétents et n’identifient aucun problème de sécurité fondamental et insoluble avec WordPress, n’est-ce pas ?
Personnellement, j’ai la chance de gérer une installation WordPress qui attire entre 3,5 et 4 millions de visiteurs mensuels. Le nombre total de failles de sécurité rencontrées au cours des huit dernières années ? Zéro !
Alors… WordPress est-il sécurisé ?
Si cela semble être une provocation, voici ma réponse :
Je le dis car, comme tout dans la vie, c’est complexe. Pour obtenir une réponse pertinente, il est essentiel de comprendre que WordPress (ou tout autre CMS préconstruit) n’est pas une simple armoire que l’on installe et dont on n’a plus à se soucier.
C’est un logiciel complexe, avec de nombreuses dépendances :
- PHP, le langage sur lequel il repose.
- Une machine publiquement accessible hébergeant l’installation.
- Le serveur web assurant la gestion des visiteurs (Apache, Nginx, etc.).
- La base de données utilisée (MySQL/MariaDB).
- Les thèmes (ensembles de fichiers PHP, CSS et JS).
- Les extensions ou plugins (ensembles de fichiers PHP, CSS et JS).
- Et bien d’autres, en fonction des objectifs de votre installation.
En d’autres termes, une faille de sécurité dans l’un de ces éléments sera étiquetée comme une faille de WordPress.
Si le mot de passe root du serveur est « admin123 » et qu’il est compromis, est-ce une faille de sécurité de WordPress ?
Si la version de PHP présente une vulnérabilité ou si un nouveau plugin installé contient une faille de sécurité flagrante ; etc. En résumé : un sous-système défaille, et c’est une défaillance de la sécurité de WordPress.
Au passage, ne croyez pas non plus que PHP, MySQL ou Apache ne sont pas sécurisés. Tout logiciel a des vulnérabilités, qui sont nombreuses dans le cas de l’open-source (car il est accessible à tous pour l’examen et l’analyse).
Quelqu’un a dit « sécurisé » ? 😛
Ce que l’on peut tirer de cet exercice, c’est que :
Rien n’est intrinsèquement sûr ou non sûr. Ce sont les divers composants qui forment les maillons d’une chaîne, et cette chaîne est aussi solide que le plus faible de ses maillons. Historiquement, l’étiquette de « non sécurisé » de WordPress résultait d’une combinaison d’anciennes versions de PHP, de l’hébergement mutualisé et de l’ajout de plugins/thèmes provenant de sources douteuses.
Parallèlement, certaines négligences courantes rendent votre installation WordPress vulnérable aux personnes qui savent les exploiter. Et c’est bien de cela qu’il s’agit. Alors, sans plus tarder (et sans tergiversations), commençons.
Principales failles de WordPress exploitables par les pirates
Le préfixe des tables WordPress
L’installation en 5 minutes est une avancée majeure pour WordPress, mais comme tous les assistants d’installation, elle peut nous inciter à la paresse et à conserver les réglages 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 facilement devinables :
- wp_users
- wp_options
- wp_posts
Prenons l’exemple d’une attaque par injection SQL, qui consiste à insérer et exécuter des requêtes de base de données malveillantes au sein de WordPress (il est important de noter que ce type d’attaque n’est pas exclusif à WordPress/PHP).
Bien que WordPress intègre des mécanismes pour gérer ces attaques, il est impossible de garantir qu’elles ne se produiront pas.
Ainsi, si un attaquant parvient d’une manière ou d’une autre à exécuter une requête du type « DROP TABLE wp_users; DROP TABLE wp_posts; », tous vos comptes, profils et publications seront instantanément supprimés, sans possibilité de récupération (à moins de disposer d’une procédure de sauvegarde, mais même dans ce cas, vous risquez de perdre des données depuis la dernière sauvegarde).
Le simple fait de modifier le préfixe lors de l’installation constitue une protection majeure (et ne demande aucun effort).
Un préfixe aléatoire comme « sdg21g34_ » est recommandé car il est absurde et difficile à deviner (plus il est long, mieux c’est). Le plus avantageux est que vous n’avez pas à mémoriser ce préfixe, WordPress le sauvegardera et vous n’aurez plus jamais à vous en soucier (tout comme vous ne vous préoccupez pas du préfixe par défaut « wp_ »).
L’URL de connexion par défaut
Comment savoir si un site web utilise WordPress ? Un indice flagrant est la présence de la page de connexion WordPress lorsque vous ajoutez « /wp-login.php » à l’adresse du site.
Prenons l’exemple de mon site web (http://ankushthakur.com). Est-ce un site WordPress ? Ajoutez simplement la partie « connexion ». Si vous êtes trop paresseux, voici le résultat :
¯\_(ツ)_/¯
WordPress, n’est-ce pas ?
Une fois cela connu, un attaquant peut jubiler et appliquer les outils de son « arsenal » à tour de rôle. Quelle aubaine !
La solution consiste à modifier l’URL de connexion par défaut et à ne la communiquer qu’aux personnes de confiance.
Par exemple, ce site web est également sous WordPress, mais si vous visitez http://toptips.fr.com/wp-login.php, vous ne trouverez rien. L’URL de connexion est cachée et seuls les administrateurs la connaissent.
Modifier l’URL de connexion n’a rien de sorcier. Utilisez ce plugin.
Félicitations, vous venez d’ajouter une couche de sécurité supplémentaire contre les attaques par force brute.
La version PHP et du serveur web
Nous avons déjà évoqué le fait que tout logiciel (existant et en cours de création) est susceptible de contenir des bugs en attente d’être exploités.
Il en va de même pour PHP.
Même si vous utilisez la dernière version de PHP, vous n’êtes pas à l’abri de vulnérabilités qui pourraient être découvertes à tout moment. La solution consiste à masquer un en-tête spécifique envoyé par votre serveur web (connaissez-vous les en-têtes ? Lisez cet article !) lorsqu’un navigateur s’y connecte : « x-powered-by ».
Voici ce à quoi cela ressemble si vous vérifiez les outils de développement de votre navigateur :
Comme vous pouvez le voir, le site web révèle qu’il utilise Apache 2.4 et PHP version 5.4.16.
C’est une quantité considérable d’informations que nous communiquons sans raison, facilitant le travail des attaquants dans le choix de leurs outils.
Ces en-têtes (et d’autres similaires) doivent être masqués.
Heureusement, cela peut être fait rapidement. Malheureusement, cela nécessite des connaissances techniques pointues car il faut plonger dans les rouages du système et modifier des fichiers importants. Par conséquent, je vous conseille de demander à votre hébergeur de s’en charger. S’il n’est pas en mesure de le faire, demandez à un consultant, la configuration de votre hébergeur déterminant s’il offre de telles possibilités.
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.
Est-ce que cela en vaut la peine ? C’est à vous de décider. 🙂
Et si vous souhaitez vous familiariser avec les en-têtes de sécurité, voici la solution !
Nombre de tentatives de connexion
Une vieille astuce utilisée par les pirates est l’attaque par dictionnaire.
Le principe est de tenter un nombre astronomique de combinaisons (des millions, si possible) pour un mot de passe jusqu’à ce que l’une d’entre elles fonctionne. Étant donné la rapidité des ordinateurs, une telle approche a du sens et peut aboutir en un temps raisonnable.
Une défense courante (et très efficace) consiste à introduire un délai avant d’afficher une erreur. Cela oblige l’attaquant à attendre, ce qui signifie que si un script est utilisé, il mettra trop de temps à se terminer. C’est pourquoi votre ordinateur ou application met parfois du temps à réagir avant d’afficher « Oops, mauvais mot de passe ! ».
En bref, vous devez limiter le nombre de tentatives de connexion à votre site WordPress.
Au-delà d’un nombre défini d’essais (cinq par exemple), le compte doit être verrouillé et ne doit pouvoir être récupéré que par l’e-mail du titulaire du compte.
Heureusement, c’est très facile avec ce plugin.
HTTP contre HTTPS
Le certificat SSL que votre hébergeur essaie de vous vendre est plus important que vous ne le pensez.
Il ne s’agit pas uniquement d’un outil de réputation permettant d’afficher un cadenas vert dans le navigateur, signifiant « Sécurisé ». L’installation d’un certificat SSL et l’obligation d’utiliser « https » pour toutes les URL suffisent à elles seules à transformer votre site web d’un livre ouvert en un texte crypté.
Si vous ne comprenez pas comment cela fonctionne, renseignez-vous sur l’attaque de l’homme du milieu.
Une autre façon d’intercepter le trafic circulant de votre ordinateur vers le serveur est l’analyse de paquets, une forme passive de collecte de données qui ne nécessite même pas d’être au milieu.
Pour les sites fonctionnant en « HTTP » simple, la personne interceptant le trafic réseau voit clairement vos mots de passe et numéros de cartes de crédit en texte brut.
Source : comparitech.com
Effrayant ? Absolument !
Mais une fois que vous avez installé un certificat SSL et que toutes les URL sont converties en « https », ces informations sensibles apparaissent comme un charabia que seul le serveur peut déchiffrer. En d’autres termes, ne vous inquiétez pas pour ces quelques dollars par an. 🙂
Conclusion
Ces cinq mesures suffiront-elles à sécuriser votre site web ?
Absolument pas. Comme le mentionnent d’innombrables articles sur la sécurité, la sécurité à 100 % n’existe pas, mais il est possible d’éliminer une grande partie de ces problèmes en faisant des efforts raisonnables. Vous pouvez envisager d’utiliser SUCURI Cloud WAF pour une protection globale de vos sites.