Bedste fremgangsmåder til opbygning af sikre API'er

af Rakesh Talanki og Vidheer Gadikota

API (applikationsprogrammeringsgrænseflade) designere og udviklere forstår generelt vigtigheden af ​​at overholde designprincipper, mens de implementerer en grænseflade. Ingen ønsker at designe eller implementere et dårligt API!

Alligevel er det undertiden fristende at kigge efter genveje for at nå de aggressive sprint-tidslinjer, komme til målstregen og implementere en API. Disse genveje kan udgøre en alvorlig risiko - usikrede API'er.

Udviklere skal huske at bære hatten på en API-hacker, før de implementeres. Hvis en udvikler forsømmer at identificere sårbarhederne i en API, kan API'et blive en åben gateway for ondsindet aktivitet.

Identificering og løsning af API-sårbarheder

En API kan arbejde for eller imod sin udbyder, afhængigt af hvor godt udbyderen har forstået og implementeret sine API-brugeres krav. Hvis et firma bygger et utroligt sikkert API, kan det ende med at være meget svært at bruge. Der er behov for en fin balance mellem formålet med en API og let forbrug. I denne artikel skal vi undersøge nogle af de API-sårbarheder, vi har fundet gennem vores arbejde som en del af Googles Apigee-team, herunder hvordan disse sårbarheder kan være blevet forhindret.

injektioner

API'er er gateways for virksomheder til digitalt at forbinde med verden. Desværre er der ondsindede brugere, der sigter mod at få adgang til virksomheders backend-systemer ved at injicere utilsigtede kommandoer eller udtryk for at slippe, slette, opdatere og endda skabe vilkårlige data, der er tilgængelige for API'er.

I oktober 2014 annoncerede Drupal for eksempel en SQL-injektionssårbarhed, der gav angribere adgang til databaser, kode og filmapper. Angrebet var så alvorligt, at angribere muligvis har kopieret alle data ud fra klientens websteder. Der er mange typer injektionstrusler, men de mest almindelige er SQL-injektion, RegEx-injektion og XML-injektion. Mere end én gang har vi set API'er gå live uden trusselsbeskyttelse - det er ikke ualmindeligt.

API'er uden godkendelse

En API, der er bygget uden beskyttelse mod ondsindede trusler gennem godkendelse, repræsenterer en API-designfejl, der kan true en organisations databaser. Ignorering af korrekt godkendelse - selv hvis transportlagskryptering (TLS) bruges - kan forårsage problemer. Med et gyldigt mobilnummer i en API-anmodning kunne for eksempel enhver person få personlige e-mail-adresser og enhedsidentifikationsdata. Industristandard stærk godkendelses- og autorisationsmekanismer som OAuth / OpenID Connect sammen med TLS er derfor kritiske.

Følsomme data i det fri

Normalt har operationsteam og andre interne teams adgang til sporingsværktøjer til fejlfindingsproblemer, som muligvis giver et klart overblik over API-nyttelastinformation. Ideelt set krypteres PCI-kortholderdata (CHD) og Personal Health-data (PHI) fra det punkt, hvor data indfanges helt til det sted, hvor data forbruges, skønt det ikke altid er tilfældet.

Med voksende bekymring for API-sikkerhed skal kryptering af følsomme og fortrolige data være en høj prioritet. For eksempel blev der i juni 2016 afsløret en http-proxy-sårbarhed, der gav flere måder for angribere at proxy den udgående anmodning til en valgt server, fange følsomme oplysninger fra anmodningen og få intelligens om interne data. Ud over at bruge TLS er det vigtigt, at API-trafik er beskyttet ved at kryptere følsomme data, implementere datamaskering til sporing / logging og bruge tokenisering til kortoplysninger.

Gentag angreb

En stor potentiel bekymring for virksomhedsarkitekter er den såkaldte "transaktionsafspilning". API'er, der er åbne for offentligheden, står overfor udfordringen med at finde ud af, om de skal stole på indgående anmodninger. I mange tilfælde, selvom en ikke-betroet anmodning fremsættes og afvises, kan API'en høfligt give den - potentielt ondsindede - bruger mulighed for at prøve og prøve igen.

Angribere udnytter denne misplacerede tillid ved at forsøge at afspille eller afspille en legitim brugeranmodning (i nogle tilfælde ved hjælp af brute force-teknikker), indtil de lykkes. I 2016 kom hackere ind på Github-konti via et afspilningsangreb ved at genbruge e-mail-adresser og adgangskoder fra andre onlinetjenester, der var blevet kompromitteret og prøve dem på Github-konti.

Modforholdsregler inkluderer hastighedsbegrænsende politikker til gashåndtering af anmodninger, brug af sofistikerede værktøjer som Apigee Sense til analyse af API-anmodningstrafik og identifikation af mønstre, der repræsenterer uønskede botanmodninger. Yderligere sikkerhedsforanstaltninger til at stymie replay-angreb inkluderer:

  • HMAC, der indeholder tidsstempler for at begrænse gyldigheden af ​​transaktionen til en defineret tidsperiode
  • tofaktorautentisering
  • muliggør en kortvarig adgangstoken ved hjælp af OAuth

Uventede stigninger i API-brug

Det er altid svært at estimere brugen af ​​en API. Et godt eksempel er den app, der kortvarigt bragte National Weather Service API. Denne særlige API havde ikke nogen form for forebyggelse eller spjældmekanisme for trafikstød, så den uventede stigning i trafik ramte direkte backend.

En god praksis er at håndhæve en arrestation i piggtrafik eller en anvendelseskvote pr. App, så backend ikke påvirkes. Dette kan let rulles ud ved hjælp af en sofistikeret API-administrationsplatform med politikker som kvote- og spidsarrest.

Taster i URI

I nogle tilfælde er implementering af API-nøgler til godkendelse og godkendelse god nok. Afsendelse af nøglen som en del af Uniform Resource Identifier (URI) kan imidlertid føre til, at nøglen kompromitteres. Som forklaret i IETF RFC 6819, fordi URI-detaljer kan vises i browser- eller systemlogfiler, kan en anden bruger muligvis se URI'erne fra browserhistorikken, hvilket gør API-nøgler, adgangskoder og følsom dato i API-URI'er let tilgængelige.

Det er sikrere at sende API-nøgler er i meddelelsesautoriseringshovedet, som ikke er logget af netværkselementer. Som tommelfingerregel anbefales brugen af ​​HTTP POST-metoden med nyttelast, der bærer følsomme oplysninger.

Stak spor

Mange API-udviklere bliver trygge ved at bruge 200 til alle succesanmodninger, 404 for alle fejl, 500 for nogle interne serverfejl, og i nogle ekstreme tilfælde 200 med en fejlmeddelelse i kroppen oven på en detaljeret stakespor. En stakesporing kan potentielt blive en informationslækage for en ondsindet bruger, når den afslører underliggende design- eller arkitekturimplementeringer i form af pakkenavne, klassnavne, rammenavne, versioner, servernavne og SQL-forespørgsler.

Angribere kan udnytte disse oplysninger ved at indsende anmodede URL-anmodninger, som forklaret i dette Cisco-eksempel. Det er en god praksis at returnere et "afbalanceret" fejlobjekt med den rigtige HTTP-statuskode, med mindst krævede fejlmeddelelser (r) og "ingen stakespore" under fejlforhold. Dette vil forbedre fejlhåndtering og beskytte API-implementeringsdetaljer fra en angriber. API-gatewayen kan bruges til at omdanne backend-fejlmeddelelser til standardiserede meddelelser, så alle fejlmeddelelser ser ens ud. dette fjerner også udsættelse af backendkodestrukturen.

Hold API'er sikre

Som vi har gennemgået i denne artikel, kan mange potentielle trusler undgås ved at overveje nogle tanker i API-design og etablere styringspolitikker, der kan anvendes på tværs af virksomheden. Det er vigtigt at beskytte API'er mod skadeligt meddelelsesindhold ved at få adgang til og maskere følsomme krypterede data under kørsel og beskytte backend-tjenester mod direkte adgang. En API-sikkerhedsfejl kan have betydelige konsekvenser - men med den rigtige tankegang og styring kan virksomheder gøre sig meget mere sikre.

[Leder du efter at lære mere om API-sikkerhed? Hent din kopi af vores seneste e-bog, inde i API-produktets mindset: Opbygning og styring af sikre API'er.]