Publié le 15 novembre 2016

Ce que vous devez savoir sur la sécurité de votre CMS

Les actualités montrent tous les jours que la sécurité est un enjeu majeur sur Internet. Voici quelques idées reçues complètement fausses sur la sécurité des sites web, en particulier ceux construits sur un CMS comme WordPress.

Attention, ceci ne remet en aucun cas en question la sécurité de WordPress, qui est une plateforme très sûre. Les remarques ci-dessous s’appliquent en fait à n’importe quelle solution hébergée, qu’il s’agisse d’un CMS open source ou d’un développement spécifique. Simplement, comme près d’un site web sur 3 dans le monde est basé sur WordPress *, le potentiel d’exploitation d’une faille WP est énorme et surtout bien plus rentable à utiliser qu’une faille sur un CMS plus confidentiel.

C’est pourquoi le code WordPress est scruté en long et en large par les pirates et que ses failles, lorsqu’il y en a, sont très rapidement utilisées par des pirates. Elles sont tout aussi rapidement comblées par l’équipe chargée du cœur de WordPress. C’est malheureusement beaucoup plus variable pour ses plugins.

J‘installe mon CMS et c’est fini !

Faux2

FAUX : Une fois votre CMS installé (WordPress à tout hasard), il reste pas mal de réglages à effectuer. Les paramètres de sécurité ne sont pas optimaux. Il faut installer et configurer les plugins.

D’une manière générale, il vaut mieux faire une installation locale, développer et intégrer sur un poste de développement et mettre en ligne la version finalisée et sécurisée. Mettre en ligne une version de base sur votre hébergement et réaliser l’intégration dessus, c’est prendre le risque que votre site soit piraté avant même que vous ayez finalisé l’intégration.

Mon site n’est pas important

FAUX : Ce n’est sans doute pas votre site qui est visé mais ses failles de sécurité.

Pour un pirate, un site piraté n’est souvent qu’une plateforme supplémentaire pour lancer d’autres attaques de plus grande ampleur. Aucune différence entre le site d’une mairie, d’une entreprise ou d’une ONG.

RE-FAUX : Votre site est toujours important car votre image est en jeu.

Même si votre site est piraté pour fournir un moyen d’attaque supplémentaire, il y aura a minima des conséquences majeures et durables sur l’image de votre entreprise et votre e-réputation. Votre site web est souvent le premier contact entre votre prospect et votre société. Souhaitez-vous vraiment que ce premier contact soit une alerte de sécurité, une page pornographique, une contamination par un virus ou une invitation à écouter le dernier album de Maître Gims ? D’ailleurs, s’il n’était pas important, auriez-vous vraiment investi dans la création d’un site web ?

RE-RE-FAUX : Si votre site est piraté, les moteurs de recherche vont rapidement le détecter et une alerte de sécurité risque de lui être associée pour longtemps dans les résultats de recherche.

ET… ENCORE FAUX : Si votre site est contaminé, l’auteur de l’attaque s’en est sans doute servi pour lancer des actions illégales, comme par exemple distribuer des virus, lancer des vagues de spam ou des attaques par Déni de Service Distribué (DDoS). Votre serveur sera donc identifié comme un serveur dangereux.

L’accès à votre site ou à votre serveur peut être restreint par certains fournisseurs d’accès Internet (FAI). Votre hébergeur peut dénoncer le contrat qui vous lie et des poursuites peuvent être lancées à votre encontre.

Mon mot de passe est long donc tout va bien

FAUX : Un mot de passe, même long, est assez facile à casser s’il ne contient que des lettres. Tout particulièrement s’il est basé sur un mot du dictionnaire. Oui, même si vous utilisez brillamment le Leet Speak^^ (ex: remplacer un ‘o’ par un ‘0’, un ‘e’ par un ‘3’, etc.).

Un bon mot de passe est un mot de passe complexe, d’au moins 8 caractères, comportant une combinaison de tous les éléments suivants :

  • lettres en majuscules (A-Z)
  • lettres en minuscules (a-z)
  • chiffres (0-9)
  • caractères spéciaux (&”#{([-|`\_ç^à)]=}$£%*+!§/:;.?, …)

Et surtout, un bon mot de passe est un mot de passe qui change souvent (au minimum tous les 6 mois) et est un mot de passe à usage unique, c’est-à-dire que vous n’utilisez pas pour toutes vos applications (messagerie, applications SaaS, réseaux sociaux, etc.). Même si votre mot de passe est sûr et bien choisi, on ne peut pas toujours en dire autant des systèmes qui l’enregistrent. Il y a régulièrement des piratages de larges bases de données (le Playstore Sony, lastpass, ebay, paypal, evernote, etc.).

Mon site n’est pas encore lancé donc je ne peux pas me faire pirater

FAUX : Dès que votre site est accessible, il est possible pour un intrus de s’y connecter. Pire, comme il est encore dans sa configuration par défaut, l’attaquant possède des informations précieuses sur son état initial (puisque le CMS est open source), qui facilitent l’exploitation des failles de sécurité.

Les pirates disposent d’outils d’analyse automatisés qui leur permettent de détecter votre site même s’il n’est pas lancé. Google arrive même à indexer des sites en pré-production, alors qu’ils n’ont pas encore leur adresse URL définitive.

Si je me fais pirater, je vais le voir rapidement

FAUX : Votre site peut avoir été compromis depuis plusieurs semaines, sans que rien ne vous l’indique : ni contenu modifié, ni fuite d’information, ni baisse de performance.

Faux1

ET DOUBLE FAUX : Il est tout à fait possible que vous ne vous rendiez jamais compte de l’attaque, en particulier si la cible du piratage n’est pas directement votre site (défaçage), mais l’utilisation de vos ressources d’hébergement (DDoS, campagne de spams, minage de bitcoins, spoofing, insertion de pages supplémentaires cachées, etc.) ou la collecte d’informations (vol de numéros de cartes bancaires, collecte de mots de passe, etc.).

Il est fréquent que les pirates procèdent en plusieurs phases :

  • Une infection initiale exploite une faille du CMS et permet d’installer une porte dérobée sur votre site. Cette porte reste en sommeil pendant quelques semaines. De cette manière, le pirate dispose d’un point d’entrée sur votre serveur, même si la faille de sécurité qu’il a utilisée pour l’infecter est corrigée entre temps.
  • Lorsqu’il a besoin de lancer son action malicieuse (DDoS, spams, etc.), le pirate utilise sa porte dérobée pour installer son contenu actif.
  • L’action malicieuse est lancée, votre serveur est utilisé pour des actions illégales. Cette action peut être visible si elle vise votre site (défacement) ou si elle surconsomme des ressources. Mais elle peut aussi viser d’autre sites ou d’autres serveurs, ou simplement utiliser les ressources de votre serveur, sans déclencher d’alarme.
  • Si elle n’est pas détectée, l’exploitation de votre serveur peut s’arrêter. Les actions sont mises en sommeil, avant une nouvelle exploitation ultérieure.

Dans tous les cas, à moyen terme, votre site, voire votre entreprise, en fera les frais directement ou indirectement : atteinte à votre e-réputation, bannissement de votre nom de domaine, poursuites judiciaires, etc. Beau programme, hein ?

Si je me fais pirater, mon hébergeur me fera une restauration

FAUX : La restauration n’est pas forcément possible.

Il n’est parfois tout simplement pas possible de revenir à une version non infectée :

  • les données de votre site ont sans doute légitimement évolué depuis l’infection. Pour un site de commerce électronique, on ne peut pas perdre les 10 derniers jours de commandes, comptes clients, factures, etc. Pour un site de présentation, peut-on mettre à la poubelle le travail de votre webmaster des 10 derniers jours ?
  • l’infection est trop ancienne et les sauvegardes ne remontent pas assez loin (voir “Si je me fais pirater, je vais le voir rapidement”)
  • la sauvegarde fait partie d’un plan de reprise d’activité (PRA) ou d’un plan de continuité d’activité (PCA), dont le but est de répondre à une destruction de l’infrastructure de production. Sa mise en œuvre peut être compliquée, présenter des risques pour d’autres sites hébergés sur le même serveur. Elle n’est peut-être pas organisée pour remettre en place simplement quelques fichiers perdus au milieu d’un disque dur

Dans tous les cas, la restauration d’une version sauvegardée du site nécessite des interventions manuelles du personnel d’exploitation et seront donc facturées par votre hébergeur.

Quand je n’utilise plus un plugin, je le désactive

FAUX : Dans WordPress comme dans Magento, désactiver un plugin ne signifie pas que son code n’est plus utilisable. Cela indique juste que le CMS ne l’utilise pas à l’instant t. Mais comme le code source reste présent, il peut être appelé directement et ses failles peuvent donc être exploitées.

L’analyse des outils de piratage montre que les scanners recherchent des sources de plugins, dans des versions spécifiques vulnérables, même quand ils ne sont pas actifs sur le site et arrivent ensuite à les exploiter.

Je n’utilise que des plugins du dépôt officiel

FAUX : Quel que soit le code, il est toujours possible qu’il présente des failles de sécurité.

Il y a déjà eu par le passé des failles y compris dans le cœur de WordPress. WordPress est un CMS extrêmement sûr, car grâce à sa base installée très large, les failles sont très rapidement détectées et immédiatement corrigées. Il en va de même pour les principaux plugins.

Les pirates constituent des bases de données de versions des sites : ils analysent préalablement votre site pour déterminer sur quelle version du cœur WordPress il fonctionne et quels sont les plugins présents.

Lorsqu’une faille est découverte, ou rendue publique, les pirates savent donc immédiatement sur quels sites elle peut être exploitée. Ils disposent ainsi d’un avantage et peuvent être plus rapides à exploiter la faille que l’éditeur à la corriger.

Je mets à jour quand je peux

FAUX : Les mises à jour doivent être faites dès qu’elles sont disponibles, afin de minimiser les possibilités d’exploitation des failles par un pirate.

WordPress est un écosystème assez fiable. Il dispose d’une option qui permet la mise à jour automatique du cœur dès qu’un patch est publié. Cette option est suffisamment fiable pour être utilisée en production, sur les versions mineures (mises à jour). Pour les versions majeures (passer de la version 4.x à la version 5.y), il faut obligatoirement passer par l’agence car les changements peuvent être plus profonds et nécessitent une passe d’intégration et de recette complète des plug-ins.

RE-FAUX : Si une vulnérabilité est publiée sur un plugin et qu’aucun patch n’est livré, il faut désinstaller le plugin au plus vite.

Rappel: la désactivation ne suffit pas !

BONUS : Mon site est en HTTPS, donc je ne crains rien

FAUX : HTTPS chiffre uniquement la connexion entre l’internaute et le site.

Le protocole TLS, qui assure le chiffrement HTTPS, est une composante essentielle de la sécurité du web, mais qui protège votre client, et pas votre site.
Sa mise en oeuvre garantit que personne ne puisse écouter la conversation entre un visiteur et votre serveur. De cette façon, elle apporte une protection des informations qui sont échangées, comme des identifiants de connexion ou des informations de carte bancaire. En revanche, les éventuelles failles du CMS, elles, restent parfaitement exploitables, même avec TLS. Seule l’application des conseils ci-dessus peut vous prémunir contre les risques de piratage.

Sylvain

Vous pensez à d’autres idées reçues sur lesquelles il faudrait revenir ? 

*Source : W3Techs

La-qualité-une-responsabilité-collective
0 Commentaires
Répondre
Se joindre à la discussion ?
Vous êtes libre de contribuer !
Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

0 Commentaires
Répondre
Se joindre à la discussion ?
Vous êtes libre de contribuer !
Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *