Svakhet
Tenant-isolasjon: når én kunde kan se en annen
Tenant-isolasjon er skillet som sikrer at kunder som deler den samme installasjonen av en tjeneste, ikke kan nå hverandres data.
Det er tilgangskontroll ett nivå over brukeren, og konsekvensen er tilsvarende større: én feil her rammer ikke én bruker, men potensielt hele kundelisten.
CWE-639 · Sist oppdatert 2026-08-21
Synlighet
Hva som kan se dette, og hva som ikke kan
Dette er ikke noe en skanning finner, og det er verdt å vite hvorfor.
Dette er usynlig utenfra. En passiv sjekk av domenet sier ingenting om hvordan applikasjonen skiller kundene fra hverandre, og en skanner har ingen måte å vite hvem som skulle hatt tilgang til hva. Feilen er stille også innenfra: alt ser riktig ut for den vanlige brukeren, helt til noen setter opp to kunder og prøver grensen med vilje.
- Gratis ekstern sjekk
- ser det ikke
- Egenvurdering
- ser det ikke
Slik finner vi det
Hvordan denne feilen faktisk avdekkes
Prosessen, ikke fremgangsmåten for å utnytte den.
Tenant-isolasjon er tilgangskontroll på et nivå over brukeren. Spørsmålet er ikke om Kari kan se Pers data, men om alt hos kunde A er utilgjengelig for alle hos kunde B. Det er den samme klassen feil som IDOR, med en konsekvens som er en helt annen: én feil rammer ikke én bruker, men hele kundelisten.
Vi tester det med to kunder vi setter opp selv, ikke med to brukere hos samme kunde. Deretter går vi gjennom det samme som ellers, med ett tillegg: alt som identifiserer en kunde blir kontrollert overalt der det kan komme inn. Feilen sitter sjelden i innloggingen. Den sitter i et sted der kundetilhørigheten ble lest fra noe klienten sendte inn, i stedet for fra sesjonen.
Rapporter, eksporter, søk, vedlegg, varsler og bakgrunnsjobber er der vi finner den oftest. Det er funksjoner som er bygget etter at isolasjonen var på plass, og som henter data på en litt annen måte enn resten.
Integrasjoner mot andre systemer er den andre. Data som går ut til et tredje system og kommer tilbake, har vært utenfor det som håndhever isolasjonen, og kommer ofte tilbake uten den.
Retting
Hva som lukker den
Rammeverksuavhengig først. Detaljene avhenger av hva dere har, og dem tar vi sammen.
Kundetilhørighet leses aldri fra forespørselen
Hvilken kunde en innlogget bruker tilhører, er noe systemet vet fra sesjonen. Kommer det inn som en parameter, en header eller et felt i en forespørsel, kan det endres av den som sender den.
Dette er den enkeltårsaken vi ser oftest, og den er som regel innført med gode hensikter: noen trengte å kunne bytte kontekst, for eksempel for support, og løsningen ble et felt alle kan sende.
Isolasjonen hører hjemme i datalaget
Ligger kontrollen i hver enkelt spørring, er den så sterk som utviklerens hukommelse den dagen spørringen ble skrevet. Det holder en stund, og så kommer det en rapport eller en eksport til.
Det som holder er at kundeavgrensningen ligger i laget alle spørringer går gjennom, slik at en spørring uten avgrensning enten er umulig å skrive eller feiler høylytt. Hvordan det gjøres, avhenger av basen og rammeverket dere har, og det er en av tingene vi går gjennom sammen etterpå.
Se over det som kjører uten en bruker
Bakgrunnsjobber, planlagte oppgaver og administrasjonsverktøy kjører ofte med utvidede rettigheter og uten en innlogget bruker å avgrense mot. Det er en legitim nødvendighet, og det er samtidig stedet der isolasjonen oftest er slått av permanent.
Gå gjennom hver av dem og still ett spørsmål: hvis denne jobben fikk feil kunde-id, hva ville skje. Svaret bør være at den stopper.
Dokumenter at det er prøvd
Selger dere til enterprise eller offentlig sektor, kommer spørsmålet om kundeseparasjon i sikkerhetsskjemaet før eller siden, og det er formulert som et spørsmål om hva dere har gjort for å kontrollere det. Da er en test med to oppsatte kunder og en rapport som sier hva som ble prøvd, et konkret svar der de fleste leverandører har en formulering.
Skal noen rette det nå
Dere har fått et funn om at én bruker kan nå en annens data. Her er rekkefølgen som lukker det for godt, og de tre rettingene som ser riktige ut og ikke er det.
Testes i
Tjenestene som ser etter dette
Prisen står på hver enkelt, og den er den samme uansett hvor mye vi finner.
- App-sjekk
En fokusert førstetest av én webapp eller ett API. Vi logger inn som en vanlig bruker og ser etter det som betyr mest: kan noen nå data eller handlinger de ikke skal.
- Webapp- og API-pentest
Autentisert testing med en vanlig brukerrolle. Vi ser etter det som lar én bruker gjøre noe hen ikke skal.
- Stor webapp / kompleks plattform
Flere roller, flere miljøer, integrasjoner mot andre systemer. Omfanget settes før vi begynner.
Videre