La recette du Big Hack

Et si vous pouviez commander un menu chez McDonald’s pour 1 centime ? Ou encore vous faire livrer la commande d’un autre utilisateur ? C’est ce qu’a réussi Eaton Zveare sur le site de McDonald’s Inde dans le cadre d’un programme de bug bounty. Ce type de programme, mis en place par certaines entreprises, récompense les chercheurs en cybersécurité qui découvrent et leur signalent des failles.

Seule l’application utilisée dans la moitié sud-ouest de l’Inde était concernée par ces vulnérabilités, et, sauf preuve du contraire, il n’a jamais été possible de les exploiter en France.

De nombreuses failles ont été découvertes, nous allons seulement en aborder une dans cette newsletter. Grâce à cette vulnérabilité, il était possible de changer le prix d’une commande avant de payer.

Pour l’exploiter, le chercheur commence par ajouter plusieurs produits à son panier, pour un total de ₹5681 (~62€).

Au moment de confirmer la commande et avant de passer au paiement, le navigateur envoie une requête "POST" sur la route "/order". Celle-ci contient tous les détails de la commande. Notamment, le montant total de la commande (dans le champ "amount").

Puisque le champ "amount" est présent dans la requête, le chercheur essaie de le modifier en rejouant l’appel à la route "POST /order". L’attaque échoue, parce que, sur cette route spécifique, un mécanisme de signature empêche la modification du payload.

Cependant, une autre route attire l’attention du chercheur. La route "PUT /cart/:cartId" existe pour modifier l’entité “Cart” (le panier). C’est cette route qui est appelée lorsqu’un produit est ajouté au panier par exemple.

Lorsque le navigateur appelle cette route, il reçoit une réponse du serveur avec le format suivant :

Cette réponse semble inclure tous les champs de l’entité Cart, et on y retrouve certains champs qui étaient présents dans le payload de la requête, tels que la quantité des articles. Et, ici aussi, on retrouve le prix (gross_price). On peut donc supposer que ce champ fait partie de l’entité Cart également. Serait-il possible de le modifier lui aussi ?

Le chercheur tente alors d’appeler cette route PUT en passant un prix de 1 rupee dans le champ "gross_price". Et contre toute attente, la requête fonctionne :

Le chercheur réussit donc à payer et à valider sa commande (désormais de seulement 1 rupee, soit environ 0.11€). Étant un hacker éthique, il l’annule après ses tests.

Cette faille, appelée “Mass Assignment” survient souvent lorsqu’il y a un couplage entre les champs attendus pour une requête HTTP et les entités métiers (telles qu’elles sont stockées dans la base de données).

Prenons l’exemple d’une application dans laquelle existe une entité “Order”. Imaginons que les développeurs ont prévu une fonctionnalité de mise à jour de la date de livraison. Dans la requête en question, seul le champ deliveryDate est normalement présent.

Si les développeurs valident uniquement que l’utilisateur a le droit de modifier une commande, sans vérifier les champs qui ont effectivement été modifiés, on a un bon exemple de Mass Assignment.

Un attaquant peut donc modifier plusieurs champs de la base de données auxquels il n’est pas censé avoir accès.

🛡️️ Comment se protéger

Une bonne pratique est de séparer l’entité de la base de données des objets sérialisés pour les requêtes et les réponses (appelées DTO pour Data Transfer Object). Ainsi, pour une fonctionnalité de modification de date uniquement, le serveur va ignorer ou va renvoyer une erreur à la présence de tout champ non spécifié par les développeurs.

Dans certains langages, la possibilité de modifier ou non un champ via l’API peut être mis comme propriété du champ. C’est le cas de NestJS par exemple avec les propriétés "whitelist" et "forbidNonWhitelisted".

Une autre solution serait de recalculer le prix de la commande dans le back au moment du paiement à partir des prix des articles.

Vous pourrez trouver plus d'informations et de ressources sur cette faille ici :