Les failles de logique métier : exemples génériques

Une injection ou un XSS reposent sur un défaut technique : un caractère mal traité. Mais une application peut être parfaitement codée et pourtant détournée, parce que ses règles de gestion contiennent une brèche. Vous connaissez peut-être l’histoire de cette boutique qui offrait une remise sur le premier achat, et dont les clients ont découvert qu’il suffisait de créer dix comptes pour la cumuler dix fois. Aucun bug dans le code : une faille dans le raisonnement. Ce sont les failles de logique métier.

Pourquoi ces failles échappent aux outils

Un scanner automatique sait chercher des motifs techniques (un caractère non neutralisé). Il ne sait pas ce qu’est une commande « normale » pour votre boutique, ni ce qu’une remise « devrait » pouvoir cumuler. Les failles de logique exigent donc de la compréhension du métier : c’est l’un des domaines où l’humain reste irremplaçable dans un audit.

Elles proviennent généralement d’hypothèses implicites du développeur :

• « Les étapes seront suivies dans l’ordre prévu. »
• « L’utilisateur n’enverra que les valeurs proposées par le formulaire. »
• « Un seul clic arrive à la fois. »
• « Personne ne voudra utiliser cette fonction de façon contraire à son but. »

Le travail du testeur est de mettre ces hypothèses à l’épreuve, une à une.

Cinq familles d’exemples génériques

1. Les valeurs que le client ne devrait pas contrôler

Quand une commande envoie des paramètres comme produit, quantité et prix, que se passe-t-il si le serveur fait confiance au prix envoyé ? Dans une application correcte, le prix est relu en base de données au moment de la commande. Autres variantes : une quantité négative qui génère un crédit, un montant de remise fourni par le client, un identifiant de livraison modifiable. Test : dans la requête de commande capturée par le proxy, repérez chaque valeur et demandez-vous « le serveur devrait-il me croire sur parole ? ».

2. Le non-respect de l’ordre des étapes

Un parcours en plusieurs écrans (panier, adresse, paiement, confirmation) suppose un enchaînement. Si le serveur ne mémorise pas où en est l’utilisateur, on peut parfois appeler directement l’étape finale en sautant le paiement. Test : tentez d’appeler l’étape de confirmation sans avoir validé l’étape précédente, dans votre application d’entraînement, et observez si le serveur vérifie l’état du parcours.

3. Les limites non appliquées

Une règle « un code promotionnel par client », « un vote par personne », « cinq tentatives par heure » n’existe vraiment que si le serveur l’impose. Un contrôle uniquement affiché dans l’interface, ou une règle qui ne tient pas compte de plusieurs comptes ou de plusieurs appareils, est contournable.

4. Les situations de concurrence

Imaginez un compte avec un solde de 100 euros et deux demandes de retrait de 100 euros reçues à quelques millisecondes d’intervalle. Si le serveur vérifie le solde puis débite sans verrouillage, il peut valider les deux. Ce défaut de synchronisation s’appelle une condition de concurrence (race condition). Les laboratoires de la PortSwigger Academy proposent des exercices guidés sur ce thème, dans un cadre sécurisé. La défense : transactions atomiques et verrouillage au niveau de la base de données.

5. Les fonctions détournées de leur but

Une fonction légitime peut servir à autre chose : un formulaire « contact » utilisé pour envoyer des messages en masse à d’autres personnes, un outil de parrainage utilisé en boucle, un export de données non limité, une fonction de recherche permettant de dresser la liste de tous les utilisateurs. Question de l’auditeur : « si quelqu’un voulait abuser de cette fonction, que pourrait-il obtenir ? ».

La méthode : penser comme un utilisateur malveillant du métier

Pour structurer votre réflexion, utilisez ce petit protocole, applicable à n’importe quelle fonctionnalité :

1. Décrire la règle voulue en une phrase (« un code promo ne s’applique qu’une fois par commande »).
2. Lister les hypothèses implicites (ordre, valeurs, unicité, rythme).
3. Chercher une hypothèse que l’on peut mettre en défaut avec le proxy : changer une valeur, rejouer une requête, sauter une étape, répéter une action.
4. Mesurer l’impact métier : perte financière, fraude, atteinte à l’image, fuite de données.
5. Prouver avec le minimum : un essai dans l’application d’entraînement suffit à établir la faille.

Défendre : concevoir avec le mauvais scénario en tête

• Ne jamais faire confiance au client pour les valeurs qui comptent (prix, droits, état d’avancement) : le serveur les recalcule ou les relit.
• Faire respecter le parcours côté serveur en mémorisant l’état de la transaction.
• Imposer les limites côté serveur et les journaliser.
• Utiliser des transactions atomiques pour les opérations sensibles à la concurrence.
• Rédiger des « cas d’abus » à côté des cas d’usage lors de la conception : « comment cela pourrait-il être détourné ? ».
• Surveiller les comportements anormaux (volume inhabituel de remises, d’exports, de créations de compte).

// Le prix est relu côté serveur ; la quantité est validée
$produit = chercher_produit((int)$_POST['produit']);
$quantite = filter_var($_POST['quantite'] ?? '', FILTER_VALIDATE_INT, ['options' => ['min_range' => 1, 'max_range' => 10]]);
if (!$produit || $quantite === false) { http_response_code(400); exit; }
$total = $produit['prix'] * $quantite;   // jamais le prix reçu du client

À vous de jouer

Choisissez une fonctionnalité de votre application d’entraînement, par exemple l’ajout au panier et la commande dans Juice Shop.

1. Écrivez en une phrase la règle de gestion attendue.
2. Listez quatre hypothèses implicites que le développeur a pu faire.
3. Pour chacune, concevez un essai à faire avec le proxy (sans rien attaquer en dehors du labo).
4. Réalisez les essais et consignez le résultat.

La dernière leçon du chapitre traite d’une faille où l’application devient, malgré elle, un relais pour atteindre des ressources internes : la SSRF.