For de fleste er OWASP Top 10-prosjektet ganske velkjent, og det har som mål å bygge en generell konsensus om hva som er de mest kritiske risikoene assosiert med webapplikasjoner.
Men når vi skal snakke om webapplikasjoner finnes det enormt mange emner under denne paraplyen. Så på noen områder er det relevant å bygge lignende, men mer spesialiserte oversikter.
Der kommer blant annet OWASP Top 10 API Security Risks inn i bildet. Som med OWASP Top 10 hovedprosjektet er Top 10 API Security Risks veldokumentert på OWASP sine egne sider, som man kan finne her.
Hvis du er ny til terminologi innen applikasjons-sikkerhet kan det være nyttig å gjøre seg kjent med forskjellen på autentisering og autorisering (authentication vs authorization), da flere av punktene omhandler disse.
Veldig enkelt forklart er autentisering prosesser som verifiserer en brukers påståtte identitet, altså at du er den du utgir deg for å være. Autorisering er prosesser som avgjør om en bruker skal få tilgang til bestemte tjenester, operasjoner eller informasjon.
For å gi en liten smakebit på funnene som er blitt gjort kan vi dykke ned i de tre øverste punktene.
Topp 3 farer: - Den verste hører vi ikke så mye om
#1: Broken Object Level Authorization
Hvis API-et ditt er sårbart for Broken Object Level Authorization (BOLA) betyr det at angripere vil kunne få tilgang til, og muligens manipulere eller slette, objekter de ikke skal ha tilgang til. Dette skjer gjennom API endepunkter som tar i mot og responderer på kall fra brukeren som inneholder en objekt ID av noe slag, uten å verifisere at brukeren faktisk skal ha tilgang til objektet de oppgir.
Et eksempel kan være API-et til en tenkt webshop, hvor det fins et endepunkt som henter objekter basert på mønsteret "/kvitteringer/{brukerId}/oversikt.json", som i eksempelet viser en bruker alle kvitteringene deres. Hvis jeg for eksempel har brukerId 1337 og endepunktet ikke er sårbart så skal jeg bare ha tilgang til objektet på "/kvitteringer/1337/oversikt.json". Om jeg derimot kan gjøre samme kall men modifiserer det til /kvitteringer/1338/oversikt.json og får ut kvitteringsoversikten til en annen bruker så har vi en BOLA sårbarhet.
En viktig finurlighet å notere seg er at BOLA kun omhandler manglende autorisering på objekt-nivå, ikke at brukere kan ha tilgang til endepunkter og funksjoner de ikke skal ha tilgang til, eksempelvis admin-ekslusive endepunkter. Dette er et eget punkt på listen kalt Broken Function Level Authorization (BFLA).
For å unngå BOLA sårbarheter bør man ha en granulær tilgangskontroll som baserer seg på eksisterende policyer, hierarkier og grupper. Denne tilgangskontrollen må man forsikre at blir benyttet i alle funksjoner som benytter input fra brukere for å aksessere, modifisere eller slette objekter og informasjon i databasen. Mange rammeverk og biblioteker lar deg benytte slik tilgangskontroll, så det kan være nyttig å lese seg opp på hvilke muligheter man har i sin tech stack, samt å verifisere at funksjonene du bruker er anerkjent for å være trygge. OWASP har et eget jukseark på autorisering generelt som er veldig nyttig.
«API-et er sårbart hvis det eksponerer sensitive attributter ved et objekt som ikke burde kunne leses av brukere, og hvis brukere kan legge til, modifisere eller slette verdier i attributter de ikke skal ha tilgang til.»
#2: Broken Authentication
For de som er kjent med den generelle OWASP Top 10 listen omhandler dette punktet det samme som A07:2021 - Identification and Authentication Failures, men gir informasjon og råd som er mer spisset mot API-er.
Broken Authentication inntreffer hvis API-et feiler på å verifisere brukeren sin identitet, autentiseringsprosessen kan forbigås, eller hvis session management feiler. Dette er ganske brede beskrivelser, da det fins mange måter autentisering kan feile på.
Ett veldig enkelt eksempel kan være at brukere får sette svake passord uten MFA, eller at autentiseringsprosessen kan bli brute-forcet, da dette betyr at autentiseringen ikke verifiserer en påstått identitet godt nok. Et annet kan være autentiseringsprosesser som godtar svak eller mangelfull signering av JWT tokens, som for eksempel gjennom å sette {"alg":"none"}.
Når det kommer til å implementere sikker autentisering er dette et ganske bredt tema. Eksempler på viktige ting å gjøre er å gjennomføre en trusselmodellering av alle autentiseringsflytene dine slik at du blir godt kjent med alle ledd og deres potensielle risikoer, samt verifiserer at alle sensitive funksjoner faktisk krever autentisering. I likhet til autorisering har OWASP et nyttig jukseark på dette emnet også.
Nå må du forklare Apple API-bruken
#3: Broken Object Property Level Authorization
Hvis du syns denne høres ganske lik ut som det første punktet på listen så er du inne på noe. Ettersom denne sårbarheten omhandler det samme problemet.
Men i stedet for å gjelde uønsket tilgang til objekter, så handler dette om uønsket tilgang til attributter ved et objekt. API-et er sårbart hvis det eksponerer sensitive attributter ved et objekt som ikke burde kunne leses av brukere, og hvis brukere kan legge til, modifisere eller slette verdier i attributter de ikke skal ha tilgang til.
La oss si at du er en innlogget bruker på en digital markedsplass, og du har lagt ut en gammel krakk til salg. Du har motatt et bud på 200 kr, og du vil hente budet gjennom et GET kall mot /bud/{budId}/hentBud. Hvis denne funksjonen ukritisk returnerer alle attributter ved objektet, så kan det være sårbart hvis objektet har sensitive attributter du ikke skal ha tilgang til å se, som for eksempel ting som "buyerAddress" eller "buyerLegalName". Her er det intensjonelt at du skal ha tilgang til både funksjonen og objektet, og la oss si at brukergrensesnittet kun viser deg kjøperens brukernavn og beløpet på budet, men ved å undersøke selve API responsen fikk du se sensitive attributter du ikke burde ha tilgang til.
Et annet eksempel kan være at du akseptere budet via et POST kall mot /bud/{budId}/bekreft, hvor et kall med legitime parametre er følgende:
{
"accepted": true,
"sellerComment": "Takk for handelen!"
}La oss så kjøre kallet på nytt, men denne gangen med følgende parametre:
{
"accepted": true,
"sellerComment": "For en super handel!"
"bidAmount": 10000
}Hvis kjøperen som egentlig bydde 200 kr nå betaler 10000 kr for krakken så har du fått modifisert en attributt ved objektet du ikke skulle hatt tilgang til, og API-et er sårbart. Dette siste eksempelet kalles for en Mass Assignment sårbarhet.
I likhet med API1:2023 må du ta i bruk en granulær tilgangskontroll som alltid verifiserer at brukeren som ber om et objekts attributt faktisk skal ha tilgang til det. Man bør også unngå generiske funksjoner som for eksempel to_json() som tar med seg alle attributter, og heller bruke funksjoner som eksplisitt definerer hvilke attributter som skal returneres. Det fins flere andre punkter å tenke på, men det fins også her et relevant jukseark å se på for "Mass Assignment"-sårbarheter.
