La fuite dans le commentaire : trouver un endpoint de debug caché dans le code source HTML
Le défi
Ce tableau de bord de facturation a l'air propre, mais un développeur a laissé une note dans le HTML qui n'est jamais retirée avant la mise en production. Ouvrez le code source, lisez le commentaire, et soumettez l'endpoint de debug qu'il mentionne.
Ce que tu vas apprendre
- Ouvrir et lire le code source d'une page plutôt que de se fier au rendu affiché
- Reconnaître que les commentaires HTML sont livrés au client et ne sont jamais confidentiels
- Repérer une note TODO de développeur qui révèle un endpoint interne et une clé
- Extraire un chemin d'URL exact à partir d'un texte de commentaire libre
- Expliquer pourquoi les routes de debug et les notes doivent être retirées avant la mise en production
Compétences testées
Prérequis
- Savoir ouvrir le code source d'une page dans un navigateur
- Connaissances de base des chemins d'URL et des query strings
Comment ça marche
Quand un navigateur affiche une page, il vous montre le résultat visuel : titres, texte, boutons. Il ne vous montre pas tout ce qui a transité sur le réseau. Les commentaires HTML, écrits sous la forme <!-- ... -->, sont retirés de l'affichage mais sont envoyés tels quels à chaque visiteur. N'importe qui peut les lire en choisissant Afficher le code source ou en ouvrant la réponse réseau. Ils sont, du point de vue de la sécurité, entièrement publics.
Les développeurs laissent régulièrement des commentaires en guise de rappel : un TODO pour retirer une route de debug, une note sur une fonctionnalité inachevée, parfois même un identifiant. Dans ce challenge, le commentaire indique TODO remove /api/v2/debug?key=DEV-9931 before release - no auth on this route yet. Cette seule ligne révèle trois choses à un attaquant : un endpoint non documenté existe, où il se trouve, et qu'il n'a aucune authentification, en plus d'inclure une clé fonctionnelle. Rien de tout cela n'est visible sur la page, donc un développeur pourrait croire que c'est caché, mais c'est envoyé à tout le monde.
La solution n'est pas de mieux cacher le commentaire. C'est de ne jamais mettre de notes sensibles dans le balisage livré au client. Tout ce que le serveur envoie au navigateur (HTML, commentaires, champs cachés, JavaScript) doit être considéré comme entièrement lisible par l'utilisateur, parce que c'est le cas.
Erreurs fréquentes
- Se fier à la page affichée. Ne regarder que ce que le navigateur affiche en supposant que rien d'autre n'a été envoyé. Les données intéressantes sont dans le code source, pas dans le rendu.
- Ignorer les commentaires. Parcourir le code source à la recherche d'éléments visibles en ignorant les blocs
<!-- -->, alors que c'est exactement là que se trouve la fuite ici. - Soumettre le mauvais fragment. Taper uniquement la clé (
DEV-9931) au lieu du chemin d'endpoint demandé. - Supposer qu'une route cachée est une route sûre. Considérer qu'une route "non liée dans l'interface" est "inaccessible". Le commentaire prouve le contraire.
Comment s'en protéger
Considérez l'intégralité de la réponse HTML comme publique et ne laissez aucun secret ni référence interne s'y glisser. Retirer les commentaires à la compilation et supprimer les routes de debug avant la mise en production est une protection peu coûteuse contre toute cette classe de fuite.
- Retirez les commentaires HTML des builds de production avec votre bundler ou votre moteur de templating.
- N'écrivez jamais d'identifiants, de clés, d'URL internes ou de notes sur des fonctionnalités inachevées dans le balisage, même dans des commentaires.
- Supprimez ou authentifiez les endpoints de debug et internes plutôt que de compter sur le fait qu'ils ne sont pas liés.
- Ajoutez une revue ou un contrôle CI qui fait échouer le build quand un
TODO, des clés, ou des chemins internes apparaissent dans le HTML livré.