Paramètres cachés en test d’intrusion web : identification et analyse

Introduction aux paramètres cachés

Les paramètres web sont au coeur des interactions entre une application et ses utilisateurs. Transmis via les requêtes HTTP (GET, POST, etc.), ils jouent de nombreux rôles : gestion de session, personnalisation de l’interface, contrôle de fonctionnalités, communication avec des API… bref, des éléments critiques, souvent sous-estimés.

Parmi eux, certains sont visibles et bien documentés. D’autres, en revanche, passent sous le radar : ce sont les paramètres cachés. Ils sont bel et bien traités par l’application, mais ne sont ni exposés à l’utilisateur, ni toujours référencés dans l’interface. On peut les classer en plusieurs catégories :

• Obsolètes ou oubliés : utilisés à un moment du développement, puis abandonnés sans être désactivés. Ils continuent parfois à répondre aux requêtes, même après une mise à jour ou une refonte.
• Non référencés ou invisibles : certains sont volontairement dissimulés (debug, configuration d’environnement, bypasss internes). Ils n’apparaissent pas dans le rendu HTML ou dans les éléments interactifs visibles.
• Présents mais discrets : injectés dans le code côté client (HTML, JS), par exemple via des champs cachés (<input type="hidden">) ou des variables JavaScript, sans pour autant être affichés ni facilement détectables.

Ces paramètres ne sont pas anodins. Lors d’un test d’intrusion ou d’un audit, leur détection peut révéler des chemins alternatifs, des mécanismes de contrôle d’accès oubliés, ou tout simplement des erreurs de conception. Invisibles pour l’utilisateur lambda, ils peuvent devenir de véritables points d’entrée pour un attaquant.

Détection des paramètres cachés

L’identification des paramètres cachés est une étape essentielle lors d’un test d’intrusion et peut être abordée de plusieurs manières :

Analyse statique :

1. Code source (quand il est disponible) : Si l’application est open source ou si certains fichiers sont exposés (Git, JS minifié mal protégé, configs oubliées), un coup d’oeil dans le code peut révéler des paramètres codés en dur, variables, constantes ou endpoints désactivés qui n’étaient clairement pas censés être publics.
2. Code HTML et JavaScript : Inspecter le code généré côté navigateur (HTML + JS) permet souvent de tomber sur des champs planqués, comme des (<input type="hidden">), ou des variables JavaScript qui construisent des requêtes à la volée. Ce n’est pas visible à l’écran, mais bien présent dans le DOM et exploitable.
3. Requêtes HTTP : En passant l’appli au proxy (BurpSuite, ZAP, etc.), on découvre parfois des paramètres qui ne figurent pas dans l’UI, mais qui voyagent bien dans les requêtes POST, GET ou AJAX. Ce sont souvent ceux qu’on oublie de sécuriser, justement parce qu’ils ne sont pas visibles côté interface.
4. Moteurs de recherche : Les moteurs de recherche et outils comme Waybackurls ou Waymore sont une vraie mine d’or. Ils révèlent parfois d’anciens liens ou paramètres qui ont été supprimés de l’UI, mais pas désactivés côté back-end. Une vraie aubaine pour repérer des endpoints fantômes ou des fonctionnalités oubliées.

Analyse dynamique :

L’analyse dynamique consiste à tester l’application en lui envoyant directement des requêtes souvent avec des paramètres inventés ou modifiés pour observer comment elle réagit. Le but étant de repérer des différences dans les réponses, des comportements anormaux, ou tout simplement des paramètres traités en back-end alors qu’ils ne sont jamais exposés à l’utilisateur.

C’est particulièrement utile pour détecter des paramètres cachés qu’on ne voit ni dans le code source, ni dans l’interface. Pour ça, plusieurs outils peuvent faire gagner un temps précieux :

• X8 (par Sh1Yo) : Rapide et performant, X8 analyse un grand nombre d’URLs avec précision en testant des wordlists personnalisées. Il détecte des paramètres spécifiques comme admin=true, même dans des cas complexes.
• Arjun (par s0md3v) : Identifie rapidement les paramètres HTTP cachés en testant 25K mots-clés en moins de 10 secondes, tout en optimisant les requêtes et en extrayant des paramètres du JavaScript.
• Param Miner (extension pour BurpSuite) : Détecte les paramètres cachés et non référencés en testant jusqu’à 65K noms par requête via une analyse différentielle et une recherche binaire.

Pour gagner du temps, la plupart des outils envoient d’un coup une série de paramètres suspects dans une seule requête. Plutôt que de tester chaque paramètre un par un, cette approche permet d’en balayer des dizaines à la volée ce qui optimise clairement le fuzzing, tout en limitant la charge réseau et le bruit côté serveur. Mais pour maximiser les chances de détection, il faut combiner deux approches d’analyse dynamique
complémentaires :

• Fuzzing par défaut : Cette approche repose sur l’utilisation de wordlists génériques pour tester des paramètres. Ces listes comprennent des mots-clés courants ou standards, souvent utilisés dans diverses applications web. Voici quelques-unes des principales wordlists recommandées :
  • SecLists : burp-parameter-names.txt (~ 6k entrées).
  • SamLists : sam-cc-parameters-lowercase-all.txt (~ 47k entrées), sam-cc-parameters-mixedcaseall.txt (~ 52k entrées).
  • Arjun : large.txt (~25k entrées), medium.txt (~10k entrées) et small.txt (~1k entrées).
• Fuzzing personnalisé : L’idée ici est d’adapter les wordlists au contexte réel de l’application. Plutôt que de tester une liste générique, on peut extraire directement des mots-clés depuis le site ciblé. L’extension GAP (par xnl-h4ck3r) est excellente pour ça. Elle s’intègre à BurpSuite et génère automatiquement des listes de paramètres potentiels en analysant l’historique des requêtes et réponses. GAP peut extraire des mots-clés à partir de plusieurs sources : requêtes HTTP, réponses, fichiers JavaScript, XML, JSON, ou encore directement dans le HTML ou les chemins d’URL. Mieux encore : elle propose des options de filtrage avancées, comme la gestion du singulier/pluriel, ou la limitation de la taille des paramètres générés. De quoi construire une wordlist sur mesure, bien plus pertinente qu’un simple fichier brut.

L’analyse dynamique combine le fuzzing par défaut avec une approche personnalisée pour une exploration approfondie de l’application. Le fuzzing par défaut teste des paramètres génériques en masse, tandis que le fuzzing personnalisé soutenu par GAP cible des paramètres extraits dynamiquement du contexte de l’application. Cette double approche s’avère particulièrement efficace pour découvrir des vecteurs d’attaque insoupçonnés, tout en optimisant le temps et la précision des tests d’intrusion.

3. Cas d’exploitation

Voici un panorama de nos dernières découvertes de paramètres cachés ayant permis de découvrir et d’exploiter des vulnérabilités :

1 – Injection SQL (SQLi), enfin une “feature SQL” visiblement : Paramètre query découvert via waybackurls.

Figure 1: Paramètre découvert via waybackurls 

2 – Bypass d’un contrôle d’accès dans GLPI (CVE-2025-25192), découverte par Mathis Evrard, menant à la désactivation des plugins, la mise à jour forcée et l’activation du mode de débogage : Paramètres continuer ou from_update découverts via l’audit du code source.

Figure 2: Paramètres découverts via le code source

3 – Redirection arbitraire (Open Redirect) : Paramètre back_url non visible découvert via les sources JavaScript.

Figure 3: Paramètre découvert via JavaScript

4 – Redirection arbitraire (Open Redirect) : Paramètre backUrl non visible découvert via les sources JavaScript.

Figure 4: Paramètre découvert via JavaScript

5 – Injection de code (XSS) : Paramètre localisation non référencé découvert via X8 et une wordlist par défaut.

Figure 5: Paramètre découvert via X8

Ces cas concrets démontrent l’impact que peuvent avoir des paramètres cachés non identifiés : chaque découverte a ouvert un vecteur d’attaque réel, parfois grave.

4. Conclusion

L’analyse des paramètres cachés s’avère stratégique en test d’intrusion. C’est souvent là que se nichent des failles peu visibles : fonctionnalités désactivées mais encore actives en back-end, routes d’API oubliées, ou contournements de logique métier. Bien menée, cette analyse révèle des vecteurs d’attaque que ni l’interface ni la documentation ne laissent soupçonner.

Pour assurer la sécurité continue de vos applications web, il est essentiel d’effectuer des tests d’intrusion réguliers, ainsi qu’une revue de code approfondie. Cela permet d’identifier et de corriger les vulnérabilités avant qu’elles ne soient exploitées. Chez Sysdream, nous proposons des prestations complètes de pentest et d’audit de sécurité, adaptées à vos besoins spécifiques, pour vous accompagner dans la détection, la gestion et la réduction des risques liés à vos applications web.