Svakhet
IDOR: når én bruker når en annens data
IDOR er når en applikasjon lar en bruker nå data som tilhører en annen, fordi den bruker en identifikator fra forespørselen uten å kontrollere hvem som spør.
Dette er den vanligste alvorlige feilen i norske webapplikasjoner, og ingen automatisk skanner finner den, fordi den bare synes når man er logget inn som to forskjellige brukere.
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.
Ingen automatisk skanning finner dette, og den gratis eksterne sjekken gjør det heller ikke. En skanner sammenligner det den kan nå mot en katalog over kjente svakheter, og det finnes ingen katalogoppføring for at bruker A ikke skal se fakturaene til bruker B. Den regelen gjelder hos dere og ingen andre steder. Feilen synes bare for noen som er logget inn som to brukere 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.
Feilen finnes bare innenfra, og den finnes bare når noen er logget inn som to forskjellige brukere samtidig. Det er hele grunnen til at den overlever så lenge: den ser ikke ut som noe galt fra utsiden, og den ser ikke ut som noe galt for en vanlig bruker heller.
Fremgangsmåten er kjedelig og systematisk. Vi setter opp to kontoer som ikke skal se hverandres data, går gjennom applikasjonen som den ene, noterer hvert sted der noe blir hentet eller endret på vegne av en bestemt bruker, og kontrollerer deretter om den andre kontoen kommer til det samme stedet. Det er ikke et triks. Det er en liste som blir gått gjennom.
Det som avgjør om vi finner den, er dekningen. En applikasjon har som regel få skjermbilder og mange endepunkter, og feilen sitter nesten alltid i et endepunkt som skjermbildet aldri viser til den som ikke skal ha det. Derfor testes API-et for seg, og ikke bare det brukergrensesnittet som ligger foran.
Vi ser også etter det motsatte av en feil: steder der kontrollen finnes og virker. Det er den delen av rapporten som er verdt noe når noen spør om dere har testet tilgangskontroll, fordi den sier hva som faktisk ble prøvd.
Retting
Hva som lukker den
Rammeverksuavhengig først. Detaljene avhenger av hva dere har, og dem tar vi sammen.
Kontrollen hører hjemme bak, ikke foran
Den vanligste årsaken vi ser er at kontrollen ligger i grensesnittet. Knappen skjules for den som ikke skal ha den, og så antar den bakenforliggende koden at den som spør, har lov, fordi knappen jo var skjult. Et grensesnitt kan ikke håndheve noe. Det bestemmer bare hva som vises.
Kontrollen må skje der data hentes, hver gang, uavhengig av hva som var synlig. Spørsmålet koden må stille er ikke om identifikatoren finnes, men om akkurat denne brukeren har lov til å se akkurat denne raden.
Gjør riktig oppførsel til standarden
Retting sak for sak fungerer dårlig her, fordi feilen sjelden opptrer ett sted. Er den i ett endepunkt, er den som regel i flere, fordi den kom av et mønster noen kopierte.
Det som holder over tid er at kontrollen ligger i noe alle spørringer går gjennom, slik at et nytt endepunkt arver den uten at utvikleren må huske det. Da er glemsel ikke lenger en sårbarhet.
Uforutsigbare identifikatorer er ikke en løsning
Å bytte løpenummer med en tilfeldig verdi gjør det vanskeligere å gjette seg til en annens data, og det er verdt å gjøre. Men det er ikke en tilgangskontroll, det er en forsinkelse. Identifikatorer lekker gjennom lenker, eksporter, integrasjoner og logger.
Bytt gjerne, men bytt i tillegg til kontrollen, ikke i stedet for den.
Bekreft at rettingen traff
En retting som ser riktig ut i koden treffer ikke alltid det som var problemet, og særlig ikke når feilen fantes flere steder. Det er derfor én retest inngår i prisen: dere får skriftlig bekreftet at det faktisk er borte, eller beskjed om at det ikke er det.
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