L'endpoint de la webview : lire une API interne dans le HTML
Le défi
Cet écran à l'intérieur d'une application mobile est en réalité une page web chargée dans une webview. L'application appelle une API interne depuis cet écran, mais n'affiche jamais cette adresse. Ouvrez le code source, trouvez le lien caché vers l'endpoint interne, et soumettez-le.
Ce que tu vas apprendre
- Comprendre que de nombreux écrans d'applications mobiles sont des pages web affichées dans une webview
- Lire le code source HTML d'un écran affiché dans une webview
- Trouver un lien caché qui pointe vers un hôte back-end interne
- Extraire l'URL complète d'un endpoint API interne depuis le code source
- Expliquer pourquoi les endpoints internes ne doivent pas être livrés dans du HTML rendu côté client
Compétences testées
Prérequis
- Notion de base de ce qu'est une webview dans une application mobile
- Familiarité avec les URLs et les noms d'hôte
Comment ça marche
Une part surprenante des écrans d'une application mobile ne sont pas natifs du tout : ce sont des pages web chargées dans une webview, un composant navigateur intégré à l'application. Pour l'utilisateur, cela ressemble à une partie de l'application, mais en coulisses, c'est du HTML, du CSS et du JavaScript, et ce HTML peut être inspecté exactement comme celui de n'importe quel site web.
Pour faire fonctionner ces écrans, les développeurs intègrent souvent des références au back-end avec lequel l'écran communique. Dans ce challenge, l'écran de portefeuille précharge sa configuration depuis un hôte interne au chargement, et l'adresse est stockée dans un lien réglé pour rester invisible : https://api.acme.example/v1/internal/config. Un commentaire dans le code source précise même « webview prefetches config from the internal host on load; do not surface to user. » L'utilisateur ne le voit jamais à l'écran, mais il figure bien dans le texte de la page.
Cela compte parce que les endpoints internes, en particulier ceux nommés comme /internal/config, sont une cible de choix pour un attaquant qui cartographie le back-end d'une application. Les découvrir indique où se trouve la logique réelle. Comme une webview n'est jamais qu'un navigateur, tout ce qui est intégré dans son HTML est aussi exposé que sur un site public : l'enveloppe native n'apporte aucune discrétion.
Erreurs fréquentes
- Supposer que les écrans d'application sont opaques. Traiter un écran mobile comme une boîte noire native alors qu'il s'agit de HTML inspectable.
- Ne lire que les liens visibles. Repérer les liens d'ajout de fonds et d'historique mais manquer le lien interne invisible.
- Soumettre une URL partielle. Omettre le schéma ou l'hôte et taper uniquement
/internal/configau lieu de l'endpoint complet demandé. - Ignorer le commentaire. Passer à côté du commentaire du code source qui confirme le préchargement interne.
Comment s'en protéger
Traitez le HTML d'une webview comme entièrement public et n'y placez aucune adresse interne. L'écran doit communiquer avec le back-end via une couche qui ne révèle ni les noms d'hôte internes ni les routes au client.
- N'intégrez pas d'URLs d'API internes dans le HTML de la webview ou le JavaScript client ; résolvez-les côté serveur.
- Placez les endpoints strictement internes derrière une authentification et des contrôles réseau, afin qu'une adresse divulguée ne suffise pas à les atteindre.
- Retirez les commentaires de développeur et les liens inutilisés des pages webview livrées en production.
- Faites transiter le trafic client par une passerelle publique et gardez les hôtes internes inaccessibles depuis l'appareil.