glippenBestill test

Synlighet

Slik finner dere filer som ikke skulle ligget ute

En .git-mappe på en webserver lar hvem som helst hente ned hele kildekoden, inkludert alt som noen gang har ligget i historikken. Det er ikke et teoretisk problem: det er et av de mest lønnsomme funnene som finnes, fordi historikken nesten alltid inneholder en nøkkel noen fjernet senere.

Det samme gjelder .env med databasepassord, sikkerhetskopier som ble lagt i webroten «bare midlertidig», og eksportfiler ingen husket å slette.

Alle sjekkene under er lesing av det som allerede ligger åpent. Ingen av dem gjør noe med systemet.

5 steg · omtrent 20 minutter · oppdatert · skrevet av Erik Nilsen

Framgangsmåte

  1. Sjekk om .git ligger ute

    Den avgjørende filen er .git/HEAD. Ligger den der, ligger som regel resten også.

    curl -sI https://example.no/.git/HEAD

    Riktig svar404 eller 403 er riktig svar. Kommer det 200, må dere gå videre til siste steg med en gang: kildekoden er offentlig, og det har den vært en stund.

  2. Sjekk de vanlige filnavnene

    De samme navnene går igjen overalt. Sjekk dem én for én og se etter 200-svar.

    for f in .env .env.local config.json backup.sql dump.sql .DS_Store; do
  printf '%s: ' "$f"
  curl -s -o /dev/null -w '%{http_code}\n' "https://example.no/$f"
done

    Riktig svar404 på alle. Alt annet enn 404 eller 403 er verdt å se nærmere på, også en 200 med en tom side.

  3. Se hva som allerede er indeksert

    Er filen funnet av en søkemotor, er den ikke lenger deres problem alene. Søk på site:example.no sammen med filtypen i en vanlig søkemotor.

    Sjekk også om domenet ligger i offentlige arkiver av gamle sider. En fil som er fjernet i dag kan fortsatt være lesbar der.

  4. Steng det igjen på riktig sted

    Blokker skjulte mapper i webserveren, ikke i applikasjonen. En regel i applikasjonen omgås av alt som kommer utenom applikasjonen.

    Best av alt er at filene ikke er der. En utrulling som kopierer arbeidsmappen med .git og alt er årsaken i de fleste tilfeller, og den løses i utrullingen, ikke med en regel.

  5. Hvis noe var eksponert: bytt nøklene, ikke bare fjern filen

    En fil som har ligget ute må regnes som lest. Å fjerne den stopper neste person, ikke den forrige.

    Alt som lå i den byttes: databasepassord, API-nøkler, tokens, signeringsnøkler. Lå det i git-historikken, hjelper det ikke å slette filen i siste commit, for historikken er hele poenget.

    Sjekk deretter loggene for bruk av de gamle nøklene, og se om noe ble brukt av noen andre enn dere.

    Pass påVar det personopplysninger i filen, kan dere ha en meldeplikt til Datatilsynet innen 72 timer. Fristen løper fra dere ble klar over det, ikke fra dere er ferdige med å undersøke.

Feil

Det som faktisk går galt

Ikke de teoretiske feilene. Disse er de vi finner igjen og igjen.

  • Filen fjernet, nøklene beholdt. Den vanligste feilen, og den som koster mest.
  • Blokkering lagt i applikasjonen i stedet for i webserveren.
  • Bare forsiden sjekket. Underdomener, testmiljøer og gamle kampanjesider er der funnene som regel ligger.
  • En regel for .git, men ikke for .env, .svn eller sikkerhetskopier med tilfeldige navn.
  • Ingen som sjekker på nytt etter neste utrulling. Dette kommer tilbake med mindre utrullingen endres.

Sjekk

Vil dere se om det virket

Den gratis sjekken leser dette utenfra sammen med resten av det som er synlig, og sier hva som fortsatt står igjen. Ingen innlogging, ingen e-postadresse.

Kjør den gratis sjekkenSe hva en full test dekker

Videre

Neste veiledning