Top 5 des failles de sécurité dans les installations WordPress

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


Les préoccupations 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’est pas dans WordPress, la sécurité est le problème numéro un dont vous entendrez parler. Est-ce que cela signifie 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 sites Web énormes qui ont été construits sur WordPress:

  • TechCrunch
  • Le new yorker
  • BBC America
  • Bloomberg
  • MTV News
  • Blog PlayStation

Alors, qu’est-ce qui empêche ces entreprises – avec des poches absurdement profondes et une main-d’œuvre époustouflante – de passer de WordPress? Si vous pensez que la réponse est un 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 (j’estime) moins de 200 000 $.

Leurs ingénieurs savent sûrement ce qu’ils font et ne voient aucun problème de sécurité fondamental et insoluble avec WordPress?

Même moi, j’ai la chance de gérer une installation WordPress qui voit 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!

Donc . . . WordPress est-il sécurisé?

Je suis désolé si cela ressemble à de la pêche à la traîne, mais voici ma réponse:

Je le dis parce que, comme toute vérité dans la vie, c’est compliqué. Pour arriver à une réponse légitime, nous devons d’abord comprendre que WordPress (ou tout CMS pré-construit, d’ailleurs) n’est pas comme un placard que vous collez quelque part de façon permanente et en finir avec.

C’est un logiciel complexe avec de nombreuses dépendances:

  • PHP, qui est le langage avec lequel il est construit
  • Une machine visible publiquement 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)
  • Thèmes (bundles de fichiers PHP, CS et JS)
  • Plugins (bundles de fichiers PHP, CS et JS)
  • Et bien d’autres, en fonction de l’objectif de votre installation

En d’autres termes, une violation de la sécurité à l’une de ces coutures sera qualifiée de violation de WordPress.

Si le mot de passe root du serveur était admin123 et qu’il a été compromis, est-ce une faille de sécurité WordPress?

Si la version PHP avait une vulnérabilité de sécurité; ou si le nouveau plugin que vous avez acheté et installé contenait une faille de sécurité flagrante; etc. Pour résumer: un sous-système échoue et c’est une défaillance de sécurité WordPress.

En passant, veuillez également ne pas laisser cela vous donner l’impression que PHP, MySQL et Apache ne sont pas sécurisés. Chaque logiciel a des vulnérabilités, dont le nombre est stupéfiant dans le cas de l’open source (car il est disponible pour tout le monde à voir et à analyser).

Quelqu’un a-t-il dit «sécurisé»? ��

Pour la source de ces données et autres statistiques démoralisantes, regarde ça.

Ce que nous apprenons de tout cet exercice est le suivant:

Rien n’est sûr ou peu sûr en soi. Ce sont les différents composants utilisés qui forment les maillons de la chaîne, la chaîne, bien sûr, étant aussi forte que la plus faible d’entre elles. Historiquement, le label «non sécurisé» de WordPress était une combinaison d’anciennes versions PHP, d’hébergement partagé et d’ajout de plugins / thèmes à partir de sources non fiables.

Dans le même temps, quelques oublis assez courants rendent votre installation WordPress vulnérable à ceux qui savent les exploiter et qui sont déterminés. Et c’est de cela qu’il s’agit. Alors sans plus tarder (et des arguments circulaires), commençons.

Les principales failles de WordPress que les pirates peuvent exploiter

Le préfixe du tableau WordPress

La célèbre installation de 5 minutes est la meilleure chose qui puisse arriver à 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 de vos tables WordPress est wp_, ce qui donne des noms de table que tout le monde peut deviner:

  • utilisateurs-wp
  • wp-options
  • wp-posts

Maintenant, considérons une attaque connue sous le nom d’Injection SQL, où des requêtes de bases de données malveillantes sont intelligemment insérées et faites pour s’exécuter dans WordPress (veuillez noter – ce n’est en aucun cas une attaque exclusive à WordPress / PHP).

Bien que WordPress dispose de mécanismes intégrés pour gérer ces types d’attaques, personne ne peut garantir que cela ne se produira pas.

Donc, si d’une manière ou d’une autre, l’attaquant parvient à exécuter une requête comme DROP TABLE wp_users; DROP TABLE wp_posts ;, tous vos comptes, profils et publications seront effacés en un instant sans possibilité de récupération (sauf si vous avez un schéma de sauvegarde en place, mais même dans ce cas, vous perdrez des données depuis la dernière sauvegarde ).

Changer simplement le préfixe pendant l’installation est un gros problème (ce qui prend zéro effort).

Quelque chose d’aléatoire comme sdg21g34_ est recommandé car 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émorable; le préfixe est quelque chose que WordPress va enregistrer, et vous n’aurez plus jamais à vous en soucier (tout comme vous ne vous inquiétez pas du préfixe wp_ par défaut!).

L’URL de connexion par défaut

Comment savez-vous qu’un site Web fonctionne sur WordPress? L’un des signes révélateurs est que vous voyez la page de connexion WordPress lorsque vous ajoutez «/wp-login.php» à l’adresse du site Web.

Par exemple, prenons mon site Web (http://ankushthakur.com). Est-ce sur WordPress? Eh bien, allez-y et ajoutez la partie de connexion. Si vous vous sentez trop paresseux, voici ce qui se passe:

¯ \ _ (ツ) _ / ¯

WordPress, à droite?

Une fois que tout cela est connu, l’attaquant peut se frotter les mains de joie et commencer à appliquer des astuces désagréables de leur 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 sera une déception profonde et profonde. L’URL de connexion est masquée et n’est connue que des administrateurs ?.

Changer l’URL de connexion n’est pas non plus une science complexe. Prenez ça brancher.

Toutes nos félicitations, vous venez d’ajouter une autre couche de sécurité frustrante contre les attaques par force brute.

La version PHP et serveur Web

Nous avons déjà discuté du fait que chaque logiciel jamais écrit (et en cours d’écriture) est plein de bogues attendant d’ê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 existantes et susceptibles d’ê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 d’en-têtes? Lire cette!) lorsqu’un navigateur s’y connecte: propulsé par x.

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

Comme nous pouvons le voir ici, le site Web nous dit qu’il fonctionne sur Apache 2.4 et utilise PHP version 5.4.16.

Maintenant, c’est déjà une tonne d’informations que nous transmettons sans raison, aidant l’attaquant à restreindre son choix d’outils.

Ces en-têtes (et similaires) doivent être masqué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 jouer avec des fichiers importants. Par conséquent, mon conseil est de demander à votre hébergeur de site Web de le faire pour vous; s’ils ne voient pas si un consultant peut le faire, bien que cela dépende en grande partie de l’hébergeur de votre site Web, que leur configuration ait de telles possibilités ou non.

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

Est-ce que ça vaut le coup? Vous seul pouvez décider cela. ��

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

Nombre de tentatives de connexion

L’un des plus anciens trucs du manuel du pirate est le soi-disant Attaque par dictionnaire.

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

Une défense courante (et extrêmement efficace) a été d’ajouter un délai avant de montrer l’erreur. Cela fait attendre le destinataire, ce qui signifie que s’il s’agit d’un script utilisé par un pirate, il prendra trop de temps pour terminer. C’est la raison pour laquelle votre ordinateur ou votre application préférée rebondit un peu et dit ensuite: “Oups, le mauvais mot de passe!”.

Quoi qu’il en soit, le fait est que vous devez limiter le nombre de tentatives de connexion pour votre site WordPress.

Au-delà d’un nombre défini d’essais (disons, cinq), le compte doit être verrouillé et ne doit être récupérable que par e-mail du titulaire du compte.

Heureusement, cela est un jeu d’enfant si vous tombez sur une belle brancher.

HTTP contre HTTPS

Le certificat SSL dont votre fournisseur vous a importuné est plus important que vous ne le pensez.

Ce n’est pas simplement un outil de réputation pour afficher une icône de verrouillage verte dans le navigateur qui dit “Sécurisé”; au lieu de cela, obtenir un certificat SSL installé et forcer toutes les URL à fonctionner sur “https” est suffisant pour faire de votre site Web un livre ouvert à un défilement cryptique.

Si vous ne comprenez pas comment cela se produit, veuillez lire quelque chose connu sous le nom de attaque de l’homme du milieu.

Une autre façon d’intercepter le trafic circulant de votre ordinateur vers 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 s’exécutent sur du «HTTP» en clair, la personne interceptant le trafic réseau, vos mots de passe et numéros de carte de crédit apparaissent en clair et en clair.

Source: comparitech.com

Effrayant? Très!

Mais une fois que vous avez installé un certificat SSL et que toutes les URL sont converties en «https», ces informations sensibles apparaissent comme du charabia que seul le serveur peut déchiffrer. En d’autres termes, ne faites pas suer ces quelques dollars par an. ��

Conclusion

Sera sous contrôle de ces cinq choses, sécurisera bien votre site Web?

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 SUCURI cloud WAF pour protéger vos sites de manière globale.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map