Les fuites de clés API ne sont plus inhabituelles, pas plus que les violations qui s'ensuivent. Alors pourquoi les jetons sensibles sont-ils toujours exposés si facilement ?
Pour le savoir, l'équipe de recherche d'Intruder a examiné ce que couvraient réellement les scanners de vulnérabilités traditionnels et a créé une nouvelle méthode de détection secrète pour combler les lacunes des approches existantes.
L'application de cela à grande échelle en analysant 5 millions d'applications a révélé plus de 42 000 jetons exposés dans 334 types de secrets, exposant ainsi une classe importante de secrets divulgués qui ne sont pas bien gérés par les outils existants, en particulier dans les applications à page unique (SPA).
Dans cet article, nous décomposons les méthodes de détection de secrets existantes et révélons ce que nous avons trouvé lorsque nous avons analysé des millions d'applications à la recherche de secrets cachés dans des packages JavaScript.
Méthodes de détection secrètes établies (et leurs limites)
Détection des secrets traditionnels
L'approche traditionnelle et entièrement automatisée de la détection des secrets d'application consiste à rechercher un ensemble de chemins connus et à appliquer des expressions régulières pour correspondre aux formats de secrets connus.
Bien que cette méthode soit utile et puisse détecter certaines expositions, elle présente des limites évidentes et ne détectera pas tous les types de fuites, en particulier celles qui nécessitent que le scanner examine l'application ou s'authentifie.
Un bon exemple est le modèle de jeton d'accès personnel GitLab de Nuclei. Le scanner reçoit une URL de base, par exemple https://portal.intruder.io/, qui crée le modèle :
- Faites une requête HTTP GET à https://portal.intruder.io/
- Inspectez la réponse directe à cette demande unique, ignorer les autres pages et ressources comme les fichiers JavaScript
- Tentative d'identification du modèle d'un jeton d'accès personnel GitLab
- Si vous le trouvez, faites une demande de trace à l'API publique GitLab pour vérifier si le jeton est actif.
- Si actif, veuillez soulever un problème
Il s’agit clairement d’un exemple simple, mais cette approche est efficace. Surtout lorsque les modèles définissent de nombreux chemins où les secrets sont généralement exposés.
Ce format est typique des scanners d'infrastructure, qui n'exécutent généralement pas de navigateur sans interface graphique. Lorsque le scanner reçoit l'URL de base à analyser (par exemple, https://portal.intruder.io), les requêtes ultérieures qu'un navigateur effectuerait (telles que les fichiers JavaScript nécessaires au rendu de la page, par exemple, https://portal.intruder.io/assets/index-DzChsIZu.js) ne seront pas effectuées en utilisant cette approche à l'ancienne.
Tests dynamiques de sécurité des applications (DAST)
Les outils de test dynamique de sécurité des applications (DAST) constituent généralement un moyen plus robuste d'analyser les applications et ont tendance à avoir des fonctionnalités plus complexes, permettant une analyse complète des applications, la prise en charge de l'authentification et une capacité plus large à détecter les faiblesses de la couche application. En fait, les scanners DAST peuvent sembler être le choix naturel pour détecter les secrets dans les interfaces des applications. Rien ne devrait empêcher un scanner DAST de découvrir les fichiers JavaScript disponibles ou d'y rechercher des secrets.
Cependant, ce type d’analyse est plus coûteux, nécessite une configuration étendue et est en fait généralement réservé à un petit nombre d’applications de grande valeur. Par exemple, il est peu probable que vous configuriez un scanner DAST pour chaque application dont vous disposez dans un vaste secteur numérique. De plus, de nombreux outils DAST n'implémentent pas une gamme suffisamment large d'expressions régulières par rapport aux outils de ligne de commande plus populaires.
Cela laisse un vide évident qui devrait être couvert par les scanners d'infrastructure traditionnels, mais ce n'est pas le cas, et selon toute vraisemblance, il ne sera pas non plus couvert par les scanners DAST en raison de limitations de mise en œuvre, de budget et de maintenance.
Tests de sécurité des applications statiques (SAST)
Les outils de test de sécurité des applications statiques (SAST) analysent le code source pour identifier les vulnérabilités et constituent le principal moyen de détecter les secrets avant que le code n'atteigne la production. Ils sont efficaces pour détecter les informations d’identification cryptées et empêcher certains types d’exposition.
Cependant, nous avons constaté que les méthodes SAST ne couvrent pas non plus l'ensemble du problème et, une fois de plus, certains secrets des packages JavaScript sont passés à travers des failles d'une manière qui échapperait à l'analyse statique.
Création d'une vérification de détection secrète pour les packages JavaScript
Lorsque nous avons commencé cette recherche, nous ne savions pas exactement dans quelle mesure ce problème serait courant. Les secrets sont-ils réellement regroupés dans les interfaces JavaScript et est-ce suffisamment répandu pour justifier une approche automatisée ?
Nous n’avons pas entièrement évalué tous les résultats, mais parmi les échantillons que nous avons examinés, nous avons identifié un certain nombre d’expositions à fort impact.
ce que nous avons trouvé
Jetons du référentiel de code
Les expositions les plus impactantes que nous avons identifiées étaient les jetons pour les plateformes de dépôt de code telles que GitHub et GitLab. Au total, nous avons trouvé 688 tokens, dont beaucoup étaient encore actifs et donnaient un accès complet aux référentiels.
Dans un cas, illustré ci-dessous, un jeton d'accès personnel à GitLab a été intégré directement dans un fichier JavaScript. La portée du jeton était de permettre l'accès à tous les référentiels privés au sein de l'organisation, y compris les secrets du pipeline CI/CD pour les services en aval comme AWS et SSH.
Clés API de gestion de projet
Une autre exposition majeure concernait une clé API pour Linear, une application de gestion de projet, intégrée directement dans le code de l'interface utilisateur :
Le jeton exposait l'intégralité de l'instance linéaire de l'organisation, y compris les tickets internes, les projets et les liens vers les services en aval et les projets SaaS.
et plus
Nous identifions les secrets exposés sur un large éventail d'autres services, notamment :
API du logiciel de CAO – accès aux données des utilisateurs, aux métadonnées du projet et aux conceptions de bâtiments, y compris un hôpital
Raccourcisseurs de liens – possibilité de créer et de lister des liens
Plateformes de messagerie – accès aux listes de diffusion, aux campagnes et aux données des abonnés
Webhooks pour les plateformes de chat et d'automatisation – 213 Slack, 2 Microsoft Teams, 1 Discord et 98 Zapier, tous actifs
Convertisseurs PDF – accès à des outils de génération de documents tiers
Plateformes de veille commerciale et d'analyse – accès aux contacts supprimés et aux données de l’entreprise
N'envoie pas tes secrets
Les commandes de changement de vitesse à gauche sont importantes. SAST, l'analyse des référentiels et les garde-fous de l'IDE détectent les problèmes réels et empêchent l'exposition de classes entières. Mais comme le montre cette recherche, elles ne couvrent pas tous les chemins que peut suivre un secret jusqu’à sa production.
Les secrets introduits lors de la construction et du déploiement peuvent contourner ces protections et se retrouver dans le code frontal, bien après le moment où les contrôles de décalage vers la gauche ont déjà été exécutés. Et ce problème ne fera que s’aggraver à mesure que l’automatisation et le code généré par l’IA deviendront plus courants.
C'est pourquoi l'analyse des applications sur une seule page est nécessaire pour détecter les secrets avant qu'ils n'atteignent la production. Nous avons intégré la détection automatisée des secrets SPA dans Intruder afin que les équipes puissent les détecter. Apprendre encore plus.
