Les points d’entrée dans une application web
Concernant la méthodologie d’analyse de risques et modélisation de menaces (threat modeling) dans le cadre du développement logiciel proposée par Microsoft, une partie de la troisième phase consiste en l’identification des points d’entrées du système.
Quels sont les points d’entrée dont il faut tenir compte dans le cadre des applications web ?
Le point d’entrée
Le point d’entrée, ou ‘entry point’, représente un endroit tangible et localisable d’un système depuis son extérieur et permettant d’accéder à ses ressources intérieures.
L’analogie de la “maison” convenant particulièrement dans la majorité des concepts de sécurité, le point d’entrée consisterait ici en la porte d’entrée, la fenêtre ou encore le trou de la cheminée.
Le protocole HTTP
Les applications orientées web partagent un point commun: les clients et les serveurs communiquent entre eux par l’intermédiaire du protocole HTTP. En résumé, le protocole HTTP permet l’accès à des ressources au travers de requêtes simples (format texte) émises par un client (le navigateur par exemple) et adressées au serveur.
Le serveur obtient généralement les informations suivantes:
- La ressource demandée (url du document, paramètres utiles au document);
- La configuration dans les grandes lignes du client utilisé (type de navigateur, version de protocole);
- S’il s’agit d’une soumission d’informations explicite (un formulaire), la requête contiendra également une ou plusieurs associations de type ‘clé=valeur’
Le point d’entrée dans les applications standard
La phase 3 de la méthodologie d’analyse de risques et modélisation de menaces consiste en la décomposition du système analysé. L’on appliquera donc des “agrandissements” successifs sur l’application afin de décomposer ses différents composants de manière itérative. Au niveau 0, le système n’est pas encore décomposé et reste donc considéré dans son ensemble. Dans le cadre des applications standard, le point d’entrée est généralement unique: il s’agira de l’exécutable lui-même.
Il n’est par exemple pas possible de lancer un programme de traitement de texte et de se retrouver devant la boîte de dialogue “Enregistrer sous” sans effectuer de manipulation auparavant ou sans passer par le sempiternel double-clic sur l’exécutable.
L’analyste a donc un contrôle direct sur le point d’entrée et peut, s’il le souhaite, y placer des contrôles de sécurité, de performance ou par exemple de disponibilité (espace disque suffisant?) adéquats.
Le point d’entrée dans les applications web
Dans le monde des applications web, il est possible de demander n’importe quelle ressource dont l’adresse (l’URL) est préalablement connue sans forcément passer par une page précise. C’est d’ailleurs cette faculté qui a partiellement fait la force d’Internet: les liens hypertextes permettent d’accéder directement à une ressource spécifique d’une application web.
L’analyste ou le développeur n’ont donc plus ce contrôle direct sur le point d’entrée de l’utilisateur. Ce point se trouve à l’extérieur de l’application ainsi que le point de sortie: l’utilisateur peut quitter le site sans même prévenir l’application de son départ.
Par analogie, la maison serait entourée de fenêtres, de portes et de cheminées, dessus, dessous, de côté, devant et derrière et serait incapable de savoir lorsqu’un visiteur en sort ou y entre.
L’ évolution
Que faisons-nous lorsque nous devons surveiller un établissement de manière à avoir des yeux ‘partout’ sans pour autant user du don d’ubiquité ? Nous postons des gardes ou des caméras de surveillance à chaque porte, fenêtre et cheminée. Dans le cadre d’une application web, cette méthode se concrétise par l’utilisation d’inclusions (méthode ‘require’ en PHP ou ‘include’ en ASP par exemple): des ‘caméras’ en quelque sorte.
Mais cette solution présente néanmoins une grande faille: toute modification dans la structure de l’application exige d’être prise en compte par les ‘agents’ de surveillance. Si vous ajoutez une page, il ne faudra pas oublier d’y ajouter les inclusions correspondantes!
A l’échelle humaine, ce procédé présente les mêmes failles. Raison pour laquelle aujourd’hui l’on utilise de plus en plus des systèmes informatisés et centralisés: toutes les caméras fournissent leurs images dans un centre de contrôle, les lecteurs de badges sont tous reliés ou encore les agents de surveillance équipés par un micro et une oreillette.
Microsoft proposait une première version de cette cellule de surveillance grâce au fichier global.asa dans la technologie Active Server Pages grâce aux méthodes Application_Start, Application_Stop, Session_Start et Session_Stop, chacune des méthodes étant exécutée suite à un événement et non plus suite à une décision du développeur.
Dans le cadre de la technologie ASP.Net, la cellule de surveillance se voit dotée de nouveaux agents supplémentaires: Application_BeginRequest, Application_EndRequest, Application_Error et Application_AuthenticateRequest. Il est donc non seulement possible de réagir lors de toute forme “d’entrée” dans l’application mais aussi de prendre des décisions lors de chaque ‘déplacement’ effectué au sein de cette application.
De quoi se protège t’on ?
Parmi les nombreuses méthodologies d’attaque sur des application web figure l’isolation des scripts et inclusions. L’objectif de cette technique est d’identifier un maximum de scripts, pages, librairies ou simples inclusions directement accessibles au niveau de la requête. Dans le cadre d’une application ASP classique, il est fréquent d’avoir des pages portant l’extension .asp, composées de divers scripts métiers (connexion à la base de données, déconnexion de la base de données, module sélectionné, menu de navigation, etc.) accessibles de manière indépendante.
Dans le concret cela donnera des tentatives du genre:
http://www.example.ch/inc/inc_connexion.inc
http://www.example.ch/includes/inc_connexion.asp
http://www.example.ch/inc/connexion.asp
http://www.example.ch/includes/connexion.inc
http://www.example.ch/inc/inc_connexion.asp
http://www.example.ch/inc/dbconnect.asp
http://www.example.ch/inc/dbconnect.inc
…etc.
Vous l’aurez deviné, le but final n’est pas de ‘trouver’ des scripts invisibles mais de trouver LE script qui posera problème et divulguera de l’information sensible. Il pourra s’agir d’une erreur donnant des informations sur le type de base de données, sur la position physique dans le système de fichiers, sur des paramètres manquants et facilement manipulables et tout ce qui peut être imaginable.
Il s’agit ici d’un simple principe: que l’on passe par l’entrée des artistes ou par la grande porte, l’on se retrouvera sur la grande scène d’une manière ou d’une autre. Ce n’est qu’une question de secondes, minutes, ou heures…
Du côté de l’analyse…
La séparation du code dans les applications web est motivée principalement par deux facteurs:
- Il est plus facile de travailler à plusieurs sur le projet;
- La maintenance est facilitée dans la mesure où chaque script est clairement responsabilisé.
Dans un souci de sécurité, l’analyste peut rester dans l’optique d’une séparation en scripts et inclusions mais la conception devra découler d’une discipline sans faille sur la règle suivante:
- Toute ressource pouvant être demandée par l’intermédiaire d’une requête doit pouvoir être appelé de manière autonome sans pour autant mettre en danger l’application. Que ce soit en fournissant des informations critiques (erreurs) ou parce que le script voit son comportement modifié s’il n’est pas ‘entouré’ de ses pairs.
Du côté de l’audit…
L’auditeur va effectuer des tests selon un cahier de charges bien précis, préalablement défini et contractualisé avec le client. Bien entendu, il y aura quelque part une étape ressemblant à ceci:
Identité: Identification et recensement des scripts composant l’application
Démarche(s):
- Déclencher des erreurs en modifiant les paramètres, s’il y en a, dans les requêtes. Relever les noms de scripts concernés;
- Effectuer une recherche sur les modèles de nommage les plus fréquemment rencontrés. Relever les scripts trouvés;
- Sur la base des scripts recensés, relever si possible la méthode de nommage utilisée par le concepteur et effectuer un nouveau recensement. Relever les scripts éventuellement trouvés.
- Appeler chaque script recensé et noter les réponses obtenues
Résultat attendu minimal:
L’appel de scripts de manière indépendante ne déclenche pas d’erreurs et ne modifie par leur comportement respectif.
Résultat attendu bon:
L’appel de scripts de type ‘librairie’ ou ‘inclusion’ ne déclenche aucune erreur ou comportement inattendu.
Résultat optimal:
L’attaquant (ou l’utilisateur innocent) est automatiquement redirigé vers une page ‘complète’ s’il tente d’appeler un script de manière indépendante. De plus, une entrée est ajoutée dans le journal, spécifiant au minimum l’adresse IP du visiteur, la date et heure précises, la ressource demandée.
On notera ici que ces étapes de ‘recensement’ peuvent être tout à fait facultatives dans la mesure où l’auditeur a usuellement déjà accès au code source. Je conseillerais cependant d’effectuer cette phase de ‘découverte’ dans la mesure où elle fournira une information concrète sur la facilité éventuelle de pouvoir recenser les scripts d’un point de vue externe.
Ce qu’il faut retenir en un minimum de mots…
Contrairement aux applications dites ‘clients lourds’, lancées par un double-clic sur un exécutable, il est possible de ‘choisir’ son point de départ pour accéder à une applications web. Il suffit pour cela de connaître le nom d’une ressource placée dans la zone ‘publique’ de l’application.
Dans le cadre d’une conception orientée sécurité, il faudra donc s’assurer que chaque point d’entrée possible de l’application web puisse être directement appelé par un client sans pour autant déclencher d’erreurs, divulguer des informations sensibles ou encore se comporter de manière différente que celle initialement prévue.
Pour le premier recensement de scripts, l’on effectuera principalement les opérations suivantes:
- Le déclenchement d’erreurs au travers des paramètres ou formulaires pour obtenir des noms de scripts;
- La recherche de scripts au hasard;
- L’analyse des noms de scripts déjà recensés pour pouvoir en deviner d’autres.
La première liste obtenue sera complétée par la liste réelle des scripts identifiés dans le code source de l’application.
Pour tester leur indépendance, l’on recherchera principalement dans le code:
- Comment le script se comporte t’il s’il est appelé seul et sans arguments ?
- Si des arguments sont attendus ou acceptés, comment le script se protège t’il contre les modifications de ces paramètres ?
Pour aller plus loin: Improving Web Application Security, Chapter 3 - Threat modeling