Cartographier les chemins d'exécution à travers l'application
Comment cartographier les différents chemins d'exécution (code paths) d'une application web pour assurer une couverture de test complète, en utilisant des techniques telles que le spidering automatique.
| ID |
|---|
| WSTG-INFO-07 |
Résumé
Avant de commencer les tests de sécurité, il est primordial de comprendre la structure de l'application. Sans une compréhension approfondie de la disposition de l'application, il est peu probable qu'un test complet soit effectué.
Objectifs du test
- Cartographier l'application cible et comprendre les principaux flux de travail.
Comment tester
Dans les tests en boîte noire, il est extrêmement difficile de tester l'ensemble du code base. Ce n'est pas seulement parce que le testeur ne peut pas voir les chemins de code à travers l'application, mais aussi parce que tester tous les chemins de code prendrait énormément de temps. Une façon de concilier cela est de documenter les chemins de code qui ont été découverts et testés.
Il existe plusieurs façons d'aborder les tests et la mesure de la couverture du code :
- Chemin - tester chacun des chemins à travers une application qui inclut des tests d'analyse combinatoire et d'analyse des valeurs limites pour chaque chemin de décision. Bien que cette approche offre une grande rigueur, le nombre de chemins testables augmente de façon exponentielle à chaque branche de décision.
- Flux de données (ou analyse de la corruption) - teste l'affectation des variables via une interaction externe (normalement des utilisateurs). Se concentre sur la cartographie du flux, de la transformation et de l'utilisation des données dans une application.
- Course - teste plusieurs instances simultanées de l'application manipulant les mêmes données.
Le choix de la méthode et la mesure dans laquelle chaque méthode est utilisée doivent être négociés avec le propriétaire de l'application. De plus, des approches plus simples pourraient être adoptées. Par exemple, le testeur pourrait interroger le propriétaire de l'application sur des fonctions ou des sections de code spécifiques qui le préoccupent particulièrement, et discuter de la manière dont ces segments de code peuvent être atteints.
Pour démontrer la couverture du code au propriétaire de l'application, le testeur peut commencer par documenter tous les liens découverts lors de l'exploration de l'application (manuellement ou automatiquement) dans un tableur. Le testeur peut ensuite examiner plus attentivement les points de décision dans l'application et étudier le nombre de chemins de code significatifs découverts. Ceux-ci doivent ensuite être documentés dans le tableur avec des URL, des descriptions en prose et des captures d'écran des chemins découverts.
Spidering automatique
Un spider automatique est un outil utilisé pour découvrir automatiquement de nouvelles ressources (URL) sur un site spécifique. Il commence par une liste d'URL à visiter, appelées les graines, qui dépend de la façon dont le Spider est démarré. Bien qu'il existe de nombreux outils de Spidering, l'exemple suivant utilise le Zed Attack Proxy (ZAP) :
Figure 4.1.7-1 : Ecran Zed Attack Proxy
ZAP propose diverses options de spidering automatique, qui peuvent être utilisées en fonction des besoins du testeur :