Chapitre 11.3 — Plugins tiers & mises à jour

⏱️ TL;DR — La surface d’attaque n°1 d’un Moodle n’est pas son cœur (mûr, audité, corrigé régulièrement) mais les plugins tiers et les instances non mises à jour. Chaque plugin installé est du code tiers qui s’exécute avec les droits de Moodle et peut, s’il est mal codé, introduire SQLi, XSS, CSRF ou contournement d’accès (chapitres 11.1-11.2). Et une instance en retard de mises à jour reste vulnérable à des failles connues et publiées (donc facilement exploitées). Les règles : installer le minimum de plugins, depuis des sources fiables, les auditer (utilisent-ils les API sûres ?), mettre à jour Moodle et les plugins rapidement, et suivre les avis de sécurité. C’est la Partie 12 (supply chain) appliquée à Moodle.

🎯 Objectifs

Comprendre pourquoi plugins tiers et retards de MAJ sont le risque n°1 d’un Moodle.
Évaluer un plugin avant installation (source, maintenance, usage des API sûres).
Mettre en place une politique de mises à jour rapides (cœur + plugins).
Suivre les avis de sécurité et réduire la surface (moindre plugin).

Le plugin : du code tiers avec les pleins pouvoirs

Un plugin Moodle (module d’activité, bloc, thème, extension) est du code PHP qui s’exécute dans Moodle, avec ses droits : accès à la base via $DB, aux fichiers, aux données de tous les utilisateurs. Un plugin mal codé ou malveillant peut donc :

Introduire une SQLi (SQL concaténé au lieu de $DB paramétré — chapitre 11.2).
Introduire un XSS stocké (echo brut de données affichées à d’autres).
Oublier require_capability/sesskey → contournement d’accès et CSRF (chapitres 11.1-11.2).
Exfiltrer ou corrompre des données d’apprenants.

Autrement dit : la sécurité de ton Moodle est celle de son plugin le plus faible. C’est exactement la logique de supply chain (Partie 12), transposée à Moodle : chaque dépendance ajoutée est une surface de plus.

⚠️ Piège — Installer un plugin « parce qu’il fait ce dont on a besoin » sans évaluer sa qualité de sécurité est un pari risqué. Un plugin abandonné (plus mis à jour), peu téléchargé, ou provenant d’une source non officielle (un .zip trouvé sur un forum) peut contenir des failles — voire du code malveillant. Chaque plugin s’exécute avec les pleins droits de Moodle : un seul mauvais plugin compromet toute la plateforme et ses données d’apprenants. Le confort d’une fonctionnalité ne justifie pas d’ouvrir une porte non vérifiée.

Évaluer un plugin avant de l’installer

Avant d’ajouter un plugin, quelques vérifications (allow-list mentale) :

Source fiable : privilégier le répertoire officiel des plugins Moodle (plugins soumis à une revue) plutôt qu’un ZIP tiers. Vérifier l’éditeur.
Maintenance active : mises à jour récentes, compatibilité avec ta version de Moodle, réactivité aux issues. Un plugin abandonné ne recevra pas les correctifs de sécurité.
Popularité / adoption : un plugin très utilisé a plus de chances d’avoir été examiné (et ses failles remontées).
Qualité du code (si tu peux jeter un œil) : utilise-t-il les API sûres ? Cherche des red flags : SQL concaténé, echo brut, PARAM_RAW, absence de require_capability/require_sesskey sur les actions. Un plugin qui ignore ces API est à écarter.
Permissions demandées : quelles capabilities déclare-t-il, avec quels défauts ?

Le principe transversal du cours s’applique : moindre plugin. Chaque plugin non essentiel qu’on n’installe pas est une surface d’attaque en moins. On désinstalle les plugins inutilisés.

Mettre à jour : le cœur ET les plugins

Une faille de sécurité corrigée dans une nouvelle version est aussi une faille publiée : dès qu’un correctif sort, les détails de la vulnérabilité deviennent (tôt ou tard) publics, et les attaquants scannent les instances non patchées. Une instance en retard est donc une cible d’autant plus facile que la faille est connue et documentée.

Mettre à jour Moodle (le cœur) régulièrement, et rapidement pour les mises à jour de sécurité. Suivre les releases et les avis de sécurité officiels de Moodle.
Mettre à jour les plugins aussi — ils ont leurs propres failles et correctifs. Un cœur à jour avec des plugins obsolètes reste vulnérable.
Tester les mises à jour sur un environnement de préproduction (une MAJ peut casser), mais ne pas les repousser indéfiniment : le risque d’une faille non patchée dépasse vite celui d’une régression.
Sauvegarder avant de mettre à jour (base + fichiers — lien Serveur Linux et Partie 15).

💡 Réflexe — Traite les mises à jour de sécurité de Moodle et de ses plugins comme urgentes, pas optionnelles. Une faille corrigée est une faille connue : le délai entre la publication du correctif et l’exploitation de masse est court. Abonne-toi aux avis de sécurité Moodle, planifie des fenêtres de mise à jour, et garde un inventaire des plugins installés (avec leur version) pour savoir ce qui doit être patché. C’est la Partie 12 (surveiller et corriger les dépendances vulnérables) appliquée à Moodle.

🎯 Côté attaquant — Contre un Moodle, l’attaquant procède souvent ainsi : identifier la version (indices dans les pages, fichiers connus) et chercher si elle est vulnérable à une faille publiée (les avis de sécurité décrivent précisément quoi exploiter sur les versions non patchées) ; énumérer les plugins installés et leurs versions, à la recherche d’un plugin vulnérable ou abandonné ; et exploiter les plugins mal codés (SQLi/XSS/accès, chapitres 11.1-11.2). Une instance à jour avec peu de plugins de confiance lui offre peu de prise ; une instance en retard truffée de plugins est un festin.

🧭 Sur FormaCampus — FormaCampus applique une politique stricte à son Moodle : peu de plugins, tous issus du répertoire officiel et activement maintenus ; chaque nouveau plugin est évalué (source, maintenance, usage des API sûres — chapitres 11.1-11.2) avant installation, et les plugins inutilisés sont désinstallés. Les mises à jour de sécurité (cœur et plugins) sont appliquées rapidement après test en préprod, précédées d’une sauvegarde (base + moodledata). L’équipe suit les avis de sécurité Moodle et tient un inventaire des versions. Sur une plateforme qui héberge des données d’apprenants, une faille connue non patchée serait une négligence directement sanctionnable (RGPD — chapitre 11.4).

✏️ Exercices

Exercice 1 — Évalue le plugin. Un collègue veut installer un plugin téléchargé sous forme de .zip sur un forum, dont la dernière mise à jour date de plusieurs versions majeures de Moodle en arrière. Quels risques, et que recommandes-tu ?

✅ Solution

Risques : (1) source non vérifiée (ZIP d’un forum, pas le répertoire officiel) — le code n’a pas été soumis à revue, il pourrait contenir des failles ou du code malveillant, s’exécutant avec les pleins droits de Moodle ; (2) abandonné/incompatible (pas mis à jour depuis plusieurs versions majeures) — il ne recevra pas les correctifs de sécurité et peut mal fonctionner ou être vulnérable sur la version actuelle. Recommandations : ne pas installer en l’état. Chercher une alternative maintenue dans le répertoire officiel ; si la fonctionnalité est indispensable et qu’aucune alternative n’existe, auditer le code (utilise-t-il $DB paramétré, require_capability, sesskey, échappement de sortie ?) sur un environnement isolé avant toute décision — et idéalement s’en passer (moindre plugin). Le confort ne justifie pas d’exécuter du code tiers non vérifié sur une plateforme de données d’apprenants.

Exercice 2 — Le retard de MAJ. Pourquoi une faille corrigée dans la dernière version de Moodle rend-elle une instance non mise à jour particulièrement exposée ?

✅ Solution

Parce qu’un correctif de sécurité publie, de fait, l’existence et souvent les détails de la vulnérabilité : les avis de sécurité décrivent ce qui est corrigé, et l’analyse du correctif (le diff) révèle comment exploiter les versions non patchées. Les attaquants scannent activement Internet à la recherche d’instances restées sur les anciennes versions, avec un exploit désormais connu. Le délai entre la sortie du correctif et l’exploitation de masse est court. Une instance non mise à jour est donc une cible facile et documentée — d’où l’urgence d’appliquer les mises à jour de sécurité rapidement (après sauvegarde et test en préprod).

🧠 Quiz de révision

1. Pourquoi les plugins tiers sont-ils la surface d’attaque n°1 d’un Moodle ?

Parce que chaque plugin est du code tiers exécuté avec les pleins droits de Moodle (base, fichiers, données de tous). Un plugin mal codé introduit SQLi, XSS, CSRF ou contournement d’accès. La sécurité de l’instance est celle de son plugin le plus faible — c’est la supply chain (Partie 12) appliquée à Moodle.

2. Quels critères évaluer avant d’installer un plugin ?

Source fiable (répertoire officiel), maintenance active (MAJ récentes, compatibilité), adoption (examiné par la communauté), qualité du code (utilise-t-il les API sûres : $DB paramétré, require_capability, sesskey, échappement ?), et les permissions demandées. Principe : moindre plugin.

3. Pourquoi une instance non mise à jour est-elle si exposée ?

Parce qu’une faille corrigée est une faille publiée : les avis de sécurité et l’analyse du correctif révèlent comment exploiter les versions non patchées, et les attaquants scannent les instances en retard. L’exploit est connu et documenté → cible facile.

4. Faut-il mettre à jour seulement le cœur de Moodle ?

Non : les plugins ont aussi leurs failles et correctifs. Un cœur à jour avec des plugins obsolètes reste vulnérable. On met à jour cœur ET plugins, rapidement pour la sécurité, après sauvegarde et test en préprod.

5. Quelle règle transversale du cours s’applique aux plugins ?

Le moindre plugin (réduction de la surface d’attaque, Partie 1) : installer le minimum de plugins nécessaires, depuis des sources fiables, et désinstaller les inutilisés. Chaque plugin non installé est une surface d’attaque en moins.

Chapitre suivant : Durcir config.php & données — sécuriser la configuration, les fichiers et les données d’apprenants d’une instance Moodle (avec le lien RGPD).