WordPress, Drupal, Joomla, Typo3 sont des CMS (Content Management Systems) qui ont révolutionné le web en permettant de simplement publier du contenu …

A l’occasion de la publication de la version 2021 du référentiel des risques des applications web OWASP Top10, il nous a semblé judicieux de partager ce que l’audit, le développement, la maintenance applicative et la sécurisation de centaines de sites basés sur des CMS sur plus d’une décennie nous ont appris.

Une base sécurité généralement solide au moment du lancement du site

Les bases du code des principaux CMS sont maintenant solides et de nombreux outils permettent d’obtenir une configuration sécurisée lors du lancement du site :  application des mises à jour, durcissement des composants logiciels, réduction de la surface d’attaque, activation de fonctions de sécurité telle que 2FA, utilisation d’un certificat TLS/SSL…

Mais que se passe-t-il après ce fameux jour du lancement? Qu’en est-il pour le J+2 ? La sécurité est un processus , pas un produit. Comment gérer le cycle de vie de ces sites web d’un point de vue sécurité ?

Ces CMS, en raison de leur simplicité, n’exécutent souvent pas les tâches métiers les plus cruciales de l’entreprise : il sont néanmoins souvent utilisés pour leur devanture (site vitrine) ou même leur façade public (extranet client). 

Une gestion du cycle de vie sécurité des CMS largement inadaptée

Il est courant pour les entreprises de lancer des campagnes de test d’intrusion (pentest) tous les 3 ans. Or, c’est une démarche coûteuse et souvent inadaptée au vu de la vitesse d’évolution des CMS, à la fois en termes de composants et de contenu.

Pour les CMS, au regard de l’OWASP Top10, c’est la catégorie “Utilisation de composants obsolètes ou vulnérables” qui est la plus prégnante. Elle passe d’ailleurs de la 9e position en 2017 à la 6eme en 2021. Bien sûr les autres catégories (« Contrôle d’accès dysfonctionnel”, “Mauvaise configuration de sécurité », “Conception sans sécurité”..) concernent les CMS.

L’avènement des Content Delivery Networks (CDN) et de Let’s Encrypt a permis de rendre la catégorie “Erreurs de protection cryptographiques” relativement marginale. 

Au final, la mise à jour d’un CMS, de ses plugins ou la correction d’une fonctionnalité peut faire apparaître des régressions fonctionnelles : ce n’est donc pas une décision à prendre à la légère. Quid des plugins qui disparaissent faute de maintenance ?

Des analyses superficielles récurrentes permettent de prédire le niveau de sécurité 

Notre expérience nous montre que le résultat d’une analyse superficielle d’un site web est un bon prédictif de sa sécurité intrinsèque. Ces analyses devraient être menées mensuellement afin de réagir rapidement à la publication des failles issues du moteur et des modules du CMS, du langage de programmation sous-jacent (souvent PHP) ou encore du serveur Web. On peut par exemple citer les premières migration de PHP7.x vers PHP8.x et l’impact sur la gestion native du stockage et de la vérification des mots de passe, qui peut impliquer des changements significatifs.

Un des principes de la sécurité est de dire qu’elle est un processus et non apportée par un produit (souvent vu comme magique). Le fait que les développeurs – qu’ils soient internes ou externes, dans des agences par exemple – reçoivent régulièrement un rapport de sécurité les sensibilisent en profondeur : toute insuffisance sera détectée.

En contrepartie, ces rapports doivent être modérés par des professionnels de la sécurité web qui comprennent les enjeux métiers, le véritable impact des failles sans chercher à les exagérer, et sont capables de fournir des indications exploitables de remédiation pour les développeurs. Bref, un véritable partenariat entre les développeurs et la sécurité.

Une surveillance et une conservation des journaux d’événements souvent négligées

Dans la version 2021 de l’OWASP TOP10, la catégorie “Monitoring et Logging insuffisants” progresse de la 9e à la 8e place. Nous constatons généralement un manque de supervision malgré l’offre abondante d’agents embarqués ou de sites dédiés, et une gestion des traces configurée par défaut,  c’est-à-dire,  la plupart du temps, des événements pauvres en information et une rétention limitée à 7 jours.

Pourtant les CMS s’appuient des serveurs Web (Apache, Nginx la plupart du temps) riches en fonctionnalités, et l’export des logs vers un SIEM externalisé fait partie des bonnes pratiques : intégrité des traces, profondeur de stockage en cas de DDoS, capacité de recherche post-incident, coût optimisé du stockage…

Nous préconisons souvent l’activation de logs enrichies pour les pages dynamiques des CMS avec l’enregistrement natif (avec précaution) des variables envoyées par les visiteurs.

C’est notamment la façon d’identifier les attaques de type Injection (SQLi , “command injection”, XSS), la 3e catégorie du Top10, mais aussi leur résultat (fuite d’informations sensibles, exécution de commande à distance).

Qui doit apporter les corrections nécessaires ?

Pour ne citer qu’un exemple d’actualité : nous avons récemment détecté une faille de type Cross-Site Request Forgery (CSRF) sur un site WordPress. Annoncer aux développeurs qu’ils doivent configurer l’attribut SameSite du cookie d’authentification et implémenter un token anti-CSRF aurait probablement fait lever quelques sourcils… Il est préférable de montrer en référence les directives PHP pour ces 2 points (ici et là) et de pointer vers des solutions adaptées à ce CMS (1 et 2 pour la section “commentaires” par exemple).

A partir du moment où le code est partagé avec des équipes sécurité spécialistes du développement Web, les chaînes d’intégration et de déploiement (CI/CD) peuvent inclure de nombreux tests de sécurité du code qui seront  alors parfaitement exploités . Nous constatons cette tendance pour les entreprises les plus avancées qui s’appuient sur des offres cloud de type PaaS ou Serverless.

Nous pouvons même aller encore  plus loin : c’est l’équipe sécurité qui s’implique pour appliquer les mesures de correction (mitigation, mise à jour du CMS et de ses modules) et corriger le code qui serait en régression, contre refacturation aux métier afin de matérialiser le poids de la sécurité qui peut atteindre 25% du coût total d’un site web, là où souvent le choix d’un CMS est fait pour des raisons économiques.

Et si au final cela n’était pas une façon de parvenir à une tendance récente : « l’introduction de la sécurité dans les projets”.

Par Stéphane REYTAN, directeur de BlueTrusty