Introduksjon til API-sikkerhet

APIer driver den teknologiske verden om dagen. Det har utviklet seg til å bli en gigantisk økonomi rundt det at leverandører tilgjengeliggjør datasett via API-tjenester. Dette kan også være gunstige veier inn i systemene dine for angripere med skakkjørte moralske kompass eller på oppdrag fra personer med stjerner på skuldrene. Vår oppgave blir derfor å gjøre alt vi kan for at disse rabbagastene skal ha det så vanskelig som mulig på jobb. 

1.0 HTTPS er et must

Hvorfor klarte NSA å sniffe all dataene til Google i pre-Snowden tiden? Fordi Google hadde bare TLS mellom sine tjenester og brukeren (klienten). Internt i Google’s datasentre var det HTTP resten av veien. Alt NSA trengte å gjøre var å sniffe etheren fra et punkt på innsiden og de fikk all informasjon i plaintext. Bare så det er nevnt; når Google fant ut av dette ble det HTTPS på all trafikk både internt og eksternt. 

I Norge i dag er det altfor mange virksomheter som tror at det holder med HTTPS mellom bruker og eksponert tjeneste. Da er det på sin plass å nevne at de fleste angrep kommer fra innsiden. En unnskyldning for å terminere TLS på ytterpunktet er at de bedriver Deep-Packet Inspection, men det er mulig å sette TLS på igjen etterpå slik at all trafikk på interne nettverk også er sikret. 

SSL1/2/3 vs TLS1.0/1.1/1.2/1.3

Folk bruker SSL og TLS som om de har samme betydning. Det er feil. SSL er utdatert og TLS er det vi benytter i dag. Når du hører andre snakke om SSL og TLS mener de som oftest X.509 sertifikater. Disse sertifikatene er et sett med public/private nøkler som er har en gyldighetsperiode og er signert av en CA (Certificate Authority). 

Hvorfor brukes uttrykkene som om de var det samme? Fordi de begge er kryptografiske protokoller for å sette opp en trygg kommunikasjonskanal som HTTPS. Men der slutter også likheten. SSL og TLS har helt forskjellige måter å utføre den initielle koblingen, autentisering av meldinger, og aller viktigst; de er helt forskjellige på hvilke typer kryptografiske algoritmer de støtter. 

SSL (Secure Sockets Layer) ble funnet opp av Netscape og kom ut i 1995. SSL kommer i 3 versjoner og ALLE er sårbare, utdatert og ingen skal lenger være i bruk. 

TLS (Transport  Layer Security) ble funnet opp av Internet Engineering Task Force (IETF) og første versjon kom i 1999. Det er arvtageren til SSL i den grad at den skulle utføre samme oppgave, men på en annerledes og bedre måte. Den mest brukte versjonen er TLS 1.2. Versjon 1.0 og 1.1 ble erklært utdatert (deprecated) i Marsj 2020, grunnet sikkerhetshull. 

2.0 API Nøkler

En API nøkkel er en unik verdi som brukes for å autentisere en bruker for å få tilgang til å gjøre API kall. Vanligste bruksformål er i system-til-system design, men de kan også brukes av menneskelige brukere. En API nøkkel alene er ikke trygg. Den må være i kombinasjon med HTTPS. Men selv om nøkkelen er av stor størrelse og høy entropi og HTTPS er på plass så har API nøkler flere svakheter. Det er ingen måte å vite om nøkkelen er på avveie, det kan være mye jobb å skifte de ut så de har ofte altfor lang levetid. 

3.0 API Gateway

En av de vanligste måtene å sikre APIer på. En sentral tjeneste som fungerer som et Policy Enforcement Point (PEP) som tar seg av autentisering, autorisasjon, ruting, logging og monitorering (mm.). Kommer i både open-source og kommersielle versjoner. 

En API Gateway kan benytte Token basert Autentisering og Autorisasjon. Det vanligste å bruke er OAuth 2.0 med OIDC, som også betyr at man må ha på plass HTTPS på en API Gateway løsning. 

Klient går mot API gateway. Klient blir redirigert til AuthZ server (STS – Secure Token Service) med en token grant type. Klient redirigeres tilbake til API Gateway med Token. API Gateway validerer Tokenet mot AuthZ server (STS server). Hvis Tokenet er godkjent rutes klienten til ønsket API endepunkt. 

Det er også viktig å sette opp to-veis TLS mellom APi Gateway og API endepunktet bak gatewayen. Hvis all autentisering og autorisasjon skjer på gateway og en angriper klarer å komme forbi så er bakomliggende APIer ubeskyttet. Med to-veis TLS vil API kreve at den som kaller autentiserer seg, som krever at det kommer fra en server med korrekt sertifikat/nøkkel, før den får tilgang. Man bør gjøre det samme mellom API Gateway og STS tjenesten.

Det bør også settes opp en WAF (Web Application Firewall) foran API Gateway for å kunne forhindre (D)DoS angrep.  

Guide: Hvordan utføre sikkerhetstesting gjennom hele utviklingsløpet?

Last ned vår guide der sikkerhetsekspert Even Lysen tar deg gjennom hvordan klassifisere applikasjonene, ulike test-teknikker og metrikker for de fem fasene i et utviklingsløp.

Last ned guiden om sikkerhet i utviklingsløpet

4.0 OAuth 2.0

OAuth 2.0 er teknologien som benyttes til autorisering. I motsetning til OAuth 1.0 som var en protokoll, er OAuth 2.0 et meget konfigurerbart rammeverk. OAuth er en åpen standard for delegering av tilganger. Si du vil at en web applikasjon (App A)  skal få tilgang til deler av din informasjon på en annen web løsning (App B). Du ønsker ikke å gi brukernavn og passord til App A, for da har de full tilgang til App B som deg. Med OAuth kan du gi App A et token som gir de bare den tilgangen de trenger, men ikke noe mer uten at du gir de noe info om din brukerkonto. 

4.1 Grant Types

Det er ikke mange som bruker OAuth 1.0 lenger (en av de som gjør det er Twitter), så vi fokuserer på de forskjellige måtene en løsning kan skaffe seg et Access Token.

Alle Grant Typer listet nedenfor krever at klient app pre-registrerer seg på AuthZ server. Klient app får her sin client id. Alle typene, med unntak av Implicit Type, gir også klient applikasjonen en client secret, men det er valgfritt om client secret skal brukes. 

Authorization Code Grant Type

Den vanligste typen for web applikasjoner og desktop applikasjoner som kan spinne opp en nettleser. 

Ressurs-Eier (brukeren) starter prosessen ved å gå til en applikasjon som brukeren ønsker å gi begrenset tilgang til en Ressurs. Applikasjonen som skal få tilgang må være registrert som klient på Autorisasjonsserveren. 

Brukeren blir rutet fra klient applikasjonen til autorisasjonsserveren. Klient applikasjonen sender en Authorization Code Grant request. I kallet sendes client_id som er id for at autorisajonsserver skal identifisere klient app. Klient sender også redirect URI som må samsvare med klient app sin registrerings URI på authz server. Klient Request kan også inneholde Scope som forteller tilgangsnivået den ber om. 

AuthZ server ber bruker skrive inn brukernavn of passord. Ved vellykket login ruter AuthZ server brukeren tilbake til klient applikasjonen med en spesiell kode. Klient app sender koden til AuthZ server. Hvis koden er godkjent sender AuthZ serveren en Access Token og en Refresh Token tilbake til klient applikasjonen.  

Implicit Grant Type

En veldig usikker metode som før i tiden ble brukt av JavaScript web klienter for å tilegne seg et token. 

Klient app ruter brukeren (nettleseren) til AuthZ serveren med en Implicit Grant Type request. AuthZ ber bruker skrive inn brukernavn og passord. Bruker skriver de inn og de blir sendt til AuthZ server. AuthZ server sender et Access token rett til brukerens nettleser i en URI fragment. 

En utfordring her er at AuthZ server ikke verifiserer klient applikasjonen. 

Resource Owner Password Credentials Grant Type

I denne grant typen må brukeren sende sitt brukernavn og passord direkte til klient applikasjonen. Dette benyttes derfor oftest i system-til-system løsninger hvor begge applikasjonene stoler på hverandre. 

Bruker sender brukernavn og passord til klient app, som sender brukerens input pluss sin client id og client secret til AuthZ server og ved vellykket login mottar et Access Token of et Refresh Token tilbake. 

Client Credentials Grant Type

Her blir Klient applikasjonen Ressurs-eier. Klient applikasjonen sender sin client id og client secret til AuthZ server og ved vellykket validering mottatt et Access Token. 

Hvilken Grant Type Skal Man Velge?

Implicit Grant og Resource Owner Password Credentials Grant er ansett som utdaterte og bør ikke brukes. Benytt Authorization Code Grant hvis ressurseren skal nåes på vegne av en menneskelig bruker, og benytt Client Credentials Grant hvis det er system-til-system. 

Les mer: Defensive teknikker for å beskytte applikasjon mot SQL-angrep

4.2 Tokens

OAuth 2.0 støtter flere typer tokens. Du kan lage egne custom tokens eller benytte de to token designene som OAuth 2.0 kommer med. Bearer Tokens og MAC token, men det vanligste er Bearer Token. 

Bearer Token

En ressurs krever at bruker har et gyldig token før den gir tilgang. Det er flere (tre) måter å bruke et Bearer token på, men det vanligste er at Tokenet kommer i Authorization headeren i HTTP Request kallet. Som betyr at denne protokollen er 100% avhengig av HTTPS for å være trygg. Sender man Tokenet over HTTP kan det sniffes (plukkes opp) av en MITM (Man in the Middle).

Et Bearer Token kan være en Rreferanse Token eller en såkalt self-contained Token. For at en Ressursserver skal kunne validere et Referanse Token må det gjøres mot Autorisasjonsserveren. Et self-contained Token er i form av en JWT (Json Web Token), og da kan Ressursserveren validere Tokenet selv ved å sjekke signaturen. 

Refresh Token

Authorization Code Grant Type og Resource Owner Password Credentials Grant Type sine Access Tokens kommer med en ekstra token som kalles Refresh Token. Refresh Token kan brukes for å forlenge gyldigheten til Ressurs Eieren sin Access Token uten at de trenger å logge inn på nytt. 

Refresh Tokens har mye lenger levetid enn Access Tokens. Hvis tiden går ut på Refresh Token må Ressurs Eieren logge inn på nytt. Når en Refresh Token brukes for å forlenge Access Token sin levetid kan serveren erstatte klientens Refresh Token med et nytt. 

5.0 OIDC (OpenID Connect)

En av de mest populære løsningene innen federering av identitet i dag er OIDC. OAuth 2.0 tar seg av autorisasjon, og OIDC bygger videre på protokollen og tar seg av autentisering. Akkurat som OAuth 2.0 bygger på OAuth 1.0 men her helt forskjellig, så bygger OpenID Connect på OpenID, og er ganske annerledes. OIDC legger et Identitetslag oppå OAuth 2.0. Når en bruker Autentiserer og Autoriserer seg mot en Token tjeneste som støtter OAuth 2.0 og OIDC mottar brukeren to tokens. Et ID Token fra OIDC tjenesten og et Access Token for OAuth 2.0. ID Token kommer i form av en JWT (JSON Web Token). 

Kort fortalt verifiserer OIDC hvem du er, og OAuth 2.0 sier hva du får lov til etter at du er identifisert.. Autorisasjonsserveren må signere ID Token og kan i tillegg kryptere den. Det er viktig at man signerer før man krypterer. Selve API endepunktet bryr seg ikke veldig om ID, men bare Access Token.

OpenID Connect kan bruke OAuth 2.0 sine grant typer, mens har også egendefinerte Flows for å hente Tokens. Når en OIDC Request sendes til autorisasjonsendepunktet definerer response_type parameter hvilken type flow som skal brukes (Parameteret  grant_type definerer hvilken grant type  som skal brukes når OAuth 2.0 requesten går til Token endepunktet).

En klient applikasjon som ikke er registrert i Autorisasjonsserveren  kan registrere seg dynamisk ved å bruke spesifikasjonen OIDC Dynamic Client Registration. Man kan hente ut brukerdata ved  å spørre om de i første Request, eller ved å hente de fra UserInfo endepunktet senere. 

Authorization Code

Hvis response_type er satt til Code benyttes Authorization Code flow i responsen. Denne fungerer likt som med Authorization Code Grant Type i OAuth 2.0. Response sender tilbake en kode som byttes til en Token. 

Implicit

Implicit flow benyttes når response_type er satt til id_token eller id_token token. Hvis request har response_type id_token sendes et ID Token tilbake i response. Har den id_token token sendes både ID Token og Access Token tilbake i samme response. 

Når id_token settes som response_type har aldri klient applikasjonen tilgang til Access Token. Den kan benytte scope parameter for å spørre om attributter som så legges til på ID Token.

Hybrid

Som navnet tilsier kan hybrid sende tilbake forskjellige besvarelser i responsen avhengig av response_type verdi. Er den satt til code id_token mottar man en authorization code samt en id_token. Er response_type satt til code token mottar man authorization code pluss Access Token for UserInput endepunkter. Og ved code token id_token mottar man alle tre (authorization code, id token og access token).

6.0 JSON Web Signaturer

RFC 7515 beskriver JSON Web Signaturer som følger: JWS representerer innhold som er sikret med digital signatur eller Message Authentication Codes (MACs). Dette gir mottaker mulighet til å validere integriteten på avsender ved å lese signaturen fra en JWS beskyttet header (det støttes flere versjoner av krypteringsalgoritmer). Man validerer signaturen med avsenders offentlige nøkkel. 

7.0 JSON Web Kryptering

Et standard oppsett for utveksling av kryptert data med JSON struktur og Base64 enkoding. Det er den andre standardformatet til en JWT (første er JSON Web Signaturer). Formatet krypterer innholdet og leverer også integritetssjekker. I 2017 ble det oppdaget et alvorlig sikkerhetshull i JWE som gjorde den sårbar for et Bleichenbacher angrep. Dette er et adaptive-chosen-ciphertext angrep og kan i verste fall gjøre at private nøkler faller i hendene på en angriper.  

8.0 Endepunkter

Det er ikke bare tekniske valg man må ta stilling til når man skal utvikle et API. Hvordan man eksponerer sine endepunkter med de tekniske verktøyene er minst like viktig. 

8.1 Synlighet 

Selv om noen har en tendens til å klundre med å finne det rette endepunktet så er det sjelden fakta for en trusselagent. Det finnes nok av verktøy der ute som skanner offentlig tilgjengelige adresser, så skal kallet ha begrenset med brukere må det ha tilgangsstyring på plass. 

Det begynner å komme noen fiffige verktøy som kan generere gode fuzzing teknikker på APIer basert på Swagger dokumentasjonen, så denne bør heller ikke ligge offentlig tilgjengelig. 

8.2 Data og parametere 

En angriper vil forsøke å manipulere alle parametere og kanskje også (ved script kiddies) forsøke brute-force angrep. For å gjøre dette så tidkrevende og komplisert som mulig oppfordres det til å begrense hva brukere kan se så mye som mulig (eks. query strukturer, informasjonsmodeller, systemdata, underliggende teknologi, etc. ) Vurder også kartlegging av data sammen med tilgangsstyring som verifiserer om det respektive APIet faktisk har lov til å kalle nettopp disse dataene. 

8.3 Feilmeldinger

Alltid benytt generiske feilmeldinger som ikke røper informasjon som en angriper kan bruke for å utføre enda nøyaktigere angrep. Gjør det så vanskelig som mulig for en angriper å kartlegge løsningen. 

8.4 Sikkerhetsdesign

Hvis APIet direkte eller indirekte kontakter sensitive data MÅ det gjøres en trusselmodellering og en risiko- og sårbarhetsanalyse. Man kan f.eks. benytte OWASP sine guider for best-practice vedrørende tilgangsstyring, data- og teknologiverbositet,  HTTP metoder etc. Og som alltid; få en uavhengig tredjepart til å penetrasjonsteste APIet for å se hvordan det kan misbrukes direkte eller indirekte for å komme seg inn i andre systemer. 

Les mer: 10 viktige prinsipper for sikkerhetsdesign