Les sites communautaires se qualifient par leur contenu géré par plusieurs utilisateurs distincts. Dans la majeure partie de ces sites, la notion de propriété y est fortement représentée, l’on verra presque dans tous les cas que tout contenu est rattaché à un utilisateur.
La non-application du principe de défense en profondeur sur certaines opérations de ce type de sites peut placer toute la structure dans un niveau de sécurité critique. Je vous propose ici une petite étude de cas mettant le doigt là où ça fait mal, à savoir, les risques encourus suite au non-respect de ce principe sur un site communautaire…
Les sites de gestion de contenu
Les sites de gestion de contenu se qualifient par leur contenu géré par plusieurs utilisateurs distincts.
Dans la majeure partie de ces sites, la notion de propriété y est fortement représentée, l’on verra presque dans tous les cas que tout contenu est rattaché à un utilisateur.
La gestion d’un contenu regroupe usuellement les opérations suivantes :
- créer un contenu
- modifier ce contenu
- supprimer ce contenu
- modifier l’état de ce contenu (approuver, refuser, publier, etc.)
Presque tout portail communautaire entre également sous la coupole de la ‘gestion de contenu’ telle qu’elle est définie dans cet article. Les risques présentés ici s’y appliquent donc également.
Le principe de défense en profondeur
Le principe de défense en profondeur a été décrit dans un précédent article, je ne m’y attarde donc pas ici. Juste une petite phrase résumant la chose:
« La défense en profondeur consiste à ne pas faire
confiance aux mesures de sécurité prises à des couches
supérieures ou adjacentes. »
L’étude de cas: ToutesLesAnnonces.com
ToutesLesAnnonces.com est une plate-forme gratuite de publication de petites annonces. Une seule instance de l’application est installée et elle est capable de gérer l’ensemble des annonces actives sur le serveur.
Il est possible à tout internaute de s’enregistrer sur le site, puis de créer ses propres petites annonces.
Le site permet plusieurs opérations de base sur les petites annonces :
- créer une annonce
- publier une annonce
- modifier une annonce
- supprimer une annonce
La conception du site permet, au travers d’une zone membres, de gérer les petites annonces dont l’utilisateur est le propriétaire.
Le flux suivant s’applique à la modification d’une petite annonce :
- afficher la liste des annonces crées par soi-même
- sélectionner une annonce
- cliquer sur ‘modifier’
- modifier le texte de l’annonce puis cliquer sur ‘confirmer’
Un développeur n’appliquant pas la défense en profondeur réalisera le pseudo-code suivant :
—listeannonces.php—
sql = " SELECT * FROM annonces WHERE proprietaire = $idProprietaire ";
//affichage des annonces dont il est propriétaire
—modifierannonce.asp—
annID = Request.Form("id")
annTexte = Request.Form("corps")
sql = " UPDATE annonces " & _
" SET texte = '" & annTexte & "'" & _
" WHERE id = " & annID
‘* modification de l’annonce
Vous saisissez où se trouve le problème ?
Le second script, modifierannonce.asp, part du principe que l’utilisateur a demandé la suppression d’une annonce lui appartenant. Où est la garantie ?
Voici ce que le script devrait faire si le développeur applique la défense en profondeur :
—modifierannonce.asp—
annID = Request.Form("id")
annTexte = Request.Form("corps")
sql = "UPDATE annonces " & _
" SET texte = '" & annTexte & "'" & _
" WHERE id = " & annID & _
" AND proprietaire = " & idProprietaire
'* modification de l’annonce
Comme vous pouvez le remarquer, la requête a été modifiée afin d’empêcher la modification d’une annonce par une autre personne que son propriétaire.
Cette modification n’a pas demandé un effort conséquent mais apporte néanmoins un avantage non négligeable en matière de sécurité de l’application : il n’est plus possible de modifier le contenu d’un autre propriétaire, sans réussir à déjouer le mécanisme d’authentification.
Conclusion
Cet exemple peut quelque peu paraître sommaire au premier abord. Je peux néanmoins confirmer qu’au moins quatre sites considérés comme ‘majeurs’ dans la région Suisse-France sont en cet instant précis vulnérables à ce genre de faille, et ceci dans les catégories suivantes :
- portail de rencontres et contacts en ligne
- portail de petites annonces
- service de “bureau virtuel”
- forums de discussions sur des sites journalistiques
Sur le trigramme CIA (cf article principes fondamentaux de sécurité) nous sommes ici dans une situation de violation d’intégrité. Si j’applique les risques associés à cet axe de sécurité aux quatre catégories de sites ci-dessus :
- modification et suppression de profils
- divulgation de propos personnels, ou à caractère illégal
- mise à défaut de profils de personnes
- modification de conditions d’acceptation des autres contenus afin de revaloriser son propre contenu
- déformation des données
- usurpation d’idées (faire croire que le contenu est l’expression des idées d’une tierce personne)
- détournement de flux (redirection automatique sur un contenu souhaité)
- autres risques …
Alors, messieurs les développeurs ou messieurs les responsables de la sécurité, peut être serait-il temps de vous fixer quelques objectifs pour la semaine à venir ! ; )