Søkemotorer ble bygget for å indeksere innhold. Angripere bruker dem imidlertid til å indeksere feilene dine. Spørringen allintext:login filtype:logg kan se harmløst ut. I virkeligheten er det en av de enkleste måtene å oppdage eksponerte loggfiler som inneholder autentiseringsflyter, legitimasjon, tokener og interne infrastrukturdata.
Hvis Google kan se disse loggene, kan angripere også det. Når de er indeksert, blir eksponering uunngåelig. Dessuten, når legitimasjonsinformasjon vises i en offentlig tilgjengelig fil, er bruddet allerede i gang.
1. Hvorfor allintext:login filetype:log er farligere enn det ser ut til
En Google-dork er et søk som bruker avanserte operatorer for å finne sensitivt eller feilkonfigurert innhold indeksert av søkemotorer. Den utnytter ikke Google. I stedet utnytter den eksponeringen din.
Denne spørringen kombinerer to operatorer:
- allintext: returnerer sider der alle termene vises i brødteksten
- filtype:logg begrenser resultatene til
.logfiler
Derfor:
Betyr: «Vis meg loggfiler som inneholder ordet login».
Ved første øyekast virker det trivielt. Men i praksis vender det ofte tilbake:
- Offentlig eksponerte webserverlogger
- CI/CD logger lastet opp som artefakter
- Feilsøkingslogger ved et uhell committed til arkiver
- Applikasjonslogger med klartekstlegitimasjon
Dette er ikke en feil i søkemotoren. Det er snarere en sårbarhet for dataeksponering forårsaket av feilkonfigurasjon. Google indekserte ganske enkelt det som var offentlig tilgjengelig.
2. Hva angripere faktisk finner i eksponerte loggfiler
Når angriperne løper allintext:login filtype:logg, de surfer ikke tilfeldig. De ser etter autentiseringsspor.
2.1 Klartekstlegitimasjon
Logger inneholder ofte oppføringer som:
or
Eller til og med SMTP-legitimasjon:
Logging av autentiseringsnyttelaster er en av de raskeste måtene å lekke produksjonslegitimasjon på. Følgelig kan én enkelt eksponert loggfil ugyldiggjøre hele tilgangskontrollmodellen.
2.2 Økttokener og JWT-er
Selv når passord ikke logges, blir tokener ofte det.
For eksempel:
En gyldig JWT- eller øktinformasjonskapsel inni en .log filen kan aktivere:
- Øktkapring
- Opptrapping av privilegier
- Lateral bevegelse på tvers av interne systemer
Med andre ord, tokener i logger gjør feilsøkingsutdata om til en autentiseringsomgåelsesvektor.
2.3 CI/CD Artifacts
Byggelogger er spesielt farlige. Faktisk, CI/CD Systemer skriver ofte ut miljøvariabler under byggetrinn.
Angripere oppdager ofte:
Inneholder linjer som:
If CI/CD Artefakter er offentlige, og hemmeligheter er offentlige. Google-dork akselererer rett og slett oppdagelsen.
2.4 Sky- og infrastrukturdata
Avslørte logger avslører ofte:
- AWS-tilgangsnøkler
- Azure Storage-tilkoblingsstrenger
- Interne tjeneste-URL-er
- Databaselegitimasjon
- Redis-endepunkter
Selv om legitimasjon roteres senere, har angriperen nå:
- Kartlegging av infrastruktur
- Å navngi stevner
- Målrettet etterretning for fremtidige angrep
Derfor gir eksponerte logger både tilgang og rekognosering.
3. Hvordan disse loggene blir offentlige i utgangspunktet
Logger dukker ikke opp magisk i Google. De blir indeksert fordi de var offentlig tilgjengelige.
3.1 Feilkonfigurerte webservere
Vanlige mønstre inkluderer:
/logs/kataloger tilgjengelige uten autentisering- Katalogoppføring aktivert
- Nginx eller Apache serverer rå
.logfiler
Hvis en logg er tilgjengelig via HTTP, er den indekserbar.
3.2 CI/CD Eksponering av artefakter
Typiske feil:
- Offentlige artefakter aktivert i GitHub-handlinger
- Logger lastet opp til åpne S3-bøtter
- Pipeline spor tilgjengelige uten autentisering
A pipeline som lagrer logger i en offentlig bøtte, publiserer effektivt hemmelighetene sine.
3.3 Feilsøkingsmodus i produksjon
Standardinnstillinger i rammeverket kan være farlige:
I tillegg kan overdreven forespørselslogging skrive ut:
- Headers
- tokens
- Fullstendige forespørselstekster
Feilsøkingslogging i produksjon forvandler applikasjonen din til en legitimasjonseksportør.
3.4 Docker- og containerlogger
Containeriserte miljøer introduserer nye eksponeringsbaner:
- Logger montert i delte volumer
- Sidevogner eksporterer logger til usikrede endepunkter
- Overnatting dashboardmed offentlig tilgang
Hvis containerlogger eksponeres via HTTP eller åpen lagring, er de søkbare. Til slutt blir de indeksert.
4. Realistisk angrepsflyt: Fra nørd til brudd
En typisk angrepskjede ser slik ut:
Angriper løper:
- Funn avdekket
.logfil - Ekstrakter:
- JWT-token
- Grunnleggende autentiseringsoverskrift
- Databasetilkoblingsstreng
Forsøker autentisering mot:
- API-endepunkter
- Adminpaneler
- Interne tjenester
Hvis autentiseringen lykkes, kan angriperen:
- Eskaler privilegier
- Beveg deg sidelengs
- Adgang CI/CD
- Kompromitter forsyningskjeden
Det som startet som et søk blir:
- Øktkapring
- Intern legitimasjonsfylling
- Pipeline overtakelse
- Forgiftning av gjenstander
Alt fra en offentlig indeksert loggfil.
5. Hvorfor det å logge «for mye» er et AppSec-problem
Logging er ikke nøytral. I stedet skaper den en sekundært datalager.
Hvis du logger sensitive data, oppretter du effektivt en andre kopi av hemmelighetene dine.
Logger blir imidlertid ofte ekskludert fra trusselmodellering. Under STRIDE er dette tydelig knyttet til:
Informasjon avsløring
Derfor, sikker SDLC Praksiser bør behandle logger som:
- Sikkerhetsrelevante artefakter
- Sensitive eiendeler
- Infrastrukturkomponenter som krever beskyttelse
Hvis trusselmodellen din ignorerer logger, er den ufullstendig.
6. Slik forhindrer du lekkasje av legitimasjon i loggfiler
6.1 Stopp loggføring av hemmeligheter
Logg aldri:
- passord
- tokens
- API-nøkler
- Økt-ID-er
- Autorisasjonsoverskrifter
Selv i feilsøkingsmodus.
Implementer automatisk skjæring når det er mulig.
6.2 Strukturert og sikker logging
Bruk strukturert logging med maskering og filtrering.
Eksempel (Node.js):
Eksempel (Python):
Hovedprinsippet er enkelt: hemmeligheter må aldri nå vedkummen.
6.3 Lås ned logglagring
Sikkerhetskontroller bør omfatte:
- Deaktiver katalogoppføring
- Beskytt
/logs/stier med autentisering - Begrens tilgang til bøtte
- Bruk oppbevaringsregler
- Krypter logger i ro
Logger må aldri være offentlig tilgjengelige via HTTP.
6.4 CI/CD Guardrails
Manuelle gjennomganger er ikke tilstrekkelige. Implementer heller automatiserte kontroller:
- Hemmelig skanning av logger før publisering av gjenstander
- Mislykkede bygginger hvis tokener oppdages
- Forhindre opplasting av artefakter som inneholder legitimasjon
- Hashvalidering for artefakter
CI/CD bør blokkere eksponering før indeksering skjer.
7. Hvordan Xygeni forhindrer all-intext:login filtype:logg Hendelser
Problemet er ikke Google-dåringen. Problemet er eksponering. Derfor må forebygging skje før indeksering.
7.1 Hemmelig deteksjon i logger og artefakter
Xygeni-skanninger:
- Søknadslogger
- CI/CD jobbspor
- Bygg gjenstander
- Docker-lag
- Serialiserte utganger
Hvis legitimasjon, tokener eller sensitive verdier vises i .log filer, flagger Xygeni dem umiddelbart.
7.2 CI/CD Guardrails Den blokkerende eksponeringen
I stedet for å stole på manuelle vurderinger, Xygeni håndhever sikkerheten på pipeline nivå:
Dette:
- Mislykkes med bygging når hemmeligheter vises i logger
- Blokkerer publisering av artefakter
- Forhindrer utilsiktet offentlig eksponering
- Stopper usikre sammenslåinger før de når hovedlinjen
Hvis en CI-jobb skriver ut et token, pipeline mislykkes.
Ingen indeksering.
Ingen eksponering.
Ingen hendelse.
7.3 Shift-venstre-beskyttelse før Google ser det
Timing er viktig.
I stedet for å reagere på:
Xygeni stopper problemet:
- At commit tid
- Under pull request validering
- Under pipeline gjennomføring
- Før publisering av artefakter
Hvis loggen aldri blir offentlig, indekserer Google den aldri.
Endelig konklusjon: Hvis Google kan indeksere det, har angripere allerede gjort det.
Logger er ikke ufarlige. Faktisk er de sjelden midlertidige. Som standard er de ikke private. Derfor bør hver loggfil behandles som en sikkerhetsrelevant ressurs, ikke bare feilsøkingsutdata.
Hvis sensitive data når en .log filen og blir offentlig tilgjengelig, den blir umiddelbart til en angrepsflate. Dessuten, når den først er indeksert av en søkemotor, skaleres eksponeringen utover din kontroll.
Løsningen er ikke å stoppe logging. Snarere er det å logge ansvarlig og håndheve strenge kontroller rundt lagring og distribusjon. Med andre ord må sikkerheten strekke seg utover selve applikasjonen og inn i observerbarhetslaget.
I stedet:
- Slutt å logge hemmeligheter
- Lås opp logglagring
- Håndheve pipeline guardrails
- Automatiser deteksjon og håndheving av retningslinjer
Til syvende og sist, forebygging handler om timing. Fordi når allintext:login filtype:logg returnerer domenet ditt, har hendelsen allerede begynt.
