Beste praksis for å bygge sikre API-er

av Rakesh Talanki og Vidheer Gadikota

API (applikasjonsprogrammeringsgrensesnitt) designere og utviklere forstår generelt viktigheten av å overholde designprinsipper mens de implementerer et grensesnitt. Ingen ønsker å designe eller implementere et dårlig API!

Likevel er det noen ganger fristende å se etter snarveier for å nå de aggressive sprint-tidslinjene, komme til målstreken og distribuere et API. Disse snarveiene kan utgjøre en alvorlig risiko - usikrede API-er.

Utviklere bør huske å bruke hatten på en API-hacker før de distribuerer. Hvis en utvikler unnlater å identifisere sårbarhetene i en API, kan APIen bli en åpen gateway for ondsinnet aktivitet.

Identifisere og løse API-sikkerhetsproblemer

Et API kan fungere for eller mot leverandøren avhengig av hvor godt leverandøren har forstått og implementert sine API-brukeres krav. Hvis et selskap bygger et utrolig sikkert API, kan det ende veldig vanskelig å bruke. Det må oppnås en fin balanse mellom formålet med en API og brukervennlighet. I denne artikkelen skal vi utforske noen av API-sårbarhetene vi har kommet over gjennom vårt arbeid som en del av Googles Apigee-team, inkludert hvordan disse sikkerhetsproblemene kan ha blitt forhindret.

injeksjoner

API-er er portene for bedrifter å digitalt få kontakt med verden. Dessverre er det ondsinnede brukere som tar sikte på å få tilgang til foretakenes backend-systemer ved å injisere utilsiktede kommandoer eller uttrykk for å slippe, slette, oppdatere og til og med lage vilkårlige data tilgjengelig for API-er.

I oktober 2014 kunngjorde for eksempel Drupal et SQL-injeksjonssårbarhet som ga angripere tilgang til databaser, kode og filkataloger. Angrepet var så alvorlig at angriperne kan ha kopiert all data fra kundenes nettsteder. Det er mange typer injeksjonstrusler, men de vanligste er SQL Injection, RegEx Injection og XML Injection. Mer enn en gang har vi sett APIer gå live uten trusselbeskyttelse - det er ikke uvanlig.

APIer uten autentisering

Et API bygget uten beskyttelse mot ondsinnede trusler gjennom autentisering representerer en API-designfeil som kan true en organisasjons databaser. Å ignorere riktig godkjenning - selv om transportlagskryptering (TLS) brukes - kan føre til problemer. Med et gyldig mobilnummer i en API-forespørsel, for eksempel, kan enhver person få personlige e-postadresser og enhetsidentifikasjonsdata. Bransjestandard sterke autentiserings- og autorisasjonsmekanismer som OAuth / OpenID Connect, sammen med TLS, er derfor kritiske.

Følsomme data i det fri

Normalt har operasjonsteam og andre interne team tilgang til sporverktøy for feilsøkingsproblemer, noe som kan gi et oversikt over informasjon om API-nyttelast. Ideelt sett er PCI-kortholderdata (CHD) og Personlig helse-data (PHI) kryptert fra det punktet hvor data blir fanget helt til der data forbrukes, selv om det ikke alltid er tilfelle.

Med økende bekymring for API-sikkerhet, må kryptering av sensitive og fortrolige data være en topp prioritet. For eksempel ble det i juni 2016 avslørt en http-proxy-sårbarhet som ga flere måter for angripere å proxy-utgående forespørsel til en valgt server, fange sensitiv informasjon fra forespørselen og få intelligens om interne data. Utover å bruke TLS, er det viktig for API-trafikk å være beskyttet ved å kryptere sensitive data, implementere datamasking for sporing / logging og bruke tokenisering for kortinformasjon.

Angrep på nytt

En stor potensiell bekymring for bedriftsarkitekter er den såkalte "transaksjonsspillingen." API-er som er åpne for publikum, står overfor utfordringen med å finne ut om de skal stole på innkommende forespørsler. I mange tilfeller, selv om en ikke-tillitsfull forespørsel blir fremsatt og avslått, kan API-en høflig tillate brukeren - potensielt ondsinnet - å prøve og prøve igjen.

Angripere utnytter denne feilplasserte tilliten ved å prøve å spille av eller spille av en legitim brukerforespørsel (i noen tilfeller ved å bruke brute force-teknikker) til de lykkes. I 2016 kom hackere inn på Github-kontoer via et avspillingsangrep ved å gjenbruke e-postadresser og passord fra andre online tjenester som hadde blitt kompromittert og prøve dem på Github-kontoer.

Forholdsregler inkluderer hastighetsbegrensende retningslinjer for gassforespørsler, bruk av avanserte verktøy som Apigee Sense for å analysere API-forespørselstrafikk, og identifisering av mønstre som representerer uønskede botforespørsler. Ekstra sikkerhetstiltak for å motvirke replayangrep inkluderer:

  • HMAC, som inneholder tidsstempler for å begrense gyldigheten av transaksjonen til en definert tidsperiode
  • tofaktorautentisering
  • muliggjør et kortvarig tilgangstoken ved å bruke OAuth

Uventet økning i API-bruk

Det er alltid vanskelig å estimere bruken av et API. Et godt eksempel er appen som kort fikk ned National Weather Service API. Denne spesielle API-en hadde ikke noen form for forebygging eller spjeldsmekanisme for trafikkstøt, så den uventede økningen i trafikk traff direkte backend.

En god praksis er å håndheve en arrestasjon i piggtrafikk eller en brukskvote per app, slik at backend ikke blir påvirket. Dette kan enkelt rulles ut ved hjelp av en sofistikert API-administrasjonsplattform med retningslinjer som kvote og piggarrest.

Nøkler i URI

For noen brukstilfeller er det å implementere API-nøkler for godkjenning og autorisasjon god nok. Å sende nøkkelen som en del av Uniform Resource Identifier (URI) kan imidlertid føre til at nøkkelen blir kompromittert. Som forklart i IETF RFC 6819, fordi URI-detaljer kan vises i nettleser- eller systemlogger, kan en annen bruker kanskje se URI-er fra nettleserhistorikken, noe som gjør API-nøkler, passord og følsom dato i API-URIs lett tilgjengelig.

Det er tryggere å sende API-nøkler er i meldingsautorisasjonshodet, som ikke er logget av nettverkselementer. Som en tommelfingerregel anbefales bruk av HTTP POST-metoden med nyttelast som fører sensitiv informasjon.

Stabel spor

Mange API-utviklere blir komfortable med å bruke 200 for alle suksessforespørsler, 404 for alle feil, 500 for noen interne serverfeil, og i noen ekstreme tilfeller 200 med en feilmelding i kroppen, på toppen av en detaljert stakkspor. En stakkspor kan potensielt bli en informasjonslekkasje for en ondsinnet bruker når den avslører underliggende design- eller arkitekturimplementeringer i form av pakkenavn, klassenavn, rammenavn, versjoner, servernavn og SQL-spørsmål.

Angripere kan utnytte denne informasjonen ved å sende inn anmodede URL-forespørsler, som forklart i dette Cisco-eksemplet. Det er en god praksis å returnere et "balansert" feilobjekt, med riktig HTTP-statuskode, med minst nødvendige feilmelding (er) og "ingen stakkespore" under feilforhold. Dette vil forbedre feilhåndteringen og beskytte API-implementeringsdetaljer fra en angriper. API-gatewayen kan brukes til å transformere backend-feilmeldinger til standardiserte meldinger slik at alle feilmeldinger ser like ut. Dette eliminerer også eksponering av strukturen for backendkoden.

Hold APIer trygge

Som vi har gjennomgått i denne artikkelen, kan mange potensielle trusler unngås ved å tenke litt på API-design og etablere styringspolitikk som kan brukes over hele bedriften. Det er viktig å beskytte API-er mot skadelig meldingsinnhold ved å få tilgang til og maskere sensitive krypterte data under kjøretid og beskytte backend-tjenester mot direkte tilgang. En API-sikkerhetsfeil kan ha betydelige konsekvenser - men med riktig ettertanke og styring kan virksomheter gjøre seg mye tryggere.

[Ønsker du å lære mer om API-sikkerhet? Få din kopi av vår nylige eBok, inne i API-produktets tankesett: Bygge og administrere sikre API-er.]