Avant qu’un incident ne survienne

Votre site Joomla! a-t-il une extension vulnérable ? La check-list

Ce n’est pas la même question que « mon site a-t-il été piraté » : il s’agit là de signes de compromission active, un sujet que nous traitons séparément pour les sites Joomla! 3 dans notre check-list du site piraté. Celle-ci vient plus tôt et se pose plus discrètement : comment savoir, avant qu’un incident ne survienne, si l’une de vos extensions installées comporte une vulnérabilité divulguée qui traîne là, non corrigée ?

Les signes à vérifier manuellement dès aujourd’hui

  • Comparez la version de votre noyau Joomla à la dernière version disponible. Système → Mise à jour de Joomla signale les écarts de version, mais il signale toute nouvelle version disponible, pas spécifiquement un statut de vulnérabilité.
  • Vérifiez si le flux VEL de Joomla lui-même mentionne nommément l’une de vos extensions installées. Consultez la structure du flux avant de le parcourir manuellement.
  • Lisez le changelog de chaque extension à la recherche d’un vocabulaire lié à la sécurité. Des termes comme « correctif de sécurité », « XSS » ou « injection SQL », même sans CVE formel associé, méritent d’être examinés de plus près.
  • Repérez les extensions sans mise à jour depuis longtemps. Une extension inchangée depuis deux ans ou plus n’a pas forcément été réexaminée au regard des classes de vulnérabilités découvertes depuis.
  • Vérifiez dans Système → Extensions tout ce qui est installé mais jamais réellement utilisé. Une extension inutilisée continue d’exécuter du code et conserve toute vulnérabilité qu’elle comporte.

Pourquoi cette méthode manuelle atteint ses limites

Chacune de ces vérifications prend quelques minutes par extension. Un site Joomla typique fait tourner entre 20 et 50 extensions une fois les composants, plugins, modules et templates comptabilisés, et une agence gérant un portefeuille de sites clients multiplie encore ce chiffre. Une vérification manuelle, extension par extension, fonctionne bien pour un audit ponctuel. Elle ne fonctionne pas comme pratique continue, car personne ne répète réellement un contrôle manuel de 30 minutes chaque semaine sur des dizaines de sites, et une vulnérabilité divulguée dans une extension installée il y a six mois est tout aussi réelle qu’une vulnérabilité divulguée hier si personne ne l’a réexaminée depuis.

À quoi ressemble l’automatisation

C’est précisément cette lacune que Houston comble : il effectue automatiquement, chaque jour, les contrôles VEL et Security Centre décrits ci-dessus sur l’inventaire réellement installé, et n’envoie un e-mail que lorsqu’une découverte est véritablement nouvelle. Consultez comment le configurer pour ne plus avoir à le faire à la main. Si vous venez de WordPress, consultez la comparaison avec Wordfence et WPScan.

← Retour à Houston

Questions fréquentes

Le fait qu’une extension affiche zéro vulnérabilité dans VEL signifie-t-il qu’elle est sûre ?

Non. Cela signifie simplement que rien n’a encore été signalé, pas que rien n’existe. VEL est un registre des problèmes connus et divulgués, pas une garantie.

Que faire si une extension n’a tout simplement aucun changelog à consulter ?

C’est en soi révélateur. L’absence de changelog signifie généralement aussi l’absence de visibilité sur le traitement effectif des problèmes connus.

Combien de temps prend réellement la vérification manuelle d’un site ?

Quelques minutes par extension, donc une heure ou plus pour un site typique de 20 à 50 extensions, et cela doit être répété régulièrement pour rester à jour, pas fait une seule fois.

Faut-il quand même vérifier les extensions inutilisées et désactivées ?

Oui. Les fichiers d’une extension désactivée sont généralement toujours présents sur le serveur. Si elle est un jour réactivée, ou si son code reste accessible directement, toute vulnérabilité qu’elle comporte demeure bien réelle.