L’étude empirique a montré que les exploitations des défauts logiques différaient d’un contexte à l’autre. Ce changement de contexte rend difficile le test et la détec- tion automatique des défauts logiques. Cependant, à partir des résultats de l’étude empirique, nous disposons d’une base de connaissance nous permettant de construire une ontologie du parcours d’authentification. Cette ontologie définit les relations qui existent entre les composants du parcours d’authentification, les classes de défauts logiques et les exploitations logiques.
Il est important de rappeler que nous nous focalisons sur les défauts logiques dus aux choix de conception et non aux erreurs de codage. Un défaut logique est spéci- fique au développement quand celui-ci est causé par une erreur ou une insuffisance dans l’implémentation du programme de l’application. Ainsi, le défaut disparaît avec la correction du programme. C’est l’exemple des failles Injection de requêtes SQL - SQL Injection (SQLI) [149] ou Cross-Site Scripting (XSS) [84] qui exploitent une vul- nérabilité dans le programme.
Par ailleurs, les défauts logiques considérés dans cette thèse sont intrinsèquement liés à la spécification. Ils persisteront malgré l’implémentation qui sera faite de l’appli- cation. Ainsi, seule leur prise en compte par la modification de la spécification permet de les prévenir. C’est la raison pour laquelle nous utilisons les termes défauts et insuf- fisances (ou manquement) plutôt que failles et vulnérabilités.
Il existe principalement deux fonctions qui sont partagées par les composants du parcours d’authentification : la fonction de vérification des attributs d’identité et la fonction d’authentification lors de l’utilisation du service. La vérification des attributs d’identité est nécessaire à la souscription d’une nouvelle entité. Tandis que le méca- nisme d’authentification est utilisé tout au long du cycle de vie de l’application par les différents composants du parcours.
3.2.1
Défauts logiques liés à la phase d’enregistrement
Insuffisance dans la vérification des identités
Une insuffisance dans la vérification des attributs d’identité est constatée lorsque l’application échoue sur la vérification des propriétés d’unicité, d’appartenance et de validité des attributs d’identité fournies par l’entité. La validité assure que l’attribut est valide et existe. L’unicité assure que l’entité est unique dans le contexte de l’ap-
plication. Tandis que, l’appartenance prouve que les attributs fournis appartiennent à l’entité qui les a fourni. L’exploitation majeure d’une insuffisance dans la vérification d’identités est la souscription d’une entité frauduleuse qui pourrait utiliser le service à des fins malicieuses (cf. Section 3.1.1).
Insuffisance dans l’émission des preuves de sécurité
Les preuves de sécurité (i.e., credentials en anglais) permettent à une entité d’ac- céder à un service via le formulaire de login. Une application peut nécessiter di- vers preuves de sécurité pour des actions liées à son fonctionnement : la réalisation d’actions sensibles (e.g., validation d’un paiement en ligne, changement d’un mot de passe). Ainsi, une insuffisance dans l’émission de ces preuves de sécurité est constatée lorsque la réalisation d’une action est bloquée par l’absence de la preuve d’identité nécessaire pour l’accomplissement cette action.
Ce défaut impacte principalement l’utilisabilité d’un service en causant des états bloquants pour certains usages. (i.e., voir l’application Blablacar et Showroom Pri- vée en Section 3.1.1). Ce défaut est très courant chez les applications qui utilisent la délégation d’authentification et qui demandent le mot de passe d’origine pour la réali- sation de certaines actions (e.g., changement d’adresse, ajout de carte bancaire). Par ailleurs, il est important de préciser que l’acquisition d’une nouvelle preuve d’identité est possible ultérieurement dans le cycle de vie de l’application. Celle-ci est considé- rée comme une mise à jour des attributs d’identité, par conséquent, elle nécessite un mécanisme de sécurité afin de satisfaire les exigences requises.
3.2.2
Défauts logiques liés au mécanisme d’authentification
Les défauts classifiés dans cette catégorie concernent les mécanismes d’authen- tification utilisés lors des phases de login, les phases de récupération et de mise à jour d’une preuve d’identité. Particulièrement, c’est l’authenticité de l’entité légitime qui est mise en défaut. Le risque de sécurité majeur est l’accès non-autorisé dont les conséquences sont entre autres : l’imitation de l’entité légitime, la substitution de celle-ci et le vol d’identité. Ci-après les différentes classes de défauts logiques identi- fiées.Défaut de limitation impropre du nombre de tentative d’authentification La limitation du nombre d’essai pour trouver un secret est l’une des mesures de sécurité la plus utilisée pour éviter les attaques par force brute. Cette mesure est parfois accompagnée d’une Preuve d’interaction avec un Humain - Human Interaction Proof (HIP) tel que le Captcha afin de détecter les agissements robotisés [32].
Beaucoup de spécifications fixent un nombre d’essai relativement bas et choi- sissent de bloquer l’entité pendant une durée déterminée en cas d’échec. Cette me- sure peut être détournée afin de bloquer l’accès à une entité cible (i.e., voir l’applica- tion Améli en Section 3.1.1). Cependant, ne pas fixer un nombre limité de tentative expose l’application aux attaques par force brute. Un compromis est nécessaire pour protéger l’application contre les attaques par force brute d’une part. Et, d’autre part, éviter que la mesure ne soit détournée afin de mettre en déni de service les entités légitimes.
Défaut de validation d’une authentification multi-facteurs
La validation de certaines authentifications multi-facteurs pourrait être exploitée afin d’amener l’utilisateur légitime à valider une transaction dont il n’est pas à l’ori- gine (voir l’application Paylib en Section 3.1.1). En effet, deux types de validation existent dans l’authentification multi-facteurs : la validation locale et la validation à distance. La validation est locale si la transaction est explicitement finalisée sur le canal de départ. Par exemple, le 3D secure avec un OTP [87] à confirmer sur ca- nal de départ (i.e., interface d’une application Web/Mobile). Alors qu’une validation à distance est effectuée via un autre canal que celui d’origine. C’est l’exemple d’une validation via une application tierce telle que sur Paylib et Mobile Connect et Moi. Les méthodes d’ingénierie sociale qui permettent de récupérer l’OTP et de valider une transaction localement ne sont pas prises en compte dans cette thèse.
Par ailleurs, nous considérons la validation à distance comme étant un défaut lo- gique car pouvant conduire l’utilisateur légitime à valider une transaction dont il n’est pas à l’origine. Deux types d’attaques sont possibles. Le premier consiste à initier la transaction à la place de l’entité légitime et espérer que celle-ci la valide par inad- vertance. Le second, plus complexe, nécessite de réaliser une transaction frauduleuse en même temps qu’une transaction légitime et amener l’entité légitime à valider la transaction frauduleuse.
Défaut de vérification des attributs d’identité
Nous avons remarqué que certaines applications qui utilisent la fédération d’iden- tités (i.e., Showroom Privée) autorisent instantanément l’accès à une demande d’ou- verture de session via la fédération d’identités s’il existe un compte associé à l’adresse e-mail de contact du fournisseur d’identités.
Pour illustrer l’attaque, nous allons souscrire une entité sur Showroom Privée avec l’adresse e-mail entite@entite.fr. Nous précisons ne pas utiliser la fédération d’identi- tés pour la souscription de l’entité. Néanmoins, nous créons un compte Facebook avec la même adresse e-mail (i.e., entite@entite.fr). Ainsi, en se connectant sur l’application Facebook, nous pouvons accéder à l’application Showroom Privée via le formulaire de
délégation d’authentification même si l’entité ne s’est pas inscrite avec la fédération d’identité. En effet, l’application se base sur l’adresse e-mail de contact afin de lier l’entité à un compte existant sur Showroom Privée. L’erreur fondamentale est le fait de considérer que l’entité connectée sur le fournisseur d’identité est la même que celle qui a souscrit au service.
Le mécanisme d’authentification, en l’occurrence Facebook Login7, n’est pas mis en défaut dans cette exploitation. Cependant, la faute est due au mécanisme de véri- fication de l’application tierce (i.e., Showroom Privée).
Défaut d’authentification explicite/hypothèse de sécurité
Le défaut d’authentification explicite caractérise toute conception ou choix de l’uti- lisateur pouvant, partiellement ou complètement, conduire à une absence d’authen- tification explicite de l’entité courante. Nous partons du postulat que le mécanisme d’authentification doit être supporté par le fournisseur de service ou à défaut, expli- citement délégué à un tiers de confiance (e.g., un fournisseur d’identités). Ainsi, est inclus dans cette catégorie, tout mécanisme d’authentification fondé sur une hypo- thèse de sécurité susceptible de ne pas être respectée. Par "hypothèse" de sécurité, on entend le fait de considérer que l’environnement d’exécution (e.g., le téléphone, l’ordinateur portable) d’une application ou d’un service est sécurisé et n’est accessible que par l’entité légitime. Par conséquent, la sécurité de l’application est implicitement substituée par celle de son environnement d’exécution. De ce fait, la compromission de la sécurité de cet environnement d’exécution est propagée sur l’ensemble des ser- vices s’y exécutant. Par exemple, pour limiter le nombre de demandes d’authentifica- tion ; la pratique actuelle, entre autre, consiste à garder la session utilisateur actif via des cookies de session stockés dans le navigateur. De ce fait, l’accès à ce cooki de session [37] ou l’accès au navigateur [10, 177] garantit l’accès au service.
Nous précisons que la délégation d’authentification et l’authentification fondée sur la possession d’un secret (e.g., carte à puce, téléphone mobile etc.) ne sont pas consi- dérées comme des hypothèses de sécurité, mais plutôt, comme des mécanismes alter- natifs.
Existence de chemins faibles
Plusieurs composants d’un parcours d’authentification peuvent permettre d’accé- der à un service. Parmi eux, le formulaire de login, la récupération des preuves de sécurité ou encore la fédération d’identités. Chacun de ces composants utilisent un moyen d’authentification de niveau de sécurité différent. Des standards et recomman- dations existent pour définir ce niveau de sécurité [26, 79, 95]. Par contre, ces moyens ne prennent pas en compte les éléments de contexte qui influent sur ce parcours et sur
son niveau de sécurité. Nous considérons qu’il y a un chemin faible lorsqu’il existe un parcours dont le niveau de sécurité est plus faible que le niveau d’authentification re- quis. Cela implique au concepteur du parcours de définir un niveau de sécurité requis pour accéder au service.
3.2.3
Vers une ontologie du parcours d’authentification
L’étude empirique et la classification des défauts logiques constituent une base de connaissance pour la création d’une ontologie des risques relatifs au parcours d’au- thentification (cf. Figure 3.4). Cette ontologie est similaire à certaines ontologies dis- cutées dans l’état de l’art [159, 104], cependant celle-ci est spécifique au contexte du parcours d’authentification dans le but de capturer les exigences pertinentes pour limiter les défauts logiques. Ainsi, cette ontologie définit les relations entre les compo- sants du parcours d’authentification, les classes de défauts et leurs exploitations par une entité malicieuse. Les concepts de cette ontologie sont décrits ci-après.
— Le parcours d’authentification avec ces différentes composantes constitue l’abstraction de notre bien à protéger contres les risques. En réalité, le bien en question est le compte utilisateur d’une entité légitime qui doit être protégé contre les risques d’usurpation d’identité (e.g., accès non autorisé, souscription frauduleuse) ou d’inaccessibilité.
— Les risques sont des évènements redoutés (e.g., usurpation, inaccessibilité) occasionnés par les défauts logiques.
— Les défauts logiques constituent les failles de sécurité susceptibles d’exister sur le parcours d’authentification.
— Les facteurs sont des éléments de contexte ou de spécification qui peuvent conduire à une faille de sécurité soit de façon unique ou par combinaison de différents facteurs.
— Les exploitations ou attaques logiques sont des conséquences négatives sur le parcours d’authentification.
— Les exigences peuvent servir de mesures pour atténuer les risques. — Les mécanismes permettent d’appliquer les exigences spécifiées.
Certains concepts présents dans les ontologies relatives à la sécurité tels que les me- naces, les attaquants et les conséquences ou impacts ne sont pas traités dans cette ontologie. En effet, dans notre contexte, ces concepts ne nous apportent pas d’in- formations supplémentaires pour capturer nos exigences. Par exemple, le concept d’attaquant est ignoré car le seule attaquant considéré dans ce contexte de défaut logique est l’humain ; il en est de même pour les impacts des risques car celles-ci dé- pendent du contexte de l’application. Cependant, ces concepts pourraient être ajoutés afin d’étendre l’ontologie.
Les concepts de notre ontologie est les relations entre ces concepts sont présen- tées dans la Figure 3.4. Elle se lit comme suit : le parcours d’authentification (e.g.,
login, récupération) peut contenir un ou plusieurs défauts logiques (e.g., erreur de vérification, validation) qui sont causées par des facteurs humains, choix de concep- tion ou le dispositif de l’utilisateur final. Ces défauts logiques sont ainsi exploités par une personne malicieuse pour réaliser des exploitations logiques qui conduisent à des risques (e.g., inaccessibilité, substitution de la personne légitime). Les exigences appliquées à travers les mécanismes de sécurité permettent d’atténuer ces risques.
Un exemple illustratif de l’ontologie est une attaque de déni de service qui conduit à l’inaccessibilité du compte de l’utilisateur légitime. Ainsi en utilisant l’ontologie on peut caractériser l’attaque comme exploitant un défaut logique causé par un choix de design du type mauvaise limitation du nombre de tentative d’authentification. Ainsi, en déduire le ou les exigences qui permettent d’atténuer ce risque. C’est dans cette optique d’aider à capturer les exigences pertinentes que nous avons construit cette ontologie. La section suivante présente ainsi la liste des exigences que nous préconi- sons.