Sökmotorer byggdes för att indexera innehåll. Angripare använder dem dock för att indexera dina misstag. Frågan allintext:login filtyp: logg kan se ofarligt ut. I verkligheten är det ett av de enklaste sätten att upptäcka exponerade loggfiler som innehåller autentiseringsflöden, inloggningsuppgifter, tokens och intern infrastrukturdata.
Om Google kan se dessa loggar, kan angripare också det. När de väl är indexerade blir exponering oundviklig. Dessutom, när inloggningsuppgifter visas i en offentligt tillgänglig fil, är intrånget redan igång.
1. Varför allintext:login filetype:log är farligare än det ser ut
En Google-dork är en sökfråga som använder avancerade operatorer för att hitta känsligt eller felkonfigurerat innehåll som indexerats av sökmotorer. Den utnyttjar inte Google. Istället utnyttjar den din exponering.
Den här frågan kombinerar två operatorer:
- allintext: returnerar sidor där alla termer förekommer i brödtexten
- filtyp: logg begränsar resultaten till
.logfiler
Därför:
Betyder: “Visa mig loggfiler som innehåller ordet login. "
Vid första anblicken verkar det trivialt. Men i praktiken återkommer det ofta:
- Offentligt exponerade webbserverloggar
- CI/CD loggar uppladdade som artefakter
- Felsöka loggar av misstag committed till arkiv
- Applikationsloggar med klartextuppgifter
Detta är inte ett sökmotorfel. Istället är det en sårbarhet för dataexponering orsakades av felkonfiguration. Google indexerade helt enkelt det som var offentligt tillgängligt.
2. Vad angripare faktiskt hittar i exponerade loggfiler
När angripare springer allintext:login filtyp: logg, de surfar inte slumpmässigt. De letar efter autentiseringsspår.
2.1 Klartextuppgifter
Loggar innehåller ofta poster som:
or
Eller till och med SMTP-inloggningsuppgifter:
Att logga autentiseringsnyttolaster är ett av de snabbaste sätten att läcka produktionsuppgifter. Följaktligen kan en enda exponerad loggfil ogiltigförklara hela din åtkomstkontrollmodell.
2.2 Sessionstokens och JWT:er
Även när lösenord inte loggas, görs det ofta tokens.
Till exempel:
En giltig JWT- eller sessionscookie inuti en .log filen kan aktivera:
- Session kapning
- Privilegieupptrappning
- Lateral rörelse över interna system
Med andra ord, tokens i loggar omvandlar felsökningsutdata till en vektor för autentiseringsförbikoppling.
2.3 CI/CD Artefakter
Byggloggar är särskilt farliga. Faktum är att CI/CD System skriver ofta ut miljövariabler under byggsteg.
Angripare upptäcker ofta:
Innehåller rader som:
If CI/CD Artefakter är offentliga, då är hemligheter offentliga. Google-nörden accelererar helt enkelt upptäckten.
2.4 Moln- och infrastrukturdata
Exponerade stockar avslöjar ofta:
- AWS-åtkomstnycklar
- Azure Storage-anslutningssträngar
- Interna tjänst-URL:er
- Databasuppgifter
- Redis-slutpunkter
Även om inloggningsuppgifterna roteras senare, har angriparen nu:
- Kartläggning av infrastruktur
- Namnkonventioner
- Målinformation för framtida attacker
Därför ger exponerade loggar både åtkomst och rekognoscering.
3. Hur dessa loggar blir offentliga från första början
Loggar dyker inte upp magiskt i Google. De blir indexerade eftersom de är offentligt tillgängliga.
3.1 Felkonfigurerade webbservrar
Vanliga mönster inkluderar:
/logs/kataloger som är tillgängliga utan autentisering- Kataloglistning aktiverad
- Nginx eller Apache som serverar rå
.logfiler
Om en logg är nåbar via HTTP är den indexerbar.
3.2 CI/CD Artefaktexponering
Typiska misstag:
- Offentliga artefakter aktiverade i GitHub-åtgärder
- Loggar uppladdade till öppna S3-buckets
- Pipeline spår tillgängliga utan autentisering
A pipeline som lagrar loggar i en offentlig bucket publicerar effektivt sina hemligheter.
3.3 Felsökningsläge i produktion
Standardinställningar i ramverket kan vara farliga:
Dessutom kan överdriven förfrågningsloggning skriva ut:
- Headers
- tokens
- Fullständiga begärandetexter
Felsökningsloggning i produktion omvandlar din applikation till en exportör av autentiseringsuppgifter.
3.4 Docker- och containerloggar
Containeriserade miljöer introducerar nya exponeringsvägar:
- Loggar monterade på delade volymer
- Sidovagnar exporterar loggar till osäkra slutpunkter
- Logga dashboardmed allmänhetens tillgång
Om containerloggar exponeras via HTTP eller öppen lagring är de sökbara. Så småningom indexeras de.
4. Realistiskt attackflöde: Från nörd till inbrott
En typisk attackkedja ser ut så här:
Anfallaren kör:
- Fynd exponerade
.logfil - utdrag:
- JWT-token
- Grundläggande autentiseringsrubrik
- Databasanslutningssträng
Försöker autentisering mot:
- API-slutpunkter
- Administratörspaneler
- Interna tjänster
Om autentiseringen lyckas kan angriparen:
- Eskalera privilegier
- Flytta i sidled
- Få åtkomst till CI/CD
- Kompromittera leveranskedjan
Det som började som en sökfråga blir:
- Session kapning
- Intern ifyllning av referenser
- Pipeline övertagande
- Förgiftning av artefakter
Allt från en offentligt indexerad loggfil.
5. Varför loggning "för mycket" är ett AppSec-problem
Loggning är inte neutral. Istället skapar den en sekundär datalagring.
Om du loggar känsliga data skapar du i praktiken en andra kopia av dina hemligheter.
Loggar exkluderas dock ofta från hotmodellering. Under STRIDE mappas detta tydligt till:
Informationsgivning
Därför, säker SDLC Rutiner bör behandla loggar som:
- Säkerhetsrelevanta artefakter
- Känsliga tillgångar
- Infrastrukturkomponenter som kräver skydd
Om din hotmodell ignorerar loggar är den ofullständig.
6. Hur man förhindrar läckage av autentiseringsuppgifter i loggfiler
6.1 Sluta logga hemligheter
Logga aldrig:
- lösenord
- tokens
- API-nycklar
- Sessions-ID:n
- Auktoriseringsrubriker
Även i felsökningsläge.
Implementera automatisk borttagning när det är möjligt.
6.2 Strukturerad och säker loggning
Använd strukturerad loggning med maskering och filtrering.
Exempel (Node.js):
Exempel (Python):
Nyckelprincipen är enkel: hemligheter får aldrig nå stockvasken.
6.3 Lås logglagring
Säkerhetsåtgärder bör omfatta:
- Inaktivera kataloglista
- Skydda
/logs/sökvägar med autentisering - Begränsa åtkomst till bucket
- Tillämpa lagringspolicyer
- Kryptera loggar i vila
Loggar får aldrig vara offentligt tillgängliga via HTTP.
6.4 CI/CD Guardrails
Manuella granskningar är otillräckliga. Implementera istället automatiserade kontroller:
- Hemlig skanning av loggar före publicering av artefakter
- Misslyckade byggen om tokens upptäcks
- Förhindra uppladdning av artefakter som innehåller inloggningsuppgifter
- Hashvalidering för artefakter
CI/CD bör blockera exponering innan indexering sker.
7. Hur Xygeni förhindrar all-intext:login filtyp: logg Incidenter
Problemet är inte Google-nörden. Problemet är exponering. Därför måste förebyggande åtgärder vidtas innan indexering.
7.1 Hemlighetsdetektering i loggar och artefakter
Xygeni-skanningar:
- Programloggar
- CI/CD jobbspår
- Bygg artefakter
- Docker-lager
- Serialiserade utgångar
Om inloggningsuppgifter, tokens eller känsliga värden visas i .log filer, flaggar Xygeni dem omedelbart.
7.2 CI/CD Guardrails Den där blockexponeringen
Istället för att förlita sig på manuella granskningar, Xygeni upprätthåller säkerheten på pipeline nivå:
Detta:
- Misslyckas med byggen när hemligheter visas i loggar
- Blockerar publicering av artefakter
- Förhindrar oavsiktlig exponering för allmänheten
- Stoppar osäkra sammanslagningar innan de når huvudfilen
Om ett CI-jobb skriver ut en token, pipeline misslyckas.
Ingen indexering.
Ingen exponering.
Ingen incident.
7.3 Skift-vänster-skydd innan Google ser det
Tajming spelar roll.
Istället för att reagera på:
Xygeni stoppar problemet:
- At commit tid
- Under pull request godkännande
- Under pipeline utförande
- Före publicering av artefakter
Om loggen aldrig blir offentlig indexerar Google den aldrig.
Slutgiltig slutsats: Om Google kan indexera det, så har angripare redan gjort det.
Loggar är inte ofarliga. Faktum är att de sällan är tillfälliga. Som standard är de inte privata. Därför bör varje loggfil behandlas som en säkerhetsrelevant tillgång, inte bara som felsökningsutdata.
Om känsliga uppgifter når en .log filen och blir allmänt tillgänglig, den förvandlas omedelbart till en anfallsyta. Dessutom, när den väl indexerats av en sökmotor, ökar exponeringen bortom din kontroll.
Lösningen är inte att stoppa loggning. Snarare är det att logga ansvarsfullt och tillämpa strikta kontroller kring lagring och distribution. Med andra ord måste säkerheten sträcka sig bortom själva applikationen och in i observerbarhetslagret.
Istället:
- Sluta logga hemligheter
- Lås loggförvaring
- driva pipeline guardrails
- Automatisera detektering och policytillämpning
Ytterst, förebyggande åtgärder handlar om timing. För när allintext:login filtyp: logg returnerar din domän, har incidenten redan börjat.
