Scanner de secrets divulgués

Vous voulez une surveillance continue ? Surveillez-le gratuitement avec myeventwatch — alertes d’expiration et de panne, sans carte.

Ce qui compte comme exposé — et ce qui ne compte pas

Le scanner sonde une liste publiée de chemins connus — /.env et ses variantes courantes, /.git/HEAD et /.git/config, fichiers de configuration, archives de sauvegarde et fichiers de clés — avec de simples requêtes GET publiques, exactement celles qu’un attaquant, un moteur de recherche ou un visiteur curieux pourrait faire. Un chemin ne compte comme exposé que lorsque le contenu de la réponse correspond à ce que ce fichier devrait réellement être : un fichier env doit pouvoir se lire comme des lignes clé–valeur, un HEAD Git doit ressembler à une référence Git. Beaucoup de serveurs répondent 200 à chaque chemin — replis d’applications monopages, pages d’erreur personnalisées, réécritures attrape-tout — et un 200 contenant le HTML de votre page d’accueil n’est pas une fuite. Ces chemins sont listés séparément dans le résultat comme répondu mais non confirmé, pour que vous jugiez vous-même ; cet outil n’appelle jamais fuite un 200 non confirmé, et aucun scanner que vous utilisez ne devrait le faire.

En plus des sondes de fichiers, le scanner récupère la page elle-même et jusqu’à une quinzaine de ses bundles JavaScript et y cherche des formes de secrets connues : identifiants de clés d’accès au cloud, en-têtes de clé privée, affectations génériques de clés API et de jetons, chaînes de connexion à des bases de données et motifs similaires à fort signal. Le code côté client est public par définition — tout ce qui est envoyé à un navigateur peut être lu par chaque visiteur —, donc un identifiant réel trouvé dans un bundle est exposé même si aucun fichier n’était mal configuré. Les trouvailles sont signalées par type, par fichier source et par nombre d’occurrences, avec la valeur masquée à quatre caractères initiaux au maximum : assez pour que vous reconnaissiez de quelle clé il s’agit, jamais assez pour qu’un lecteur du rapport puisse l’utiliser. Le secret complet n’est jamais récupéré, stocké ni affiché dans ce rapport.

Limites, dites clairement

Il s’agit d’une sonde publique, en lecture seule, de chemins connus, et ses limites font partie du résultat. Elle ne demande que les chemins de la liste publiée — un secret dans un fichier au nom inhabituel ne sera pas trouvé. Elle analyse la page d’arrivée et environ quinze bundles de scripts, pas chaque ressource d’un grand site, et elle ne se connecte pas, n’explore pas derrière une authentification, ne devine pas de noms de fichiers et ne teste rien qui ne soit pas déjà accessible par un GET non authentifié. Les analyses sont limitées à 5 par heure et par visiteur et les résultats sont mis en cache 10 minutes, donc une nouvelle analyse dans cette fenêtre peut montrer le verdict en cache. Une analyse dispose aussi d’un budget de temps : quand une cible lente l’épuise, le résultat est marqué partiel et le dit — traitez un résultat propre partiel comme « pas entièrement vérifié », pas comme « propre ».

Si l’analyse trouve quelque chose, l’ordre du travail compte plus que la vitesse de suppression. Faites d’abord tourner l’identifiant — révoquez la clé exposée et émettez-en une nouvelle — car des copies peuvent déjà exister dans des caches, des archives et des mains étrangères ; supprimer le fichier arrête les nouveaux téléchargements mais ne fait rien pour une clé déjà sortie. Retirez ou bloquez ensuite le fichier sur le serveur, purgez les caches CDN et proxy qui pourraient en garder une copie, et examinez vos journaux d’accès à la recherche de récupérations antérieures du même chemin. L’article associé, fichiers .env exposés et clés divulguées, parcourt dans l’ordre le manuel de la première heure qu’utilisent les attaquants et la séquence complète de récupération.

Les contrôles voisins complètent le tableau : l’audit des scripts tiers couvre les scripts externes que vos pages chargent — un risque de chaîne d’approvisionnement différent de celui de vos propres fichiers divulgués — et le contrôle des en-têtes de sécurité note les protections de navigateur que portent vos réponses. Une note sur la méthode : un résultat propre signifie qu’aucun des chemins sondés n’a répondu avec un contenu correspondant et qu’aucun motif de secret connu n’est apparu dans les fichiers analysés, au moment de l’analyse et depuis la position réseau du vérificateur. C’est une preuve sur ces chemins et ces fichiers, pas une garantie sur tout le serveur — gardez les fichiers hors de la racine web dès le départ et relancez l’analyse après chaque changement de déploiement qui touche ce que votre serveur publie.

La liste de sondes, publiée

Questions fréquentes