Secrets voyageant avec le paquet: des millions d'applications exposent des jetons dans le navigateur et comment l'arrêter

Les fuites de clés API et de jetons n'étaient plus rares. Ces dernières années, nous avons vu comment des secrets qui devraient rester dans des environnements fermés finissent par circuler dans des dépôts publics, des images de conteneurs et, de plus en plus, dans le propre code qui est envoyé au navigateur. Pourquoi ces fuites continuent-elles de se produire quand il y a tant d'outils et de pratiques pour les éviter? Après avoir étudié comment les différentes approches de détection des secrets fonctionnent et développé un contrôle spécifique pour les paquets JavaScript, le résultat a été surprenant: l'analyse de millions d'applications a trouvé des dizaines de milliers de jetons exposés, dont beaucoup actifs et avec de puissantes permissions.

Les méthodes classiques de recherche de secrets sont souvent basées sur deux piliers : connaître des itinéraires communs où les références peuvent être laissées et appliquer des modèles (habituellement des expressions régulières) qui identifient des formats de jetons connus. Cette technique entièrement automatisée fournit des résultats utiles et rapides, et est celle que de nombreux scanners d'infrastructure utilisent. Cependant, il a une limite évidente: si le moteur de recherche est conforme à la demande de la page racine d'un domaine et ne reproduit pas les demandes d'un navigateur fait - comme télécharger des fichiers JavaScript - beaucoup de secrets ne vont jamais devant le détecteur. Un exemple réel de modèle suivant ce modèle peut être vu dans les dépôts ProjectDiscovery pour Nuclei, où des vérifications sont décrites qui inspectent les réponses directes à des requêtes HTTP spécifiques et agissent en conséquence: Modèle Nuclei pour jetons personnels GitLab.

D'autre part, les tests de sécurité dynamiques (DAST) semblent, en théorie, une bonne option pour détecter les secrets sur le front-end parce qu'ils peuvent émuler la navigation réelle, suivre l'application et comprendre les flux qui nécessitent l'authentification. Dans la pratique, l'exécution du DAST de manière globale est plus coûteuse et nécessite une configuration avancée, tant d'organisations le réservent à un nombre limité d'applications critiques. En outre, tous les scanners DAST n'intègrent pas la même gamme de modèles de détection que les outils spécialisés dans la recherche de secrets.

La vérification statique du code (SAST) est un autre élément de l'arsenal : elle analyse le code source pour empêcher les secrets de venir à la production et est très efficace dans de nombreux scénarios. Mais les faisceaux JavaScript utilisés dans les applications web modernes, en particulier dans les applications à page unique (SPA), peuvent être construits par étapes après analyse statique ou avec des processus de construction qui injectent des variables. Cela permet à de nouveaux secrets d'apparaître dans les artefacts compilés sans passer par les contrôles exécutant SAST, de sorte qu'une analyse purement statique du dépôt ne détecte pas toujours ce qui est finalement servi au client.

Avec ces limitations à l'esprit, une vérification a été conçue pour examiner les paquets JavaScript qui peuvent être téléchargés par un navigateur. Elle a été mise à l'échelle : environ cinq millions d'applications ont été suivies à la recherche de modèles de jetons dans les dossiers servis au client. Le renversement des résultats a dépassé 100 Mo de texte et a publié plus de 42 000 lettres d'identité assorties de 334 différents types de secrets. Les résultats n'ont pas tous été triés manuellement, mais parmi les échantillons vérifiés, les expositions à impact élevé semblaient bien illustrer le problème.

Parmi les cas les plus graves, des jetons ont été détectés pour les plateformes de dépôt de code. Au total, 688 jetons étaient liés à des services tels que GitHub et GitLab, et une partie pertinente restait en vigueur, permettant l'accès aux dépôts privés. Dans un cas particulier, un jeton personnel GitLab était situé dans un fichier JavaScript, accordant de vastes permis organisationnels, y compris des secrets de pipeline et d'accès qui facilitent les mouvements latéraux vers des services tels que l'accès AWS ou SSH. La documentation personnelle officielle de GitLab est un bon point de référence pour comprendre les risques de les exposer: GitLab - Jetons d'accès personnels. De même, GitHub maintient des lignes directrices sur la création et la gestion des jetons qui devraient être connues: GitHub - Jetons d'accès personnels.

Une autre exposition notable a affecté les clés API pour les outils de gestion de projet. Les jetons linéaires étaient situés dans des inserts de code qui vous ont permis de lire des tickets, des projets internes et des liens vers des intégrations qui pourraient à leur tour donner accès à d'autres actifs et services. Au-delà de ces exemples, l'analyse a trouvé des identifiants liés aux API de logiciels de conception assistée par ordinateur, des raccourcis de lien avec la capacité de créer et de lister des URL, des plateformes de marketing par courriel avec accès aux listes et campagnes, des webbooks de plateformes de chat et d'automatisation - y compris des centaines de paramètres actifs de Slack, Microsoft Teams, Discord et Zapier -, des convertisseurs PDF et des outils d'intelligence commerciale qui ont exposé des bases de données de contact. Ces constatations confirment que la zone de risque ne se limite pas à quelques fournisseurs, mais couvre un large éventail d'intégrations et de services.

Quelles leçons pratiques en découlent? Tout d'abord, les mesures de "gauche de fortune" - pour analyser et prévenir dès les premiers stades de développement - restent fondamentales. Les outils SAST, les scanners de dépôt et les plugins IDE détectent de nombreuses mauvaises pratiques avant que le code ne quitte l'environnement de développement. Cependant, ils ne sont pas suffisants par eux-mêmes: tout secret introduit dans les phases de construction ou pendant la configuration de déploiement peut éviter ces commandes et finir emballé dans un paquet servi au navigateur.

Il est donc essentiel d'incorporer des vérifications qui reproduisent le comportement réel d'un client web : télécharger les fichiers JS que l'application délivre, les inspecter à la recherche de motifs de jetons et valider l'activité des identifiants détectés. Cette approche nécessite des mécanismes qui interprètent le même arbre de ressources qu'un navigateur obtient lors du chargement d'un SPA et effectuent également des vérifications automatisées pour déterminer si un jeton demeure valide. La communauté de la sécurité et les guides de bonnes pratiques contiennent des recommandations pour la gestion des secrets - par exemple OWASP Gestion secrète Feuille de chaleur- qu'il convient de s'intégrer aux détections en temps d'exécution.

En ce qui concerne les mesures d'atténuation spécifiques, les organisations devraient, dans la mesure du possible, empêcher tout titre de créance assorti de permis sensibles d'atteindre le client. Au lieu de cela, les applications devraient déléguer des appels aux services sur des serveurs contrôlés, utiliser des proxys de cache de clés, utiliser des jetons de courte durée et appliquer le principe de privilège mineur. En outre, activer et compléter la numérisation des secrets offerts par des fournisseurs comme GitHub - voir votre service de détection secrète - aide à intercepter les fuites dans le code et les artefacts publiés: GitHub - Numérisation secrète.

L'image évolue également en augmentant l'automatisation et l'utilisation du code généré par les outils IA : si les pipelines automatisés ne sont pas configurés pour protéger les secrets, le risque d'introduire des références dans les artefacts compilés augmentera. La solution va en combinant les contrôles statiques dans le flux de développement, les analyses de dépôt, les contrôles pendant la compilation et la détection dynamique qui simulent le téléchargement et l'inspection des paquets qui atteignent le navigateur. Pour les applications SPA spécifiquement, cela implique d'intégrer l'araignée et le téléchargement de ressources statiques dans le processus de sécurité, plutôt que de simplement demander seulement pour la page d'accueil.

La détection et l'élimination des secrets exposés dans les faisceaux n'est pas une tâche insignifiante, mais les preuves montrent qu'il est essentiel : lorsque des millions d'applications ont été analysées, des dizaines de milliers de jetons exposés et des centaines de différents types de secrets sont apparus. Adopter une stratégie multicouche, mettre à jour les processus IC / CD pour éviter d'injecter des références dans des artefacts publics, et exécuter des analyses qui reproduisent l'expérience réelle du navigateur sont des étapes nécessaires pour réduire considérablement ce risque. Si vous souhaitez approfondir les différences entre l'analyse statique et l'analyse dynamique et mieux comprendre quand utiliser chaque technique, les ressources de l'OWASP sur l'analyse de la sécurité sont un bon point de départ: OWASP - Analyse du code source et OWASP - Analyse dynamique.

Bref, le problème est clair : les secrets ne doivent pas se déplacer vers le navigateur, mais avec les processus actuels de construction, de déploiement et d'automatisation qui continuent de se produire. La réponse n'est pas un outil unique mais une combinaison de bonnes pratiques, de contrôles de pipeline et de détection qui inspecte exactement ce que le navigateur télécharge. Ce n'est qu'ainsi que nous pourrons réduire la probabilité qu'un jeton engagé soit la porte d'entrée vers des actifs beaucoup plus précieux.