Bing indekserer private dokumenter

Bing indekserer private dokumenter

Digi kunne nylig melde at: Med en enkel «site:»-kommando dukket det opp 25400 søkeresultater på et fakturahotell som tilhører den norske IT-giganten i søkemotoren Bing. Og rotårsaken skal være at Microsoft sin nettleser "Edge" har endret oppførsel.

Den egentlige rotårsaken her kan heller sies å være manglende sesjonshåndtering, noe som er punkt nr 2OWASP sin topp-10-liste.

Bakgrunnen er at når en bruker går til en nettside med "Edge", blir den URL brukeren besøker sendt til Microsoft sin søkemotor "Bing" for indeksering. Man kan jo anta at dette er en funksjon de har laget for å få tak i mer innhold til søkemotoren sin. I dette tilfellet har brukerne klikket på en link i nettbanken som peker på en faktura lagret i et såkalt fakturahotell. Et fakturahotell er i praksis bare en filserver som lagrer fakturaer og gjør dem tilgjengelig via internett.

I dette scenariet har brukeren i utgangspunktet ingen sesjon mot fakturahotellet. Det betyr at brukeren er ikke logget inn, fakturahotellet vet ikke hvem brukeren er, og brukeren merker sannsynligvis heller ikke at dette er en annen tjeneste enn nettbanken, for brukeren ser dette ut som en felles løsning

Sikkerhetsutfordringen her knytter seg til å balansere to målsetninger mot hverandre: For det første er det nødvendig å gjøre dette så enkelt som mulig for brukeren, det er altså ikke akseptabelt å lage en ny pålogging hvor brukeren må autentiseres til fakturahotellet. For det andre er informasjon i fakturaene privat og sannsynligvis sensitivt, og det er bare den rette mottakeren av fakturaen som skal få lov til å lese den.

Saken i Digi gir få tekniske detaljer om hvordan løsningen var implementert, men man kan jo anta at linkene inn i fakturahotellet var laget på en måte som skulle gjøre dem "umulige å gjette". De kan for eksempel ha inneholdt en lang tilfeldig streng (som i praksis vil være et "passord"), eller at de er gyldige bare midlertidig (som innebærer at det finnes en sesjon som får timeout, men sesjons-id er lagret i url).

Her er det flere punkter som feiler:

  • Man antar (implisitt) av en URL som vises til brukeren i nettbanken kan holdes hemmelig, og velger derfor å legge sesjons-id inn i URL. Dette er eksplisitt nevnt i OWASP sin forklaring av hva "broken session management" betyr:3. Session IDs are exposed in the URL (e.g., URL rewriting).
  • Det er ikke gjort en grundig nok risikovurdering som tar utgangspunkt i at URL inneholder sensitiv informasjon.
  • Det er ingen autentiseringsmekanisme overhode, slik at enhver som får tilgang til URL automatisk har tilgang til informasjonen den peker til.
  • Det er ingen overvåkingsmekanismer som fanger opp at forespørsler kommer fra uvanlige IP-adresser (som tilhører Bing), at de har uvanlig user-agent eller at de kommer uten noen "referer"-header (evt med "referer" som peker på Bing).
  • Hvis nettleseren sender data om din surfing til en søkemotor er dette i beste fall uheldig, i verste fall direkte ulovlig, men det blir feil å si at dette er rotårsaken til problemet. Hvis sikkerheten i systemet ditt er avhengig av at ingen andre gjør noe feil, er det ikke særlig sikkert.

Her er vi egentlig i kjernen av veldig mange sikkerhetsutfordringer på internett: hvis sikkerhet er viktig, kan man aldri stole på klienten. På den annen side: hvis internett skal virke i det hele tatt, er man nødt til å stole på klienten. Utfordringen er å lage systemet slik at man bare trenger å stole på klienten i så liten grad som mulig, og at man er veldig bevisst på hva dette innebærer og hvilke konsekvenser det har.

I denne sammenhengen burde man sørget for å etablere sikkerhetsmekanismer som ikke er avhengig av at klienten ikke gjør feil. Uten å gjøre dette til et komplett kurs i sesjonshåndtering for web-applikasjoner, er det noen generelle retningslinjer for hva som er "rett måte" å håndtere sesjoner på:

  • Brukeren må først autentiseres. I dette tilfellet er det typisk ønskelig at brukeren overføres fra et annet syste inn i fakturahotellet uten å måtte logge på. Dette innebærer at man må ha single sign-on mellom de to applikasjonene, det er noe som typisk løses med en standard protokoll som SAML eller OpenID Connect.
  • Så må det opprettes en sesjon, identifisert med en sesjons-id.
  • Sesjons-id lagres i klienten som en cookie (her finnes det retningslinjer og mekanismer for å gjøre dette på en mest mulig sikker måte)
  • Dersom det fantes en sesjons-id før brukeren logget på, må den byttes ut med en ny sesjons-id opprettet i forbindelse med påloggingen.

Cookies er selvsagt heller ikke garantert sikker, og klienten kan også gjøre feil i håndteringen av disse. Men man har jobbet i over 20 år med å forsøke å gjøre dem sikre nok, og det er det beste vi har akkurat nå.

comments powered by Disqus