Que sont les failles logiques sur les applications web?

Qu’est-ce qu’une faille logique ?

Une faille logique se produit lorsqu’une application web (site web, application mobile, webservice…) ne se comporte pas comme prévu.
Cela arrive généralement lorsqu’une étape logique ou un workflow peut être évité ou contourné.

Imaginez un simple site web permettant d’acheter des t-shirts.
Le workflow normal est le suivant :

  1. Le consommateur ajoute des t-shirts à son panier d’achat.
  2. Le consommateur paye avec sa carte de paiement.
  3. Le consommateur finalise la commande.

Une personne malintentionnée arrive sur le site web et fait les choses suivantes :

  1. Ajoute deux t-shirts à son panier.
  2. Paye avec sa carte de crédit.
  3. Ajoute des t-shirts supplémentaires au panier (10).
  4. Finalise la commande et reçoit au final 12 t-shirts, pour le prix de 2.

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? L’hôtesse de caisse ne verra pas l’article, et le consommateur ne le paiera pas.

Panier d'achat dangereux

Chaque faille logique est quasiment unique, car il s’agit d’exploiter une fonction spécifique à l’application web.
En fonction de l’application, les failles de logique peuvent être dès puissantes et dangereuses. Lorsqu’il s’agit de processus de récupération de mots de passe, ou d’autres transactions sensibles, les dommages peuvent devenir considérables.

En plus du potentiel dommage qu’elles peuvent causer, les failles logiques sont les plus difficiles à détecter, en comparaison aux failles techniques (XSS, injections SQL, CSRF…).

Comment détecter une faille logique ?

Détecter des failles logiques nécessite d’aller plus loin que ce que tout outil de sécurité automatisé peut faire. Les scanneurs de sécurité ne sont pas mauvais dans la détection de failles techniques lorsque les conditions sont bonnes, mais totalement incapables de comprendre ce qu’est le comportement prévu (et donc non prévu) d’un site internet ou d’une application mobile.
(Pour plus de détails sur le manque d’efficacité des outils automatisés, vous pouvez lire cet article : Pourquoi tester des applications web avec des outils automatisés n’est pas suffisant )

Détecter les faiblesses logiques d’une application nécessite de comprendre intégralement le comportement attendu de cette application. Avec ces informations en tête, le testeur doit faire preuve de créativité afin de construire des scénarios imprévus et les tester sur l’application.

Afin de revoir la sécurité logique, il est nécessaire de sortir des sentiers battus (du périmètre fonctionnel de l’application), et de penser “attaque”.

Pourquoi y a-t-il des failles logiques ?

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é.
Un manque de rigueur dans le cycle de développement de l’application (SDLC) implique un manque de contrôle du design et des contrôles vagues dans l’application elle-même.

Il est également important de noter que les failles logiques passent souvent à travers les contrôles qualité sans être repérées. Les testeurs QA se focalisant généralement sur ce que l’application est supposée faire (et pas ce qu’elle n’est pas sensée permettre).

Comment éviter de telles vulnérabilités ?

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 au début du cycle de développement.
Ensuite, implémenter les contrôles adéquat à chaque étape de chaque workflow permettra de s’assurer que la logique métier ne peut pas donner lieu à des abus ou être contournée.

Effectuer un test d’intrusion (pentest) sur le site web ou l’application concernée est un moyen de mettre au jour ses faiblesses, dans l’optique de les corriger.

Comme précisé plus haut, des processus faibles et un mauvais design créent ces vulnérabilités. Mettre en place des contrôles logiques et des restrictions met fin au problème.
Revenons à notre exemple e-commerce, le site de vente de t-shirts. Un contrôle doit être mise 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 notre exemple de supermarché physique, demander à l’hôtesse de caisse de systématiquement vérifier le contenu du caddie permet de réduire la fraude.

Quelques exemples de failles logiques

Les exemples ci-dessous sont réels et on été rencontrés sur internet.

Exemple A :

Toujours dans le secteur du e-commerce, supposons que votre site web ajoute automatiquement un cadeau dans la panier du consommateur, lorsque celui-ci atteint un certain montant total. Techniquement, vos développeurs ont choisi d’implémenter ce “cadeau” en ajoutant un article “normal” d’une valeur de 8 EUR dans le panier, et en ajoutant également un élément de “remise” de -8 EUR pour équilibrer.
Le consommateur décide alors de supprimer le cadeau du panier, mais le site web ne retire par la remise correspondante! Ainsi, n’importe quel consommateur peut bénéficier d’une remise de 8 EUR, ce qui n’est pas le scénario prévu.

Pour éviter ce problème, le système doit supprimer la remise de 8 EUR en même temps que le cadeau, lorsque ce dernier est retiré du panier.

Exemple B :

Dernier exemple dans le monde du e-commerce, qui peut en fait fonctionner dans d’autres scénarios :
Le panier d’achat affiche les articles que le consommateur a sélectionné, et utilise des champs cachés afin de garder en mémoire les prix des articles.
Si un utilisateur malicieux modifie le contenu de ces champs cachés avant d’envoyer le contenu du panier et de procéder au paiement, il peut alors modifier les prix.

Pour éviter ce type de failles, le site web ne doit pas s’appuyer sur des champs cachés (informations côté client d’un point de vue technique), mais utiliser les informations stockées sur le serveur.

Exemple C :

Sur un site bancaire, un utilisateur peut effectuer des transferts de fonds vers n’importe quel compte tiers.
Il n’y a pas de contrôle sur le montant qui est spécifié par l’utilisateur.
Un utilisateur malintentionné décide d’entrer un montant négatif pour un transfert de fonds.
Au lieu d’envoyer de l’argent sur le compte B, l’attaquant retire donc de l’argent de ce compte.

Un contrôle doit être implémenté afin de prévenir ce type de problème.

Exemple D :

Créez votre propre exemple !
Prenez n’importe quel scénario utilisateur d’un site Internet, et soyez créatif. L’imagination est la seule limite, jusqu’à ce que les développeurs mettent en place les bons contrôles.