Vulnérabilités de logique métier¶
Les vulnérabilités de logique métier (business logic vulnerabilities, aussi appelées défauts de logique applicative) sont des défauts de conception et d'implémentation qui permettent de provoquer un comportement non prévu. Elles résultent généralement d'un manque d'anticipation des états inhabituels de l'application, et donc d'une absence de gestion sécurisée de ces états. Ici, « logique métier » désigne les règles selon lesquelles l'application opère — rien à voir avec un secteur d'activité particulier.
Ces failles tiennent à des hypothèses erronées du développeur sur la façon dont les utilisateurs interagiront avec l'application. Elles sont propres à chaque application, ce qui les rend difficiles à détecter automatiquement, mais souvent simples à exploiter une fois comprises.
Trop de confiance dans les contrôles côté client¶
Une hypothèse fréquente et fausse : l'utilisateur n'interagit avec l'application que via un navigateur. Avec un proxy comme Burp, on intercepte et modifie une donnée après son émission par le client mais avant sa réception par le serveur. Si le prix d'un produit est envoyé par le client lors de l'ajout au panier, il suffit d'intercepter (ou de rejouer) la requête pour modifier le prix reçu par le serveur.
Entrées non conventionnelles¶
L'exploration des états inhabituels passe par des entrées que le développeur n'a pas anticipées :
- Valeurs négatives, et leur comportement combiné à des valeurs positives.
- Valeurs énormes dépassant les limites de stockage d'un entier.
- Dépassement de longueur (au-delà de 255 caractères) sur des données stockées, pour manipuler le résultat.
- Étapes omises : en interceptant, on retire une étape d'un workflow pour observer la réaction de l'application.
- Contournement de limite par alternance : une action non répétable peut en fait n'être protégée que contre la répétition consécutive. Appliquer deux coupons en alternance permet parfois d'appliquer chacun plusieurs fois. Des macros de navigation permettent d'automatiser ce type d'exploitation.
On peut aussi écrire de la donnée côté serveur via les fonctionnalités de l'application en provoquant des messages d'erreur (e-mail invalide, caractères spéciaux) : si l'application reflète cette donnée sous forme chiffrée quelque part, et qu'elle réutilise le même mécanisme ailleurs, on peut éventuellement l'exploiter.
Aide-mémoire¶
| Vecteur | Approche |
|---|---|
| Contrôle côté client | Intercepter et modifier la donnée (prix, quantité) |
| Valeurs hors normes | Négatives, énormes, dépassement de longueur |
| Workflow | Omettre ou réordonner des étapes |
| Limite par alternance | Alterner deux valeurs pour contourner la non-répétition |
La démarche consiste à se demander quel état le développeur n'a pas anticipé : c'est en sortant des chemins d'usage prévus que se révèlent ces failles, propres à la logique de chaque application.