Une application de prise de notes locale peut réussir ses tests unitaires tout en intégrant deux failles de sécurité. La route GET /notes/:id renvoie la note 42 dès qu’un utilisateur authentifié en fait la demande, même si cette note appartient à un autre compte. Par ailleurs, l’application accepte un terme de recherche qui est intégré à une requête de base de données sans traitement sécurisé préalable. Un troisième problème se situe en dehors du code personnalisé du dépôt : une version de paquet est concernée par un avis de sécurité publié. Pour exploiter ces failles, un attaquant a simplement besoin d’un compte valide à faibles privilèges pour la première, d’un point de terminaison HTTP accessible pour la seconde, et d’aucun accès au code source pour le risque lié aux dépendances.
Ces défaillances exposent la surface d’attaque de l’application, c’est-à-dire l’ensemble des chemins d’exécution du code, des interfaces d’exécution et des limites de dépendance par lesquels des entrées non fiables ou des comportements contrôlés par un attaquant peuvent affecter le système. Pour le défenseur, la question n’est pas de savoir quel scanner est le meilleur dans l’absolu. Il s’agit de déterminer quels éléments de preuve les tests de sécurité statiques (SAST), les tests de sécurité dynamiques (DAST) et l’analyse de composition logicielle (SCA) doivent fournir pour cette application de notes, puis d’utiliser ces éléments pour décider si une modification peut être mise en production. Les dépôts de code source, le comportement HTTP en cours d’exécution et les paquets tiers révèlent des facettes différentes du risque.
L’exemple comparatif le plus simple est la requête /notes/42. L’analyse du code source permet d’identifier la condition d’autorisation qui omet de comparer le compte de l’utilisateur demandeur avec celui du propriétaire de la note. L’analyse à l’exécution permet d’envoyer une requête autorisée en tant qu’utilisateur donné et d’observer si la réponse expose la note d’un autre utilisateur. L’analyse des dépendances permet d’examiner le manifeste du paquet sans même invoquer la fonctionnalité vulnérable. L’outil capable de démontrer chaque point dépend de l’emplacement de la faille.
Les limites de confiance au sein de l’application de notes indiquent où commence et où s’arrête chaque type d’analyse.
Ce diagramme illustre pourquoi aucun scanner unique ne peut examiner de manière équivalente les entrées du navigateur, la logique applicative, les appels à la base de données et les limites des paquets externes.
Comme les trois observateurs nécessitent une cible commune, le cours s’appuie sur un dépôt contenant une application de prise de notes hébergée localement et volontairement vulnérable. L’application accepte des paramètres HTTP et des corps JSON au niveau de l’interface API web, utilise une identité établie via la route de connexion locale, renvoie des réponses au format HTML ou JSON et transmet les opérations de base de données par l’intermédiaire de sa couche d’accès aux données. Nous analysons uniquement cette application de laboratoire locale ainsi que les environnements que nous contrôlons. Le test de services tiers sans autorisation écrite sort du cadre de ce cours et pourrait enfreindre des lois telles que le Computer Fraud and Abuse Act aux États-Unis ou le Computer Misuse Act 1990 au Royaume-Uni.
Le dépôt présente deux comportements délibérément introduits. Le premier est un chemin de recherche vulnérable aux injections, représentatif de la CWE-89 (Neutralisation incorrecte d’éléments spéciaux utilisés dans une commande SQL). Le second est un défaut d’autorisation au niveau de l’objet sur la route GET /notes/:id, une catégorie de vulnérabilité désignée sous le nom « API1: Broken Object Level Authorization » dans le classement OWASP API Security Top 10 de 2023. Le manifeste des dépendances référence également un paquet volontairement obsolète présentant une vulnérabilité connue. Ces cas sont traités séparément, car une découverte dans le code, une observation HTTP et un avis de sécurité concernant un paquet ne constituent pas des preuves interchangeables.
L’instantané du dépôt permet de localiser les routes, les mécanismes d’accès aux données et la déclaration des dépendances sans exécuter la moindre analyse ni requête.