Les vulnérabilités liées à l’habilitation sont des vulnérabilités qu’on croise très souvent. Dans ce chapitre, nous allons voir ensemble comment les détecter et les exploiter.
Comprenez la notion d'habilitation
Rappelez-vous : dans le chapitre précédent, on avait défini les termes "authentification" et "habilitation", pour que vous fassiez bien la différence. Dans ce chapitre, nous allons parler de la notion d'habilitation, donc je remets les définitions, pour rappel :
Testez le cloisonnement horizontal
On appelle cloisonnement horizontal le fait de vérifier qu’un utilisateur A ne peut pas accéder au périmètre d’un utilisateur B.
Par exemple, dans l'application example.com que nous testons, il s'agit de voir si un médecin (qui a ses propres patients) peut accéder aux dossiers des patients d'un autre médecin.
Autre exemple : dans une application bancaire, c’est le fait que vous, en tant qu’utilisateur, ne puissiez pas accéder aux comptes d’un autre utilisateur.
Pour vérifier qu’il y a bien un cloisonnement horizontal (ou son absence), il suffit de tester chaque requête avec les différents profils que vous avez à disposition. Vous pourrez donc voir si vous obtenez le résultat attendu : être “bloqué” quand vous n’avez pas le droit d’accéder aux données.
Il est relativement facile d’être exhaustif sur ce type de vulnérabilité, en boîte grise.
Si vous êtes en boîte grise, la méthode est la suivante :
Parcourez l’application avec chaque profil (infirmier, médecin, directeur, dans le cadre de notre application de e-santé).
Consolidez toutes les requêtes dans une liste.
Puis rejouez toutes les requêtes avec les différents profils en faisant varier les cookies de session si c’est le moyen utilisé pour la persistance de la session.
La boîte noire implique, avant ça, une étape supplémentaire d’identification (ou de guessing) des fonctionnalités auxquelles nous n’avons pas forcément accès avec les profils à notre disposition.
Les fonctionnalités qui sont particulièrement vulnérables sont celles qui appellent certains résultats par référence, par exemple :
http://example.com/patient/8976453
Dans l’application de notre client, pour des raisons de confidentialité, seul le médecin A doit avoir accès au dossier de ce patient via cette URL. Si le médecin B y a accès alors qu’il ne devrait pas, il y a rupture du cloisonnement horizontal entre les profils médecins !
Dans ce cas-là, la vulnérabilité porte même un nom précis : IDOR pour “Insecure Direct Object Reference”.
Testez le cloisonnement vertical
Le cloisonnement vertical suit le même principe que le cloisonnement horizontal, à une différence près : c’est le fait de chercher à voir si nous pouvons accéder à des fonctionnalités qui sont hors de notre périmètre utilisateur ou des données supplémentaires, potentiellement plus sensibles.
Par exemple, avec un profil “infirmier” ou “brancardier”, nous allons essayer de voir si nous accédons aux données normalement réservées aux médecins, voire aux administrateurs :
La méthode est donc strictement la même, et les deux peuvent se traiter en même temps.
Eh oui, ça compte comme une rupture de cloisonnement vertical puisqu’on accède à des fonctionnalités normalement restreintes, sans habilitation ni authentification !
Outillez-vous pour tester ces points efficacement
Le cloisonnement peut se tester manuellement :
en ouvrant différents navigateurs avec des onglets de navigation privée, par exemple ;
ou en rejouant une à une les requêtes dans le Burp Repeater, (mais avouez que ce n’est pas très pratique…).
Pour vous éviter cela, je vous conseille fortement d’utiliser le plugin Firefox PwnFox et l’extension Burp associée. Ils permettent de compartimenter les onglets dans Firefox – pour régler le problème d’avoir plusieurs navigateurs avec la navigation privée pour générer plusieurs cookies valides – et de mettre en surbrillance automatiquement dans Burp les requêtes en fonction des profils.
Allez, je vous montre !
En résumé
L’habilitation consiste à vérifier que quelqu’un a bien le droit de faire ce qu’il demande (comme utiliser une fonctionnalité en particulier).
Le cloisonnement horizontal désigne le cloisonnement entre deux utilisateurs de même niveau de privilèges, mais avec des périmètres différents. Par exemple deux médecins, mais avec des patients différents.
Le cloisonnement vertical désigne la séparation entre les différents niveaux de privilèges. Par exemple, un infirmier n'accède pas aux mêmes fonctions et données au sein d’un hôpital qu’un médecin, par exemple.
Il y a rupture de cloisonnement à partir du moment où le système laisse un profil accéder à des données en dehors de son périmètre défini, ou à des fonctionnalités qui ne sont normalement pas accessibles avec le niveau de privilèges du profil en question.
Nous en avons terminé avec les vulnérabilités techniques pour ce cours ! Dans le prochain chapitre, nous allons parler des autres points qu’on croise en audit, et qu’il est à mon sens nécessaire de remonter, car ils peuvent constituer un risque pour l’application, et donc intéresser le commanditaire.