Ce défaut de sécurisation n'est pas dû à des failles dans les logiciels - c'est un autre problème - mais à des défauts de configuration qui permettent, pour peu que l'on connaisse la bonne URL, d'accéder à des contenus que les développeurs n'ont pas pensé à masquer, ignorant qu'ils étaient accessibles.

J'ai ainsi récemment découvert dans des sites que j'avais développés que je pouvais, en connaissant leur adresse, accéder à des contenus qui n'étaient pas censés être affichés. J'ai tenté l'expérience sur différents sites réalisés avec des CMS que je connais, et réalisé que ce travers était assez répandu. J'ai ainsi pu afficher des informations non destinées être publiques, par exemple des commentaires internes sur des articles, ou des références sur des fiches produits. Je n'ai pas voulu pousser l'expérience plus loin sur des sites en ligne, mais d'après mes tests sur des installations locales de certains logiciels, je pense qu'il est assez simple, si la configuration par défaut a été conservée, de se créer un compte (sans droits, heureusement) voire de créer des contenus en forgeant des requêtes POST.

Beaucoup de sites offrent donc plus de "fonctionnalités" que leurs créateurs ne le pensent. Ils permettent souvent à n'importe quel visiteur d'accéder à des informations qui n'avaient pas vocation à être publiques, et parfois bien plus encore.

La sécurité est rarement prise en compte lors du développement d'un site avec un logiciel de gestion de contenu. C'est souvent la troisième roue du vélo, pour de multiples raisons:

  • parce que les informations susceptibles d'être consultées de manière non prévue semblent rarement suffisamment cruciales pour que la sécurité soit explicitement mentionnée dans les cahiers des charges;
  • parce que les délais et les moyens mis à la disposition des équipes de développement sont généralement déjà trop serrés pour simplement réaliser les fonctionnalités demandées, alors la sécurisation du site...
  • parce que les développeurs web sont peut-être moins sensibilisés à ces thématiques que, par exemple, des administrateurs systèmes;
  • parce que ces problématiques sont rarement mises en avant dans les manuels des logiciels...
  • etc

Pourtant, ne pas protéger certains contenus peut poser de graves problèmes de respect de la vie privée. Exemple parmi d'autres, si les informations saisies dans le formulaire de contact sont traitées comme des contenus, il peut être possible de les afficher comme on affiche n'importe quel contenu du site. Quand on sait les informations parfois personnelles que les visiteurs saisissent parfois dans ces formulaires, le danger est réel.

Quelques exemples

Je reste volontairement flou, mais n'hésitez pas à transposer ces exemples dans les logiciels que vous pratiquez pour voir s'ils s'appliquent.

La première étape est de découvrir à quel logiciel on a affaire. C'est rarement compliqué, en étudiant le code source des pages, les urls d'accès à certaines fonctionnalités, ou en testant la réponse à certaines url. On peut ensuite essayer les URL d'accès à l'interface d'administration. On trouvera par exemple facilement les pages permettant de se connecter au back office ou d'enregistrer un nouvel utilisateur. Pour peu que cet enregistrement ne nécessite aucune validation d'un administrateur, il est parfois possible de se créer un compte sur un site où, cette possibilité n'étant pas prévue, elle n'a pas été correctement paramétrée.

L'obsession pour les zolies zurl a fait perdre de vue que par défaut, tous les CMS affichent les contenus avec des url facilement devinables et prédictibles. Les contenus ont souvent des identifiants qui ne nécessitent pas une longue consultation du marc au fond de la tasse pour être devinées: 1, 2, 3... Afficher tous les contenus d'un site, y compris bien sûr ceux vers lesquels il n'y a aucun lien dans le front office, ne demande souvent qu'une simple itération. Pire, lors de l'installation, les logiciels créent un certain nombre d'objets, généralement toujours avec les mêmes identifiants. Sur tel CMS, l'utilisateur disposant des plein pouvoirs aura l'id 0, sur tel autre ce sera le 5... Avec cette simple information, il est parfois possible d'afficher le profil de cet utilisateur, avec son nom, son mail, etc. Des données suffisantes pour tenter une attaque par ingéniérie sociale

Les squelettes sont souvent la partie la plus facilement modifiable d'un CMS. On a donc régulièrement tendance à y coder une partie de la logique métier, des contrôles d'accès, des restrictions d'affichages, etc. Mais certains gestionnaires de contenus permettent de sélectionner le thème ou le squelette utilisé pour afficher un contenu, simplement en passant des paramètres dans l'URL. Il est ainsi facile d'afficher un contenu avec un squelette par défaut, vierge de tout contrôle et qui liste généralement l'ensemble des informations de l'objet, y compris celles qui ne devraient pas être affichées.

Tout cela est bien sûr connu depuis des années. Mais malheureusement rien ne semble vraiment changer, alors qu'aujourd'hui l'immense majorité des sites sont dynamiques, et donc susceptibles de présenter ces défauts.

Que faire ?

Les solutions à ces problèmes sont multiples, humaines comme techniques.

Techniquement, une réflexion constante sur la sécurité à toutes les étapes de la conception et du développement des CMS et des sites réalisés avec, devrait permettre de corriger les pièges les plus évidents pour les développeurs novices. Par exemple, il serait grand temps que les concepteurs de CMS remplacent les entiers par des UUID pour identifier les contenus. Cela réglerait la plupart des problèmes évoqués ci-dessus. Des solutions pour décourager les tentatives d'intrusion pourraient être proposées, comme par exemple l'activation d'un bannissement temporaire, sur le principe de fail2ban: bloquer pour quelques minutes les IP des internautes qui multiplient les 404.

Au niveau des développeurs de CMS, un effort serait vraiment à faire pour mieux documenter les paramètres ayant trait à la sécurité.

Sur le plan humain, augmenté la sécurité des sites réalisés passe bien sûr par la formation des développeurs, c'est à dire, pour celles et ceux qui sont salariés, obtenir de votre employeur de vrais formations[1], tant sur les produits utilisés que sur des considérations plus générales comme la sécurité. Tout le monde y gagnerait.

Mais cela peut aussi passer par la mise en commun de bonnes pratiques. En écrivant ce billet, j'ai cherché sur le web des ressources sur la sécurité des CMS. Si la plupart des logiciels y consacrent quelques paragraphes de leur documentation, et si on trouve de-ci, de-là quelques articles sur le sujet, je n'ai pas vraiment trouvé de centre de ressources sur le sujet. Vous en connaissez ? Ou est-ce que ça reste à créer ? Qui est partant pour ouvrir un wiki où collectiviser les expériences, les bonnes pratiques et les conseils pour améliorer la sécurité des sites que nous développons avec eZ Publish, Drupal, Spip et les autres ? Ne répondez pas tous en même temps ;-)

Notes

[1] profitons-en, c'est encore pour peu de temps un droit