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

La gestion du Workplace Digital est l’une des tâches les plus difficiles à effectuer dans l’IT, car il est difficile de disposer d’une vue exhaustive et claire sur les environnements des postes de travail utilisateurs. Cette mauvaise visibilité est une préoccupation croissante pour ceux qui comprennent que l’informatique a un impact réel sur la productivité d’une entreprise. Dans ce contexte, l’analyse de l’expérience devient un enjeu stratégique qu’il convient de traiter facilement et efficacement.

Industrialiser la démarche d’analyse de l’expérience utilisateur

Dans cette démarche, le recours au numérique est fondamental. Son objectif consiste d’ailleurs à s’appuyer sur un outil efficace, capable d’analyser l’intégralité du niveau d’information de l’entreprise et de connaitre en temps réel les performances et les services rendus aux utilisateurs. C’est uniquement de cette manière que les DSI peuvent gérer efficacement des systèmes informatiques souvent complexes, surmonter leurs problèmes de sécurité et de gestion, élargir l’éventail d’applications intégrées à l’espace de travail, partager de manière sécurisée les fichiers et données sur n’importe quel appareil et offrir une expérience fluide au travers d’un dispositif unique.

Des bénéfices concrets rapidement et à plusieurs niveaux 

La gestion proactive du SI : grâce à des recommandations priorisées pour guider les équipes IT dans l’amélioration de l’expérience utilisateur à l’échelle de toute l’organisation. Les exemples d’actions sont nombreux, il est possible d’œuvrer efficacement sur le nombre d’heures de productivité par utilisateur, la réduction de tickets support, la diminution du temps d’intervention des équipes support, la baisse des coûts, l’identification des utilisateurs ayant des problèmes de performances avec des navigateurs ou outils…

La réduction des coûts informatiques et l’optimisation des investissements en matériels et logiciels : une application d’analyse de l’expérience utilisateur peut s’intégrer de manière transparente avec des sources de données externes permettant de bénéficier d’une véritable interface unique de reporting et de gestion. 

Une sécurité accrue grâce à des dispositifs d’analyse approfondie : c’est ainsi que le service informatique peut être averti en cas de conditions défavorables et résoudre facilement les problèmes. 

Une amélioration de la conformité et de l’audit grâce à la réalisation de tâches complexes telles que : l’audit utilisateur, la mesure de performance, l’analyse des temps de réponse, l’analyse des ressources applicatives, etc.

Au final, une bonne analyse de l’expérience utilisateur permet de mieux comprendre son environnement de travail, de connaitre la santé de son organisation en surveillant et en analysant les interactions des utilisateurs finaux au sein de celle-ci. Il est alors possible d’adapter le système d’information et ses coûts aux besoins des utilisateurs finaux et de résoudre les problèmes informatiques affectant la productivité. Une telle démarche est donc l’assurance de maximiser les bénéfices liés à sa transformation numérique et de s’assurer que les actions mises en place impactent positivement le confort de travail et la productivité des collaborateurs.

Par Xavier Le Dily – Technical Leader chez Cegedim Outsourcing