Mis à jour 16 fev. 2021
Les failles logiques restent un type de vulnérabilités méconnues dans la sécurité informatique. Ce ne sont pas des erreurs dans le raisonnement logique. Il s’agit de failles liées au fonctionnement d’une application web. Elles diffèrent des vulnérabilités techniques, qui elles, sont directement liées à des erreurs de code, d’implémentation ou de configuration.
Nous trouvons régulièrement ces vulnérabilités de logique business lors de tests d’intrusion, sur tout type d’applications. Généralement, les sites ecommerce et les logiciels SaaS sont les solutions où ces vulnérabilités se retrouvent le plus fréquemment.
Que sont les failles logiques ? Comment les détecter ? Comment les éviter ?
Après avoir compris comment ces vulnérabilités fonctionnent, nous nommons cinq grandes catégories de failles logiques et vous donnons des questions bien précises qui aident à les identifier lors de tests qui peuvent être mené en interne ou lors d’un audit de sécurité. Pour finir, nous donnerons des exemples que nous avons rencontrés durant des tests d’intrusion
Qu’est-ce qu’une faille logique sur une application web ?
Une faille logique se produit lorsqu’une application (site web, application mobile, webservice…) ne se comporte pas comme prévu. Cela arrive lorsqu’une étape logique ou un workflow peut être évité, contourné ou manipulé par l’attaquant. L’attaquant détourne un processus dans son intérêt, ce n’est pas une erreur technique en soi.
Les failles logiques peuvent souvent être exploitées sans outils techniques spécifiques, parfois en manipulant simplement l’url ou le code html de la page. Généralement, l’utilisation d’un proxy pour intercepter et rejouer les requêtes facilite la découverte et l’exploitation des vulnérabilités.
Imaginez une plateforme e-commerce spécialisée dans la vente de t-shirts. Le parcours utilisateur normal est le suivant :
- Ajoute des t-shirts à son panier d’achats.
- Paye avec sa carte de paiement.
- Finalise la commande.
Une personne malintentionnée arrive sur le site et exploitera par exemple une faille logique de cette manière :
- Ajoute deux t-shirts à son panier.
- Paye avec sa carte de crédit.
- Ajoute des t-shirts supplémentaires au panier (10).
- Finalise la commande et reçoit au final 12 t-shirts, pour le prix de 2.
Les failles de logique business existent également dans la vie réelle. Nous pouvons comparer cet exemple e-commerce à ce qui peut arriver dans un supermarché physique. Le « workflow » normal du supermarché suppose que le consommateur ajoute les articles de son choix dans le caddie et qu’il les mette ensuite sur le tapis roulant de la caisse. Mais que se passe-t-il si un consommateur malintentionné cache un article dans son caddie au moment du passage en caisse ? La personne en caisse ne verra pas l’article, et le consommateur ne le payera pas.
Chaque faille logique est quasiment unique, car il s’agit d’exploiter une fonction spécifique à l’application. En fonction de l’application, les failles de logique peuvent être très puissantes et dangereuses, car elles sont liées au fonctionnement même de la solution. Lorsqu’il s’agit de processus de récupération de mots de passe, ou d’autres transactions sensibles, les dommages peuvent par conséquent devenir considérables.
Les failles logiques sont plus difficiles à identifier que des failles techniques (XSS, injections SQL, CSRF…). Les failles techniques sont encore trop fréquentes, vous pouvez d’ailleurs lire notre article sur les attaques les plus courantes sur les applications web. Mais les vulnérabilités logiques restent généralement moins étudiées, moins testées et leur impact est souvent sous-estimé.
Comment détecter une faille logique dans une application ?
Tester la sécurité logique nécessite d’aller plus loin que ce que tout outil de sécurité automatisé peut faire. Ces failles sont découvertes lors des tests d’intrusion. Il est nécessaire d’étudier et de comprendre le fonctionnement prévu (et donc non prévu) d’un site ou d’une application et de penser « attaque » : quels gains pourraient obtenir des attaquants dans cette situation ?
Les scanneurs de vulnérabilités ne sont pas mauvais dans la détection de failles techniques lorsque les conditions sont bonnes. Ils testent les failles techniques liées à des erreurs dans le code ou de configuration. Mais ils sont incapables de comprendre une situation et de réfléchir à comment esquiver ou détourner un contrôle. Un scanneur ne saura pas qu’accéder aux factures d’un autre utilisateur en modifiant l’url est une faille logique par exemple.
Découvrir les faiblesses logiques d’une application nécessite de cerner le comportement attendu de cette application, de comprendre en profondeur la logique métier et l’intérêt qu’un attaquant pourrait y trouver. Avec ces informations en tête, les pentesters font preuve de créativité afin de construire des scénarios imprévus et de les tester sur l’application. Il n’y a qu’un humain qui puisse trouver une solution alternative dans un parcours utilisateur et qui puisse juger si contourner telle étape est pertinent ou non.
Détecter les failles logiques nécessite donc
- d’avoir une compréhension complète de ce que l’application est censée faire : les règles métiers, les processus…
- de découper et modéliser le workflow,
- d’identifier à quels endroits les contrôles sont effectués, et où ils ne sont pas effectués,
- d’analyser les contrôles effectués, les paramètres envoyés, les réponses retournées…
Pourquoi y a-t-il des failles logiques ?
Les failles logiques existent lorsqu’une application ne prend pas les mesures appropriées pour gérer un comportement inattendu. L’attaquant détourne un processus normal, mais l’application n’a pas de contrôle en place pour l’en empêcher.
On peut citer quelques grandes « catégories » de failles logiques :
- les failles liées à un manque de robustesse dans un workflow, qui peut être contourné,
- les failles liées à un manque de contrôle sur les données, qui influencent les actions en cours d’exécution,
- les failles liées à une réaction inattendue de l’application,
- les failles liées à des attaques temporelles,
- les failles liées à un assemblage de fonctionnalités, qui deviennent problématiques uniquement une fois combinées.
Les failles logiques sont généralement le résultat d’un manque de rigueur dans le design et d’un manque de tests approfondis d’un point de vue sécurité sur les processus métier de la solution.
Tout d’abord, les équipes de développements et QA sont peu sensibilisées à ce type de failles. On peut noter que les failles logiques passent souvent au travers des contrôles qualité sans être repérées. Les testeurs QA se concentrent généralement sur ce que l’application est supposée faire (et pas ce qu’elle n’est pas censée permettre).
Ensuite, les failles logiques restent également présentes parce qu’il est difficile d’avoir un œil neuf pour une personne de l’entreprise sur des processus sur lesquelles elle travaille au quotidien et de se mettre dans l’état d’esprit d’un attaquant cherchant à enfreindre les règles de la logique métier.
Comment éviter les failles logiques sur les applications ?
Contrairement aux vulnérabilités techniques, les frameworks et les librairies ne peuvent pas apporter une bonne protection contre ces failles.
La seule solution réelle est d’effectuer des contrôles en validant les processus business et les spécifications technico-fonctionnelles à plusieurs étapes du cycle de développement. Il est crucial de ne pas seulement intégrer des tests sécurité à la fin du projet, car des erreurs de conceptions en amont du développement peuvent être compliquées à rattraper ensuite lorsqu’elles sont ancrées dans le cœur de l’application.
Pour ces tests, les équipes QA/sécurité doivent connaitre en détail le fonctionnement de chaque bout de l’application et la logique métier. Une compréhension complète des technologies utilisées est aussi nécessaire, afin de contrôler les implémentations et associations des différentes technologies. Un réflexe à prendre est par ailleurs de documenter les processus et règles métiers en plus de la documentation technique.
Ensuite, implémenter les contrôles adéquats à chaque étape de chaque workflow permet de s’assurer que la logique métier ne peut pas donner lieu à des abus ou être contournée. Vous pouvez vous appuyer sur les méthodes de management de la qualité, en posant pour chaque étape notamment les questions :
- Qui, de qui, vers qui, avec qui, pour qui…
- Quoi, vers quoi, avec quoi…
- Où, vers où, d’où…
- Quand, à quelle fréquence, pour quelle durée…
- Comment, par quel moyen…
- Combien, quelles quantités…
- Pourquoi, quelle cause, quelle finalité…
Enfin, réaliser un test d’intrusion (pentest) sur le site web ou l’application est un moyen de mettre au jour des vulnérabilités logiques, par des pentesters qui ont l’habitude de chercher ces failles, afin que vous puissiez les corriger.
Pour reprendre notre exemple du départ, le site de vente de t-shirts. Un contrôle doit être mis en place afin de s’assurer que les articles ne peuvent être ajoutés à la commande en cours, une fois que celle-ci a été payée. Dans l’exemple de supermarché physique, l’équivalent est de demander à la personne en caisse de vérifier systématiquement le contenu du caddie, afin de réduire la fraude.
Quelques exemples de failles logiques
Exemple A : Faille logique liée à une attaque temporelle
Durant d’un test d’intrusion sur un site de gestion d’évènements, il y avait une fonctionnalité de réservation de billets. Lorsqu’un client commençait une réservation en ajoutant des tickets dans son panier, ses billets étaient bloqués pour les autres clients pendant un certain nombre de minutes, afin de laisser à l’utilisateur le temps de finaliser sa commande.
Lors de l’attaque, nous avons créé un script qui réservait tous les tickets. En lançant ce script, nous avons bloqué le site entier. Il s’agit d’un déni de service (DoS), car les vrais clients ne pouvaient plus utiliser le site pour acheter leurs billets. Pour le site, cela entraine une perte de chiffres d’affaires (car les utilisateurs se reportent sur des sites concurrents), une perte de confiance, une dégradation de leur image de marque…
Pour empêcher ce type de faille lié à des attaques temporelles, plusieurs solutions sont possibles et cumulables en fonction de la situation : mettre place un captcha au début du processus de réservation, faire un contrôle de l’identité lors de la création du compte (validation du numéro de téléphone par exemple), vérifier qu’une carte bancaire n’est associée qu’à un seul compte, etc.
Exemple B : Faille logique liée au contournement d’un workflow
Durant un pentest sur un site e-commerce, les utilisateurs pouvaient finaliser leur commande en choisissant d’aller la retirer au magasin et de payer sur place. Le personnel au magasin se chargeait de recevoir le paiement et de contrôler la validité du paiement en espèces ou chèque.
Cependant, lorsque la commande était validée, nous avons vu dans les requêtes envoyées que la facture était déjà générée. Nous avons pu récupérer l’url d’accès à la facture grâce à un outil et l’imprimer avant d’aller en magasin. Grâce à cette facture, en nous présentant en boutique, nous avons pu retirer notre commande sans avoir à la payer.
Pour y remédier, une étape a été rajoutée au workflow afin que la facture soit générée uniquement une fois le paiement encaissé.
Exemple C : Faille logique liée au contournement d’un workflow
Un site fonctionnait sur un système un abonnement pour que les utilisateurs accèdent au contenu. Lors de l’inscription, le téléchargement d’un contenu était offert par compte.
Durant le test d’intrusion, nous nous sommes inscrits puis désinscrits de l’abonnement. Nous sommes ensuite inscrits à nouveau, et nous pouvions lors de cette deuxième inscription avec le même compte avoir droit à un nouveau téléchargement d’un contenu.
Un attaquant malveillant aurait pu profiter de cette faille pour télécharger un grand nombre de contenus.
Cette faille était possible, car ce cas de figure de comportement n’a pas été pris en compte lors du développement.
Exemple D :
Créez votre propre exemple !
Prenez le scénario d’utilisation de votre solution, et soyez créatif. L’imagination est la seule limite, jusqu’à ce que les bons contrôles soient mis en place.