Une requête concernant un panier d’achat, censée renvoyer les articles d’un client donné, peut à la place renvoyer les données d’un autre client si l’application ne vérifie pas correctement les droits de propriété. Un attaquant peut n’avoir besoin que d’une session valide et d’une référence d’objet visible, sans recourir à un logiciel malveillant ni nécessiter un accès au serveur. Ce cours examine ce type de défaut de contrôle des limites uniquement dans un environnement de laboratoire isolé et fixe, où chaque constatation repose sur une requête et une réponse HTTP observables plutôt que sur une chaîne d’exploitation complexe.
Notre cible autorisée est OWASP Juice Shop, accessible à l’adresse http://app.lab:3000 (associée à l’IP 10.0.0.20) ; les tests sont effectués exclusivement depuis une machine Kali située à l’adresse 10.0.0.10. Le laboratoire n’ayant pas d’accès à Internet, toute requête capturée par Burp correspond à un échange entre le testeur et l’application, et non à un trafic vers un service externe. L’application et son système de stockage de données constituent des entités distinctes, même si nous n’observons que le comportement HTTP de l’application. Définissons les limites qui garantissent la pertinence des preuves recueillies dans le laboratoire :
Ce schéma indique où se situent les éléments de preuve : au niveau de l’échange entre le navigateur et Burp, incluant la requête interceptée et la réponse reçue. Une réponse telle qu’un code 200 OK inattendu, un message d’erreur révélant des détails d’implémentation ou des données appartenant à un autre compte de laboratoire ne constitue une preuve que si l’on conserve également la requête à l’origine de cette réponse.
Une fois la limite réseau établie, les règles d’engagement définissent les contraintes opérationnelles : ce qui peut être testé, les modalités des tests et les effets interdits. La seule cible autorisée est 10.0.0.20 et l’interface permise est le protocole HTTP vers app.lab:3000. Les requêtes adressées à une autre adresse IP, à un nom DNS externe ou à un autre service sont hors périmètre, même si un navigateur ou un proxy en facilite l’accès.
Les règles interdisent la persistance, le déni de service, la réutilisation d’identifiants autres que ceux fournis pour le laboratoire, l’ajustement de charges utiles (payloads) visant à contourner les protections, ainsi que le scan d’adresses non concernées. Ces limites préservent l’intégrité du laboratoire, évitent toute extension accidentelle de l’impact et garantissent que les conclusions restent centrées sur le comportement de l’application web analysée. Le Computer Fraud and Abuse Act aux États-Unis et le Computer Misuse Act 1990 au Royaume-Uni illustrent l’importance d’une autorisation écrite et d’un périmètre défini ; ces références ne constituent toutefois pas des conseils juridiques. Nous pouvons mettre en balance chaque contrainte et les preuves qu’elle nécessite :