Cartographier une application : pages, formulaires, paramètres

Un cambrioleur de film repère les lieux avant d’agir. Un testeur, lui, dresse un plan avant de chercher des failles, pour savoir où regarder. Cartographier une application, c’est lister ses pages, ses formulaires, ses paramètres et ses rôles. Cette étape, discrète et peu spectaculaire, détermine la qualité de tout l’audit : on ne peut pas tester ce qu’on ne connaît pas.

Pourquoi cartographier ?

Une application web est un iceberg. La partie visible, ce sont les pages du menu. Dessous, il y a des fonctions peu visibles : une page d’administration, une interface d’API, un formulaire accessible seulement après une action précise. Les failles se cachent souvent dans ces recoins que personne n’a pensé à protéger. La cartographie vise à rendre visible l’ensemble.

Les éléments à recenser

Pour chaque page ou fonction, notez :

• L’URL et la méthode (GET, POST…) ;
• Les paramètres : dans l’URL (?id=3), dans le corps d’un formulaire, dans les en-têtes, dans les cookies ;
• Les formulaires : leurs champs, leur destination, la présence d’un jeton anti-falsification (nous en reparlerons) ;
• Les rôles : ce que voit un visiteur anonyme, un utilisateur connecté, un administrateur ;
• Les technologies visibles : en-têtes de réponse, extensions de fichiers, messages d’erreur ;
• Les fonctions sensibles : connexion, inscription, réinitialisation de mot de passe, paiement, envoi de fichier, recherche.

Exploration manuelle : la base

Avec le proxy actif, parcourez toute l’application comme un utilisateur curieux : cliquez sur chaque lien, remplissez chaque formulaire avec des valeurs ordinaires, créez un compte, ajoutez au panier, modifiez votre profil. Le proxy enregistre tout ; la carte du site (site map) se remplit toute seule. Cette méthode a un grand avantage : elle respecte la logique réelle de l’application, avec les enchaînements d’étapes qu’un outil automatique manquerait.

Pensez à explorer sous plusieurs identités. Un même menu n’affiche pas les mêmes fonctions à un anonyme et à un utilisateur inscrit. Gardez une trace de qui peut accéder à quoi : ce tableau servira directement aux contrôles d’accès du chapitre 5.

Lire ce que la page révèle

Le code source d’une page et les réponses du serveur contiennent des indices précieux. Cherchez :

• les liens cachés ou non affichés dans le menu ;
• les commentaires HTML laissés par les développeurs ;
• les adresses d’interfaces d’API appelées par les scripts de la page ;
• les champs de formulaire masqués (type="hidden"), qui transportent parfois des valeurs que l’application croit « sûres » ;
• les en-têtes de réponse qui trahissent le serveur ou le langage utilisé.

Ces indices ne sont pas des failles en soi, mais ils orientent les tests. Un champ masqué qui contient un identifiant de compte, par exemple, est une piste à creuser plus tard.

Exploration automatisée : un complément, pas un substitut

Des outils d’exploration (« crawlers ») suivent automatiquement les liens pour construire la carte. D’autres testent des chemins courants à partir d’une liste de noms pour découvrir des pages non liées. Ils sont utiles, mais gardez trois précautions :

1. Ils sont bruyants : ils envoient beaucoup de requêtes, ce qui est acceptable dans un labo, pas toujours en production.
2. Ils peuvent déclencher des actions : suivre un lien « supprimer » ou soumettre un formulaire peut modifier des données. Dans l’application d’entraînement, ce n’est pas grave ; en mission, il faut cadrer ces outils.
3. Ils manquent la logique : une étape accessible seulement après un enchaînement précis leur échappe.

La bonne pratique : explorer d’abord à la main, puis compléter avec un outil, puis comparer les deux cartes. Ce qui apparaît dans l’une et pas dans l’autre mérite un regard.

Un exemple de carte

Voici un extrait de carte pour une boutique d’entraînement fictive, tel que vous pourriez le noter dans votre carnet :

Remarquez la colonne « Remarque » : elle contient déjà des hypothèses de test (« reflète le terme saisi », « le prix est-il envoyé par le client ? »). Vous reconnaîtrez bientôt ce que chacune cache : injection, XSS, logique métier, contrôle d’accès. La carte n’est pas un inventaire passif, c’est votre plan de travail.

À vous de jouer

Cartographiez votre application d’entraînement.

1. Avec le proxy actif, parcourez toutes les pages accessibles anonymement, puis créez un compte et parcourez celles qui nécessitent une connexion.
2. Dans votre carnet, dressez un tableau d’au moins dix fonctions avec leur méthode, leurs paramètres et leur niveau d’accès.
3. Repérez trois endroits où l’application « renvoie » ce que vous avez saisi, et trois paramètres qui ressemblent à un identifiant.
4. Écrivez, pour chacun de ces six éléments, une hypothèse de test en une phrase.

Vous avez maintenant une méthode, un outil, un terrain et une carte. Le chapitre suivant s’attaque à la porte d’entrée de toute application : l’authentification.