Én bruker kan nå data som tilhører en annen
Slik retter dere IDOR og manglende tilgangskontroll
Et IDOR-funn sier at applikasjonen henter noe på vegne av en bestemt bruker uten å kontrollere at det er den brukeren som spør. Rettingen er sjelden vanskelig. Det som er vanskelig, er å rette den ett sted og tro at man er ferdig.
Denne veiledningen er skrevet for den som skal gjøre endringen, ikke for den som bestilte testen. Den inneholder ingen kommandoer, fordi det ikke finnes en kommando som retter tilgangskontroll i noen andres kodebase, og fordi vi ikke publiserer fremgangsmåter for å prøve seg på en applikasjon.
Rekkefølgen under er den vi ville brukt selv. Den begynner med å finne ut hvor mange steder feilen faktisk er, fordi det svaret bestemmer alt annet.
6 steg · omtrent 12 minutter · oppdatert · skrevet av Erik Nilsen
Framgangsmåte
Finn ut om det er ett sted eller et mønster
Før dere retter noe: se på funnet og let etter det samme et annet sted. Et IDOR-funn er nesten alltid et eksempel og ikke en uttømmende liste, fordi feilen kom av at noen kopierte en måte å hente data på som virket.
Søk etter mønsteret, ikke etter endepunktet. Finner dere at det samme oppslaget gjøres uten en eierskapskontroll i fem andre funksjoner, er det de seks som skal rettes, og ikke den ene som sto i rapporten.
Er dere usikre på hvor mange steder det gjelder, er det et av spørsmålene vi går gjennom sammen. Det er raskere for oss å si hvor vi så det samme mønsteret enn for dere å lete etter det i blinde.
Pass påRetter dere bare endepunktet som står i rapporten, kommer retesten til å finne de andre. Det er bedre enn at noen andre gjør det, men det er en runde til.
Flytt avgjørelsen dit dataene hentes
Den vanligste årsaken er at kontrollen ligger i grensesnittet: knappen skjules for den som ikke skal ha den, og koden bak stoler på at den var skjult. Et grensesnitt bestemmer hva som vises, ikke hva som er lov.
Spørsmålet koden må stille står i eierskapet, ikke i identifikatoren. Ikke om raden finnes, men om den som spør har lov til å se akkurat den raden. I praksis betyr det som regel at oppslaget avgrenses på både identifikator og eier i det samme kallet, slik at feil eier gir ingen treff i stedet for et treff man deretter glemmer å kontrollere.
Gjør riktig oppførsel til standarden, ikke til et valg
Ligger kontrollen som en linje hver utvikler må huske å skrive, er den så sterk som hukommelsen til den som skrev det siste endepunktet en fredag ettermiddag.
Det som holder over tid er at avgrensningen ligger i noe alle spørringer går gjennom, slik at et nytt endepunkt arver den uten at noen tenker på det. Hvordan det ser ut avhenger av rammeverket deres, men målet er det samme overalt: å gjøre den utrygge varianten vanskeligere å skrive enn den trygge.
Der det ikke lar seg gjøre, er nest beste løsning at den utrygge varianten er lett å få øye på i en kodegjennomgang.
Rett også det som ikke er en skjerm
Vi finner det oftest i rapporter, eksporter, søk, vedlegg, varsler og bakgrunnsjobber. Det er funksjoner som er bygget etter at tilgangskontrollen kom på plass, og som henter data på en litt annen måte enn resten gjør.
Gå gjennom hver av dem med det samme spørsmålet: hvis denne fikk en identifikator som tilhører noen andre, hva skjer da. Svaret bør være ingenting.
La være å bytte identifikatorer i stedet for å rette
Å erstatte løpenumre med tilfeldige verdier gjør det vanskeligere å gjette seg til andres data, og det er verdt å gjøre uansett. Men det er ikke tilgangskontroll, det er en forsinkelse.
Identifikatorer lekker. De havner i lenker som deles, i eksporter, i integrasjoner, i logger og i støttehenvendelser. Bytt gjerne, men bytt i tillegg til kontrollen.
Pass påDette er den rettingen vi oftest ser levert som ferdig. Den fjerner ikke feilen, den gjør den bare vanskeligere å snuble i.
Skriv ned hva dere gjorde
Noen kommer til å spørre. Er dere leverandør til en større kunde eller til det offentlige, kommer spørsmålet om tilgangskontroll i et sikkerhetsskjema før eller siden, og det er formulert som hva dere har gjort for å kontrollere det.
En kort notis holder: hvilke steder som ble endret, hva endringen var, når retesten ble gjort, og hva den sa. Det er den samme dokumentasjonen som gjør at en fremtidig utvikler forstår hvorfor koden ser ut som den gjør.
Feil
Det som faktisk går galt
Ikke de teoretiske feilene. Disse er de vi finner igjen og igjen.
- Å rette endepunktet i rapporten og ikke lete etter mønsteret. Feilen sitter nesten aldri bare ett sted.
- Å skjule funksjonen i grensesnittet i stedet for å avvise forespørselen. Da er den fortsatt der for alle som ikke bruker grensesnittet.
- Å bytte til uforutsigbare identifikatorer og kalle det ferdig.
- Å teste rettingen som administrator. En administrator har som regel lov til det dere prøver å hindre, så testen bekrefter ingenting.
- Å glemme bakgrunnsjobber og integrasjoner, som ofte kjører med utvidede rettigheter og ingen bruker å avgrense mot.
Sjekk
Vil dere se om det virket
Ingen av de gratis verktøyene kan bekrefte dette. Om en rettelse i tilgangskontroll faktisk lukket hullet, kan hverken leses utenfra eller spørres om: det avgjøres ved å logge inn som to brukere igjen og prøve grensen på nytt. Har dere fått funnet fra oss, inngår én retest innen 30 dager, og da er det nettopp det vi gjør.