Kort sagt: En offentlig .git-mapp uppstår när en webbplats rullas ut med git clone eller git pull direkt i webbroten och webbservern inte spärrar dolda mappar. Då går hela källkoden att hämta tillsammans med versionshistoriken, inklusive tidigare incheckade inloggningsuppgifter. Kontrollera era domäner med ett enkelt anrop, spärra åtkomsten direkt, ställ om driftsättningen till paket utan .git och byt ut inloggningsuppgifter från historiken.
Källkoden att ta med sig
Git är standardverktyget för versionshantering, och för små team ligger det nära till hands att också rulla ut med det: anslut till servern, git pull, klart. Det fungerar tillförlitligt och är snabbt. Men det har en bieffekt som ofta ingen märker.
I projektmappen ligger en dold mapp .git. Den innehåller inte bara den aktuella versionen utan varje fil i varje version som någonsin checkats in, dessutom commit-meddelanden, utvecklarnas namn och e-postadresser och referenser till servrar. Ligger den mappen i webbroten och webbservern levererar den kan vem som helst hämta den.
För angripare är det en gåva. Med källkoden går det att söka efter sårbarheter målinriktat i stället för att gissa dem utifrån. Och i historiken finns ofta saker som sedan länge verkade raderade: ett databaslösenord från begynnelsetiden, en API-nyckel, en testfil med kunddata.
Är er .git-mapp offentlig? Så kontrollerar ni det
Kontrollen tar sekunder och ändrar ingenting. Anropa för varje domän och underdomän en fil som finns i varje Git-repository:
# Väntat: 403 eller 404
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/.git/HEAD
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/.git/config
# På servern: finns det .git-mappar under webbrötterna?
find /var/www /srv/www -maxdepth 4 -type d -name ".git" 2>/dev/null
Status 200 betyder: Mappen är nåbar. Se också upp med undermappar. Ibland ligger repositoryt inte i själva webbroten utan i en tilläggs- eller temamapp som sköts separat med Git.
Kontrollera dessutom staging- och testmiljöer. De uppdateras oftare med Git än produktionen och är ofta nåbara under gissningsbara underdomäner.
Direkt: spärra åtkomsten
Tills driftsättningen är omställd spärrar en regel i webbservern åtkomsten till mappar för versionshantering. En allmän spärr för dolda filer, som beskrivs i Skydda inloggningsuppgifter och .env-filer rätt, täcker det också. Den som bara vill spärra versionshanteringen målinriktat använder en snävare regel:
location ~ /\.(git|svn|hg)(/|$) {
return 404;
}
RedirectMatch 404 /\.(git|svn|hg)(/|$)
Upprepa därefter kontrollen ovan, och det med ett verkligt anrop utifrån: Ett lyckat konfigurationstest säger bara att syntaxen stämmer, inte att regeln slår till före andra regler för statiska filer. För paneler som Plesk eller cPanel för ni in regeln i de avsedda extra direktiven så att den inte går förlorad vid nästa konfigurationsgenerering.
Var mappen nåbar, behandla alla inloggningsuppgifter som någonsin stått i repositoryt som kända. Att bara spärra räcker då inte, värdena måste bytas ut.
Varaktigt: rulla ut utan .git i webbroten
Spärren är ett skydd, inte en lösning. Varaktigt hör versionshanteringen inte hemma på produktionsservern. Beprövade vägar, beroende på er miljö:
| Förfarande | Hur det fungerar | Lämpligt för |
|---|---|---|
| Byggpaket från CI | Pipelinen bygger ett arkiv utan .git, servern packar upp det i en ny releasemapp |
Team med CI/CD |
git archive |
skapar ett arkiv av en version utan versionsdata | små projekt utan pipeline |
rsync med undantag |
överför bara de nödvändiga filerna | klassiska servrar |
| Containerimage | Koden kopieras in i imagen vid bygget, .git utesluts via .dockerignore |
Containerdrift |
En releasemapp per version med en symbolisk länk till den aktuella versionen har ytterligare en fördel: Vid problem kan ni växla tillbaka direkt. För containeruppsättningar beskriver CI/CD: bygg PHP-images automatiskt på nytt hur byggen blir reproducerbara. Där bör man också kontrollera att .git inte hamnar i imagen.
# Exempel: skapa ett paket av en version utan versionsdata
git archive --format=tar.gz -o release.tar.gz HEAD
Fler projektfiler som inte hör hemma i webbroten
Mappen .git är det mest kända exemplet men inte det enda. Den som rullar ut hela projektmappar för med sig fler filer till webbroten som inte har något där att göra:
- Mappar från utvecklingsmiljöer som
.ideaeller.vscode, där tillägg för filuppladdning ibland lagrar serveradresser och inloggningsuppgifter. composer.jsonochcomposer.lock, som avslöjar exakta versioner av alla bibliotek och därmed underlättar sökningen efter kända sårbarheter.- Konfigurationer för tester, byggverktyg och pipelines, som röjer interna värdnamn och förlopp.
- Rester från operativsystem som
.DS_Store, som innehåller fillistor för hela kataloger.
Lösningen är densamma som för .git-mappen: leverera bara det som måste vara offentligt, helst via en egen undermapp som webbrot. Den som ändå ställer om driftsättningen till paket fastställer samtidigt en lista över undantagna filer och kontrollerar den för varje nytt verktyg i projektet.
Om mappen var öppen: kontrollera historik och loggar
Visar det sig att .git-mappen var nåbar går ni fram i den här ordningen:
- Spärra åtkomsten och upprepa kontrollen.
- Sök igenom historiken efter vilka hemligheter som någonsin checkats in: konfigurationsfiler,
.env, nycklar, databasdumpar. - Byt ut inloggningsuppgifter, alla som hittades i steg 2, även om de i dag inte längre står i koden.
- Utvärdera åtkomstloggarna för att se om filer under
/.git/hämtats med status 200 och från vilka adresser. Hur det går till visar Utvärdera webbserverloggar efter ett angrepp. - Granska källkoden målinriktat, för angripare känner nu till den. Kända svagheter bör åtgärdas med förtur.
- Klargör dataskyddet, om personuppgifter låg i historiken, till exempel testexporter. Bedömningen gör ert dataskyddsombud.
Verktyg för att söka efter hemligheter i repositories hör därefter varaktigt hemma i pipelinen. OWASP rekommenderar uttryckligen sådana kontroller, som hook före incheckning och i CI.
Hur hjälper PHP SOS konkret?
- Vi kontrollerar alla era domäner och underdomäner efter nåbara mappar för versionshantering.
- Vi spärrar åtkomsten direkt och ställer om driftsättningen till paket utan versionsdata.
- Vi söker igenom historiken efter hemligheter och följer utbytet av de berörda åtkomsterna.
- Vi utvärderar åtkomstloggarna och dokumenterar om och när data har hämtats.
Dessa åtgärder är en del av vår serverhärdning för PHP-webbservrar.
Vanliga frågor
Hur uppstår en offentlig .git-mapp?
Oftast genom en driftsättning med git clone eller git pull direkt i webbroten. Mappen .git med hela versionshistoriken ligger då bredvid index.php, och utan spärr levererar webbservern dess filer.
Räcker det att radera .git-mappen?
För framtiden ja, för det förflutna nej. Om mappen var nåbar kan innehållet redan ha kopierats. Inloggningsuppgifter som någon gång stod i repositoryt bör ni därför byta ut.
Hjälper det att i efterhand ta bort inloggningsuppgifter ur Git-historiken?
Det förhindrar att nya kopior innehåller dem. Den som redan har hämtat repositoryt har kvar de gamla versionerna. Avgörande är därför utbytet av inloggningsuppgifterna, inte bara omskrivningen av historiken.
Berör det även andra versionshanteringssystem?
Ja. Även mappar som .svn eller .hg innehåller projektdata och bör aldrig vara nåbara i webbroten. En allmän spärr för filer och mappar med punkt i början täcker alla dessa fall.