I motori di ricerca sono stati creati per indicizzare i contenuti. Tuttavia, gli aggressori li usano per indicizzare i tuoi errori. La query tutto il testo:login tipo di file:log Può sembrare innocuo. In realtà, è uno dei modi più semplici per scoprire file di log esposti contenenti flussi di autenticazione, credenziali, token e dati dell'infrastruttura interna.
Se Google può vedere quei log, anche gli aggressori possono farlo. Una volta indicizzati, l'esposizione diventa inevitabile. Inoltre, quando le credenziali compaiono in un file accessibile al pubblico, la violazione è già in atto.
1. Perché allintext:login filetype:log è più pericoloso di quanto sembri
Un "Google dork" è una query di ricerca che utilizza operatori avanzati per individuare contenuti sensibili o non configurati correttamente indicizzati dai motori di ricerca. Non sfrutta Google, ma la tua visibilità.
Questa query combina due operatori:
- tutto il testo: restituisce le pagine in cui tutti i termini appaiono nel corpo del testo
- tipo di file:log limita i risultati a
.logfile
Perciò:
allintext:login filetype:log
Significa: "Mostrami i file di registro che contengono la parola login. "
A prima vista, sembra banale. Tuttavia, nella pratica, spesso restituisce:
- Registri del server web esposti pubblicamente
- CI/CD registri caricati come artefatti
- Debug dei log accidentalmente committed ai repository
- Registri delle applicazioni con credenziali in chiaro
Questo non è un bug del motore di ricerca. Invece, è un vulnerabilità all'esposizione dei dati causato da una configurazione errata. Google ha semplicemente indicizzato ciò che era accessibile al pubblico.
2. Cosa trovano realmente gli aggressori nei file di registro esposti
Quando gli aggressori corrono tutto il testo:login tipo di file:log, non stanno navigando in modo casuale. Stanno cercando tracce di autenticazione.
2.1 Credenziali in chiaro
I registri contengono spesso voci come:
POST /login username=admin password=SuperSecret123or
Authorization: Basic YWRtaW46cGFzc3dvcmQ=
Oppure anche le credenziali SMTP:
smtp_user=mailer
smtp_pass=ProdMailPass!La registrazione dei payload di autenticazione è uno dei modi più rapidi per divulgare le credenziali di produzione. Di conseguenza, un singolo file di log esposto può invalidare l'intero modello di controllo degli accessi.
2.2 Token di sessione e JWT
Anche quando le password non vengono registrate, spesso i token lo sono.
Per esempio:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Set-Cookie: session=abc123xyz789;
Generated API token: sk_live_ABC123SECRETUn cookie JWT o di sessione valido all'interno di un .log il file può abilitare:
- Dirottamento di sessione
- Escalation di privilegi
- Movimento laterale attraverso i sistemi interni
In altre parole, i token nei log trasformano l'output di debug in un vettore di bypass dell'autenticazione.
2.3 CI/CD Artifacts
I registri di costruzione sono particolarmente pericolosi. Infatti, CI/CD i sistemi spesso stampano le variabili di ambiente durante le fasi di compilazione.
Gli aggressori scoprono spesso:
Contenente linee come:
AWS_ACCESS_KEY_ID=AKIA...
DATABASE_URL=postgres://admin:password@internal-db:5432/appIf CI/CD Gli artefatti sono pubblici, quindi i segreti sono pubblici. L'idiota di Google non fa altro che accelerare la scoperta.
2.4 Dati cloud e infrastrutturali
I registri esposti spesso rivelano:
- Chiavi di accesso AWS
- Stringhe di connessione di archiviazione di Azure
- URL dei servizi interni
- Credenziali del database
- Endpoint Redis
Anche se le credenziali vengono ruotate in un secondo momento, l'aggressore possiede ora:
- Mappatura delle infrastrutture
- Convenzioni di denominazione
- Informazioni mirate per attacchi futuri
Pertanto, i registri esposti forniscono sia accesso che ricognizione.
3. Come questi registri diventano pubblici in primo luogo
I log non compaiono magicamente su Google. Vengono indicizzati perché erano accessibili al pubblico.
3.1 Server Web non configurati correttamente
I modelli comuni includono:
/logs/directory accessibili senza autenticazione- Elenco directory abilitato
- Nginx o Apache che servono raw
.logfile
Se un registro è raggiungibile tramite HTTP, è indicizzabile.
3.2 CI/CD Esposizione di artefatti
Errori tipici:
- Artefatti pubblici abilitati in Azioni GitHub
- Registri caricati per aprire i bucket S3
- Pipeline tracce accessibili senza autenticazione
A pipeline che memorizza i log in un bucket pubblico, di fatto ne pubblica i segreti.
3.3 Modalità di debug in produzione
Le impostazioni predefinite del framework possono essere pericolose:
APP_DEBUG=trueInoltre, una registrazione eccessiva delle richieste potrebbe stampare:
- Headers
- Tokens
- Corpi di richiesta completi
La registrazione del debug in produzione trasforma la tua applicazione in un esportatore di credenziali.
3.4 Registri Docker e Container
Gli ambienti containerizzati introducono nuovi percorsi di esposizione:
- Registri montati in volumi condivisi
- Sidecar che esportano i registri verso endpoint non protetti
- Log dashboardcon accesso pubblico
Se i log dei container vengono esposti tramite HTTP o storage aperto, sono ricercabili e, in ultima analisi, indicizzati.
4. Flusso di attacco realistico: da Dork a Breach
Una tipica catena di attacco si presenta così:
L'attaccante esegue:
allintext:login filetype:log- Reperti esposti
.logfiletto - estratti:
- Token JWT
- Intestazione di autorizzazione di base
- Stringa di connessione al database
Tentativi di autenticazione contro:
- Endpoint API
- Pannelli di amministrazione
- Servizi interni
Se l'autenticazione riesce, l'aggressore può:
- Aumentare i privilegi
- Muoviti lateralmente
- accesso a CI/CD
- Compromettere la catena di fornitura
Ciò che è iniziato come una query di ricerca diventa:
- Dirottamento di sessione
- Inserimento di credenziali interne
- Pipeline acquisizione
- Avvelenamento da artefatto
Tutto da un file di registro indicizzato pubblicamente.
5. Perché registrare "troppe cose" è un problema di AppSec
La registrazione non è neutrale. Invece, crea un archivio dati secondario.
Se registri dati sensibili, di fatto crei una seconda copia dei tuoi segreti.
Tuttavia, i log vengono spesso esclusi dalla modellazione delle minacce. In STRIDE, questo corrisponde chiaramente a:
Rivelazione di un 'informazione
Pertanto, sicuro SDLC le pratiche dovrebbero trattare i registri come:
- Artefatti rilevanti per la sicurezza
- Attività sensibili
- Componenti dell'infrastruttura che richiedono protezione
Se il modello di minaccia ignora i log, è incompleto.
6. Come prevenire la perdita di credenziali nei file di registro
6.1 Interrompere la registrazione dei segreti
Non effettuare mai il log:
- Le password
- Tokens
- Chiavi API
- ID di sessione
- Intestazioni di autorizzazione
Anche in modalità debug.
Se possibile, implementare la redazione automatica.
6.2 Registrazione strutturata e sicura
Utilizzare la registrazione strutturata con mascheramento e filtraggio.
Esempio (Node.js):
const logger = require('pino')({
redact: ['req.headers.authorization', 'body.password']
});Esempio (Python):
class RedactFilter(logging.Filter):
def filter(self, record):
record.msg = record.msg.replace("password=", "password=***")
return TrueIl principio fondamentale è semplice: i segreti non devono mai raggiungere il pozzo di raccolta.
6.3 Blocco dell'archiviazione dei registri
I controlli di sicurezza dovrebbero includere:
- Disabilita l'elenco delle directory
- Proteggere
/logs/percorsi con autenticazione - Limita l'accesso al bucket
- Applicare criteri di conservazione
- Crittografa i registri a riposo
I log non devono mai essere accessibili pubblicamente tramite HTTP.
6.4 CI/CD Guardrails
Le revisioni manuali non sono sufficienti. È preferibile implementare controlli automatizzati:
- Scansione segreta dei registri prima della pubblicazione dell'artefatto
- Build fallite se vengono rilevati token
- Impedisci il caricamento di artefatti contenenti credenziali
- Validazione hash per artefatti
CI/CD dovrebbe bloccare l'esposizione prima che avvenga l'indicizzazione.
7. Come Xygeni previene allintext:login filetype:log Incidenti
Il problema non è il nerd di Google. Il problema è l'esposizione. Pertanto, la prevenzione deve avvenire prima dell'indicizzazione.
7.1 Rilevamento di segreti nei registri e negli artefatti
Scansioni Xygeni:
- Log dell'applicazione
- CI/CD tracce di lavoro
- Costruisci artefatti
- Livelli Docker
- Uscite serializzate
Se credenziali, token o valori sensibili vengono visualizzati in .log file, Xygeni li contrassegna immediatamente.
7.2 CI/CD Guardrails Che bloccano l'esposizione
Invece di affidarsi a revisioni manuali, Xygeni rafforza la sicurezza presso pipeline livello:
dotnet xygeni enforce --rules secrets,artifacts,logs --fail-on-riskQuesto:
- Fallisce le build quando i segreti appaiono nei log
- Pubblicazione di artefatti bloccati
- Previene l'esposizione accidentale del pubblico
- Arresta le unioni non sicure prima di raggiungere il main
Se un lavoro CI stampa un token, il pipeline non riesce.
Nessuna indicizzazione.
Nessuna esposizione.
Nessun incidente.
7.3 Protezione Maiusc-Sinistra prima che Google la veda
Il tempismo conta.
Invece di reagire a:
allintext:login filetype:logXygeni blocca il problema:
- At commit tempo
- Durante pull request convalida
- Durante pipeline esecuzione
- Prima della pubblicazione dell'artefatto
Se il registro non diventa mai pubblico, Google non lo indicizza mai.
Conclusione: se Google può indicizzarlo, gli aggressori lo hanno già fatto
I log non sono innocui. In effetti, raramente sono temporanei. Per impostazione predefinita, non sono privati. Pertanto, ogni file di log dovrebbe essere trattato come una risorsa rilevante per la sicurezza, non solo come output di debug.
Se i dati sensibili raggiungono un .log file e diventa accessibile al pubblico, si trasforma immediatamente in una superficie di attacco. Inoltre, una volta indicizzati da un motore di ricerca, la visibilità aumenta in modo incontrollato.
La soluzione non è interrompere la registrazione. Piuttosto, è registrare in modo responsabile e applicare controlli rigorosi su archiviazione e distribuzione. In altre parole, la sicurezza deve estendersi oltre l'applicazione stessa e raggiungere il livello di osservabilità.
Piuttosto:
- Smetti di registrare i segreti
- Blocca l'archiviazione dei registri
- imporre pipeline guardrails
- Automatizzare il rilevamento e l'applicazione delle policy
in definitiva, la prevenzione è una questione di tempismo. Perché una volta tutto il testo:login tipo di file:log restituisce il tuo dominio, l'incidente è già iniziato.
