Les moteurs de recherche ont été conçus pour indexer le contenu. Cependant, les pirates les utilisent pour indexer vos erreurs. La requête texte intégral :login type de fichier : journal Cela peut paraître inoffensif. En réalité, c'est l'un des moyens les plus simples de découvrir des fichiers journaux exposés contenant des flux d'authentification, des identifiants, des jetons et des données d'infrastructure interne.
Si Google peut consulter ces journaux, les attaquants le peuvent aussi. Une fois indexées, leur divulgation devient inévitable. De plus, lorsque des identifiants apparaissent dans un fichier accessible publiquement, la violation est déjà en cours.
1. Pourquoi tout en texte :login Le type de fichier : log est plus dangereux qu'il n'y paraît.
Une « google dork » est une requête de recherche qui utilise des opérateurs avancés pour localiser du contenu sensible ou mal configuré indexé par les moteurs de recherche. Elle n'exploite pas Google, mais votre vulnérabilité.
Cette requête combine deux opérateurs :
- texte intégral : renvoie les pages où tous les termes apparaissent dans le corps du texte
- type de fichier : journal limite les résultats à
.logfichiers
Donc:
allintext:login filetype:log
Moyens: "Montrez-moi les fichiers journaux qui contiennent le mot login. »
À première vue, cela semble anodin. Cependant, en pratique, cela se reproduit souvent :
- Journaux de serveur web exposés publiquement
- CI/CD journaux téléchargés en tant qu'artefacts
- Journaux de débogage accidentellement committed aux dépôts
- Journaux d'application contenant des identifiants en clair
Il ne s'agit pas d'un bug du moteur de recherche. Il s'agit plutôt d'un vulnérabilité à l'exposition des données Provoqué par une erreur de configuration. Google a simplement indexé ce qui était accessible publiquement.
2. Ce que les attaquants trouvent réellement dans les fichiers journaux exposés
Lorsque les attaquants courent texte intégral :login type de fichier : journalIls ne naviguent pas au hasard. Ils recherchent des traces d'authentification.
2.1 Identifiants en clair
Les journaux contiennent fréquemment des entrées telles que :
POST /login username=admin password=SuperSecret123or
Authorization: Basic YWRtaW46cGFzc3dvcmQ=
Ou même les identifiants SMTP :
smtp_user=mailer
smtp_pass=ProdMailPass!L'enregistrement des données d'authentification est l'un des moyens les plus rapides de divulguer des identifiants de production. Par conséquent, un seul fichier journal exposé peut invalider l'intégralité de votre système de contrôle d'accès.
2.2 Jetons de session et JWT
Même si les mots de passe ne sont pas enregistrés, les jetons le sont souvent.
Par exemple :
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Set-Cookie: session=abc123xyz789;
Generated API token: sk_live_ABC123SECRETUn JWT ou un cookie de session valide à l'intérieur d'un .log Le fichier peut activer :
- Séance de détournement
- Elévation de privilèges
- Mouvement latéral à travers les systèmes internes
Autrement dit, les jetons présents dans les journaux transforment les informations de débogage en un vecteur de contournement d'authentification.
2.3 CI/CD Artefacts
Les journaux de construction sont particulièrement dangereux. En fait, CI/CD Les systèmes affichent souvent les variables d'environnement lors des étapes de compilation.
Les attaquants découvrent fréquemment :
Contenant des lignes telles que :
AWS_ACCESS_KEY_ID=AKIA...
DATABASE_URL=postgres://admin:password@internal-db:5432/appIf CI/CD Les artefacts sont publics, donc les secrets le sont aussi. La requête Google Dork accélère simplement la découverte.
2.4 Données du cloud et de l'infrastructure
Les troncs d'arbres exposés révèlent souvent :
- Clés d'accès AWS
- chaînes de connexion au stockage Azure
- URL des services internes
- Informations d'identification de la base de données
- Points de terminaison Redis
Même si les identifiants sont renouvelés ultérieurement, l'attaquant possède désormais :
- Cartographie des infrastructures
- Conventions de nommage
- Renseignements ciblés pour les attaques futures
Par conséquent, les journaux d'activité exposés permettent à la fois l'accès et la reconnaissance.
3. Comment ces journaux deviennent publics au départ
Les journaux d'événements n'apparaissent pas comme par magie dans Google. Ils sont indexés parce qu'ils étaient accessibles au public.
3.1 Serveurs Web mal configurés
Les modèles courants incluent :
/logs/Répertoires accessibles sans authentification- Liste de répertoires activée
- Nginx ou Apache servant du contenu brut
.logfichiers
Si un journal est accessible via HTTP, il est indexable.
3.2 CI/CD Exposition aux artefacts
Erreurs typiques :
- Artefacts publics activés dans Actions GitHub
- Journaux téléchargés vers des compartiments S3 ouverts
- Pipeline traces accessibles sans authentification
A pipeline Le fait de stocker les journaux dans un compartiment public revient à publier ses secrets.
3.3 Mode débogage en production
Les paramètres par défaut du framework peuvent être dangereux :
APP_DEBUG=trueDe plus, un enregistrement excessif des requêtes peut entraîner l'affichage des éléments suivants :
- En-têtes
- Tokens
- Corps de demande complets
L'activation de la journalisation de débogage en production transforme votre application en un exportateur d'identifiants.
3.4 Journaux Docker et conteneurs
Les environnements conteneurisés introduisent de nouvelles voies d'exposition :
- Journaux montés dans des volumes partagés
- Sidecars exportant des journaux vers des points de terminaison non sécurisés
- Historique dashboards avec accès public
Si les journaux de conteneurs sont accessibles via HTTP ou un stockage ouvert, ils sont consultables. Ils sont ensuite indexés.
4. Déroulement réaliste d'une attaque : de la découverte à la brèche
Une chaîne d'attaque typique ressemble à ceci :
L'attaquant court :
allintext:login filetype:log- Découvertes exposées
.logfilet - Extraits:
- Jeton JWT
- En-tête d'authentification de base
- Chaîne de connexion à la base de données
Tentatives d'authentification auprès de :
- Points de terminaison API
- panneaux d'administration
- Services internes
Si l'authentification réussit, l'attaquant peut :
- Escalader les privilèges
- Se déplacer latéralement
- L’accès CI/CD
- Compromettre la chaîne d'approvisionnement
Ce qui a commencé comme une requête de recherche devient :
- Séance de détournement
- Bourrage interne de justificatifs
- Pipeline prise de contrôle
- Empoisonnement par artefacts
Tout cela provient d'un fichier journal indexé publiquement.
5. Pourquoi la journalisation « excessive » constitue un problème de sécurité des applications
La journalisation n'est pas neutre. Au contraire, elle crée un magasin de données secondaire.
Si vous enregistrez des données sensibles, vous créez de fait une deuxième copie de vos secrets.
Cependant, les journaux d'activité sont souvent exclus de la modélisation des menaces. Dans le cadre de STRIDE, cela correspond clairement à :
Divulgation d'information
Par conséquent, sécurisé SDLC Les pratiques doivent traiter les journaux comme :
- artefacts liés à la sécurité
- Actifs sensibles
- Composantes d'infrastructure nécessitant une protection
Si votre modèle de menaces ignore les journaux, il est incomplet.
6. Comment prévenir les fuites d'identifiants dans les fichiers journaux
6.1 Arrêter la journalisation des secrets
Ne jamais se connecter :
- Les mots de passe
- Tokens
- Clés API
- ID de session
- En-têtes d'autorisation
Même en mode débogage.
Dans la mesure du possible, mettez en œuvre la rédaction automatique.
6.2 Exploitation forestière structurée et sécurisée
Utilisez la journalisation structurée avec masquage et filtrage.
Exemple (Node.js) :
const logger = require('pino')({
redact: ['req.headers.authorization', 'body.password']
});Exemple (Python) :
class RedactFilter(logging.Filter):
def filter(self, record):
record.msg = record.msg.replace("password=", "password=***")
return TrueLe principe fondamental est simple : les secrets ne doivent jamais atteindre le système de journalisation.
6.3 Stockage sécurisé des bûches
Les contrôles de sécurité doivent inclure :
- Désactiver l'affichage du répertoire
- Protéger
/logs/chemins avec authentification - Restreindre l'accès au compartiment
- Appliquer les politiques de rétention
- Chiffrer les journaux au repos
Les journaux ne doivent jamais être accessibles publiquement via HTTP.
6.4 CI/CD Guardrails
Les contrôles manuels sont insuffisants. Il convient plutôt de mettre en place des contrôles automatisés :
- Analyse secrète des journaux avant la publication des artefacts
- Échec de la compilation si des jetons sont détectés
- Empêcher le chargement d'artefacts contenant des informations d'identification
- Validation du hachage des artefacts
CI/CD Il faudrait bloquer l'exposition avant l'indexation.
7. Comment Xygeni empêche tout dans le texte :login type de fichier : journal des incidents
Le problème ne réside pas dans la requête Google, mais dans l'exposition. Il est donc impératif de mettre en place des mesures préventives avant l'indexation.
7.1 Détection de secrets dans les journaux et les artefacts
Scans Xygeni :
- Journaux d'application
- CI/CD traces d'emploi
- Construire des artefacts
- Couches Docker
- Sorties sérialisées
Si des identifiants, des jetons ou des valeurs sensibles apparaissent dans .log Les fichiers sont immédiatement signalés par Xygeni.
7.2 CI/CD Guardrails Ce blocage d'exposition
Au lieu de s'appuyer sur des examens manuels, Xygeni renforce la sécurité à pipeline niveau:
dotnet xygeni enforce --rules secrets,artifacts,logs --fail-on-riskCe:
- Les compilations échouent lorsque des secrets apparaissent dans les journaux.
- Publication d'artefacts de blocs
- Prévient l'exposition accidentelle au public
- Empêche les fusions non sécurisées avant d'atteindre la branche principale.
Si une tâche CI imprime un jeton, le pipeline échoue.
Pas d'indexation.
Aucune exposition.
Aucun incident.
7.3 Protection contre le détournement de compte avant que Google ne le voie
Le timing est important.
Au lieu de réagir à :
allintext:login filetype:logXygeni résout le problème :
- At commit Paisible
- Pendant pull request validation
- Pendant pipeline efficace
- Avant la publication de l'artefact
Si le journal ne devient jamais public, Google ne l'indexe jamais.
Conclusion finale : Si Google peut l’indexer, les attaquants l’ont déjà fait.
Les journaux ne sont pas inoffensifs. En réalité, ils sont rarement temporaires. Par défaut, ils ne sont pas privés. Par conséquent, chaque fichier journal doit être considéré comme un élément important pour la sécurité, et non comme un simple document de débogage.
Si des données sensibles atteignent un .log le fichier devient accessible au public, elle se transforme immédiatement en surface d'attaque. De plus, une fois indexé par un moteur de recherche, l'exposition devient incontrôlable.
La solution n'est pas d'arrêter la journalisation. Il s'agit plutôt de la mettre en œuvre de manière responsable et d'appliquer des contrôles stricts sur le stockage et la distribution. Autrement dit, la sécurité doit s'étendre au-delà de l'application elle-même et englober la couche d'observabilité.
Au lieu:
- Cessez d'enregistrer les secrets
- Stockage de bûches sous clé
- Imposer pipeline guardrails
- Automatiser la détection et l'application des politiques
En fin de compte, La prévention est une question de timing. Car une fois qu'une fois texte intégral :login type de fichier : journal Votre domaine est renvoyé, l'incident a déjà commencé.
