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 ! ; )
Le principe de défense en profondeur est l’un de mes préférés. Pourquoi ? C’est le plus facile à oublier, et le plus vicieux à attaquer dans le cadre des services orientés web. Ce bulletin n’est publié qu’à titre formel, afin de définir le principe. Je traiterai de ce principe dans diverses études de cas prochainement publiées.
Voici une phrase très réductrice sur le principe de défense en profondeur mais résumant à elle seule toute l’idée :
« La défense en profondeur consiste à ne pas faire
confiance aux mesures de sécurité prises à des couches
supérieures ou adjacentes. »
Le principe des couches de sécurité est assez intuitif mais doit être tout de même formalisé dans ce document, vu que d’autres principes se basent eux-mêmes sur celui-ci.
« L’accès a toute couche du système implique le
passage par la couche supérieure à cette couche. »
Un exemple
Pour accéder à son contenu, un intranet d’entreprise exige que tout utilisateur soit correctement authentifié. Nous pourrions résumer ce besoin en deux couches :
Couche 1 : authentification utilisateur
Couche 0 : accès au contenu
Le principe des couches de sécurité exige que pour accéder à la couche 0 (le centre), il faille préalablement avoir passé les conditions émises par la couche 1.
SI l’autorisation est accordée par la couche 1
ALORS exécuter l’opération de la couche 0
SINON refuser l’accès à la couche 0
Chaque technologie de développement web propose ses propres mécanismes d’implémentation de couches, virtuelles ou réelles.
L’on pourra utiliser les directives d’inclusions en technologie ASP classique ou les commandes ‘include’ en technologie PHP. Dans ces cas, il s’agira de couches virtuelles dans la mesure où il n’y a pas ‘logiquement’ parlant d’accès sur une couche inférieure mais accès à ‘la suite’ du code :
—index.php—
< ?php include("inc_checkauth.php"); ?>
< ?php
//afficher contenu
?>
D’autres technologie telles que ASP.Net proposent des couches réelles par exemple avec la méthode Application_BeginRequest() du fichier Global.asax. Cette méthode est exécutée avant d’appeler la page demandée. Le document lui-même n’inclut donc aucun code pouvant permettre de détecter qu’un module d’authentification est appliqué avant son appel.
Dans la mesure du possible, il sera souhaitable de toujours privilégier l’utilisation de couches réelles plutôt que virtuelles.
La sécurité informatique repose sur plusieurs fondements. Ci-dessous, je vous propose d’approcher les sept fondements qui nous concerneront le plus dans le cadre des prochains articles publiés sur ce blog.
Cette liste n’est bien entendu pas exhaustive et n’est pas encore standardisée (à moins que j'aie mal cherché l'info?). Elle peut donc varier selon la personne à qui vous vous adressez.
Quoi qu’il en soit, elle constitue MA liste de base, nerf de guerre sur lequel s’articuleront tous les articles liés à la sécurité. Il y aura d’autres principes traités, tels que la défense en profondeur, l’obscurité, la confiance ou encore retomber sur ses pattes. Mais ceux-ci seront pour plus tard!
Triade CIA
La triade CIA regroupe trois principes essentiels au maintien de la sécurité d’un système d’information.
Les trois principes sont respectivement: la confidentialité (Confidentiality), l’intégrité (Integrity) et la disponibilité (Availability) des informations.
Certaines nouvelles formations dans la sécurité informatique proposent un quatrième principe (CIAA): l’authentification (Authentication).
Principe de confidentialité
Alice envoie un message à Bob. Qu’est-ce qui garantit à Alice que personne d’autre que Bob n’a pu ou ne pourra consulter le message ?
La confidentialité regroupe tous les mécanismes permettant d’assurer qu’une information ne pourrait être accessible et exploitable que par les personnes autorisées.
La confidentialité regroupe tous les mécanismes permettant d’assurer qu’une information ne pourrait être accessible et exploitable que par les personnes autorisées.
Ce principe peut être considéré de manière autonome, par exemple lorsque l’on traite de cryptographie sur un système de fichiers, ou de manière combinée, au principe d’authentification.
Intégrité
Alice envoie un message à Bob. Qu’est-ce qui garantit à Bob que ce message n’a pas été modifié durant son acheminement ?
Le principe d’intégrité vise à assurer qu’une donnée soit ‘réelle’. Cette donnée est censée représenter l’état d’une entité, d’un système ou même d’une pensée ou idée, à un instant donné.
Les contrôles d’intégrité visent à garantir qu’une donnée est représentative d’un certain modèle et qu’elle n’a pas subi de modification ou même détérioration entre deux contrôles.
Disponibilité
Alice envoie un message à Bob. Qu’est-ce qui garantit à Alice que Bob pourra consulter ce message dans les délais prévus ?
Le principe de disponibilité vise à fournir les données ou les informations lorsque les utilisateurs en ont besoin.
En clair : la disponibilité regroupe toutes les mesures visant à permettre à un service d’assurer ses responsabilités sans interruption ou du moins, lorsqu’il doit être disponible.
Authentification
Bob souhaite récupérer le message d’Alice. Comment peut-il prouver qu’il est bel et bien Bob ?
L’authentification consiste à s’assurer qu’un utilisateur est celui qu’il prétend être.
Le principe d’authentification se décline en un sous-principe : l’identification.
L’identification consiste à identifier un utilisateur de manière unique.
Quelques exemples pour différencier l’identification de l’authentification :
Système d’authentification ‘mot de passe’ : vous insérez votre carte bancaire dans un distributeur de billets. La carte sert à identifier le client (et ses comptes) sur lequel le distributeur va effectuer les opérations. Le NIP (Numéro d’Identification Personnel) vous permet de vous authentifier au distributeur : vous lui prouvez que vous êtes bel et bien le titulaire de la carte.
Système d’authentification ‘passeport’ : votre carte d’identité porte votre nom. Elle vous identifie au sein du fichier de la population d’un pays. Sur votre carte d’identité se trouve votre photo. Lorsque vous montrez votre carte d’identité à un douanier, il vous identifie par votre nom et vous authentifie par deux facteurs : le fait que vous possédiez cette carte et par le fait que vous soyez la personne représentée sur la photo.
Autorisation
Anita désire envoyer un message à Bob. A t’elle le droit de le faire ?
L’autorisation (ou permission) consiste à pouvoir déterminer si une opération est autorisée ou non.
Le mécanisme d’autorisation doit normalement être en mesure de répondre aux questions suivantes :
- quel acteur désire effectuer une opération ?
- quelle opération souhaite t’il effectuer ?
- a t’il le droit d’effectuer cette opération ? oui, ou non.
Non-répudiation
Bob a reçu un message d’Alice. Alice prétend qu’elle ne l’a pas envoyé. Qui a raison ?
Le principe de non-répudiation regroupe les mesures permettant d’affirmer avec certitude quel est ou quels sont les auteurs d’une opération.
Très utilisé dans le domaine financier, les mesures de non-répudiation permettent par exemple d’empêcher que des investisseurs ne disent “ce n’est pas moi qui ai acheté ça, on s’est fait passer pour moi!” après que leur action n’ait chuté…
Audit - journalisation
Alice a envoyé un message à Bob le 8 février 2004 à 8 heures 34 minutes et 27 secondes. Bob a consulté ce message 4 minutes plus tard, à savoir, le 8 février 2004 à 8 heures 38 minutes et 31 secondes précises.
QUI a fait QUOI et QUAND ?
La journalisation permet de répondre à cette question, et souvent bien d’autres !
Les mécanismes de journalisation regroupent toutes les techniques permettant de récupérer et stocker les informations d’activité de manière exploitable.
L’audit entre en compte dans les mécanismes de non-répudiation (ne pas pouvoir nier que l’on a fait quelque chose): « ça a eu lieu, c’est même écrit ici » ou encore lors d’analyses statistiques par exemple : « Combien de personnes ont demandé telle ressource durant les premières heures après le passage à la nouvelle année ? ».
Ce qu’il faut retenir ici…
Un système ou application considéré comme “sécurisé” doit au minimum pouvoir fournir les services suivants :
- Empêcher la consultation de données par des acteurs à qui elles ne sont pas destinées;
- Conserver et fournir les données dans l’état où elles ont été laissées par leur propriétaire;
- Fournir les données lorsque les acteurs en ont besoin ;
- Identifier et authentifier les acteurs agissant sur le système;
- Décider si oui ou non une opération est autorisée à un acteur;
- Savoir QUAND a été effectuée une opération et par QUI de manière certaine
Build complete – 0 errors, 948 warnings
Building satellite assemblies…
Voci la réponse. Un projet initialement prévu pour n’être utilisé qu’en interne, dans un langage qu’aucun autre collaborateur que moi ne comprend, et qui ne serait jamais vendu est depuis peu devenu un projet développé en équipe, par des collaborateurs comprenant le langage et qui va être vendu à un client.
Le message ci-dessus est la réponse de Visual Studio à ce changement soudain de direction: 948 entrées de documentations à saisir dans les jours à venir pour se débarrasser de ces messages intrusifs!
Moralité: dans vos propriétés de projet Visual Studio, entrez un nom de fichier dans la case ‘XML Documentation File’. Cela vous forcera dès le début à rentrer dans les rangs des développeurs orientés qualité et qui documentent tout leur code 
Si vous avez déjà un projet en cours, essayez, vous verrez, c’est jouissif.