Hvordan sikrer du APIen din?
Det er en tidsalder for den digitale økonomiens eksplosjon, og massive datamengder sendes gjennom API-er. Business, gaming, utdanning, vær, vitenskap, kunst. . . hva som helst; alt fungerer på APIer. For en verden som er så grunnleggende avhengig av APIer, er det overraskende lite fokus på sikkerhet.
For utviklere er standardinnstillingene til rammeverket nok; eller enda verre, når ingen rammeverk blir brukt, tror de at de følger sikkerhetspraksis. For systemadministratorer er standardsikkerheten som tilbys av deres infrastruktur eller tjenesteleverandør det de er avhengige av.
Ikke et pent syn i det hele tatt, spør du meg.
Kilde: developer.ibm.com
Det er unødvendig å si at det er mye som står på spill, som vi først innser når noe virkelig forferdelig skjer.
Men først ting først. 🙂
Innholdsfortegnelse
Hvorfor sikre API-endepunkter?
Dette må være en enkel sak, ikke sant?
Vi må sikre endepunkter fordi, vel, det er det virksomheten er avhengig av.
Selv om det er et sterkt nok argument i seg selv, ønsker jeg å utvide synspunktet litt og fremheve andre relaterte, men like dødelige konsekvenser.
Forretningstap 📉
Dette er den åpenbare. Hvis noen lykkes med å rote med API-endepunktene dine, vil det få alt til å stoppe. Sikkerhetsbrudd kan også ta mye tid å komme seg fra, noe som betyr selvmord i forretningsmessige termer. Selv om det er sant at de fleste bedrifter sannsynligvis ikke vil bli påvirket av en time eller to med nedetid, er det for noen ikke tillatt.
Se for deg at en valutaveksling er nede i noen minutter!
Overholdelsesproblemer
Å ikke sikre API-ene dine på riktig måte kan føre til alvorlige problemer, avhengig av hvilke geografier eller bransjer du har å gjøre med. For eksempel, hvis du betjener banknæringen (spesielt i EU), vil kostnadene ved å bli oppdaget å betjene med usikre APIer resultere i massive juridiske problemer og problemer med etterlevelse. Så mye at det til og med kan bety slutten på virksomheten din.
Omdømmetap
Å bli hacket er smertefullt nok i seg selv, men hvis nyheter kommer ut offentlig, vil det være et uopprettelig tap for merkevarebildet ditt. For eksempel har Sony blitt hacket noen ganger veldig dårlig nå, og i sikkerhetskretser er selskapet en vits slags.
Selv om det ikke påløper noe faktisk tap av data eller penger, lykke til med å prøve å overbevise de forvirrende kundene dine. 🙂
Oppblåste infrastrukturregninger 💰
Når API-en din kjører på infrastruktur, bruker den ressurser (for det meste båndbredde, CPU og minne). For eksempel, der API-en ikke er ordentlig sikret, og ondsinnede utenforstående er i stand til å samhandle med den, er det mulig for dem å tvinge API-en til å fortsette å gjøre mye meningsløst arbeid (for eksempel kjøre tunge databasespørringer), som kan skyte opp regningene dine av grunner.
På plattformer der automatisk skalering av ressurser er aktivert (som AWS), kan resultatene være sjokkerende (utenfor temaet, men hvis du noen gang blir fanget i en suppe som denne på AWS, forstår de situasjonen og gir seg umiddelbart den oppblåste regningen – i det minste i skrivende stund!).
Teammoralen
Så du tenker kanskje at teamet som lar disse kompromissene skje vil miste moralen over dem. Vel, ikke helt. Det er mulig at kompromissene skyldtes svak infrastruktursikkerhet, noe som vil virke motløs for utviklerne eller omvendt.
Skulle dette skje nok tid, vil du ha en kultur på hendene som du vil angre på å la utvikle.
Konkurrentens gevinster
Så la oss si at det var et brudd, men det var ikke noe faktisk tap. Imidlertid vil konkurrentene dine bruke hendelsen til å tromme opp sitt eget API og hevde hvor mye sikrere deres er (selv om det ikke er det!). Nok en gang, lykke til med å prøve å overbevise markedet. 🙂
Alt i alt er det konsekvenser for sikkerhetsbrudd som går utover å tape penger.
Beste praksis for sikring av API-endepunkter
Heldigvis er det visse enkle å implementere og godt forstått praksis som du kan bruke på API-endepunktene dine for å sikre dem. Her er hva de fleste sikkerhetseksperter anbefaler.
HTTPS alltid 🔒
Hvis API-endepunktene dine lar API-forbrukere snakke over http eller andre ikke-sikre protokoller, utsetter du dem for en stor risiko. Passord, hemmelige nøkler og kredittkortinformasjon kan enkelt bli stjålet mann-i-midten angrepeller packet sniffer-verktøyet kan lese dem som ren tekst.
Så gjør alltid https til det eneste tilgjengelige alternativet. Uansett hvor trivielt et endepunkt kan virke, bør tilkobling over http ikke engang være et alternativ. TLS-sertifikat koster ikke mye; du kan kjøpe for så lite som $20 fra SSL-butikk.
Enveis hashing av passord
Passord bør aldri lagres som ren tekst, da i tilfelle det oppstår et sikkerhetsbrudd, vil alle brukerkontoene bli kompromittert. Samtidig bør symmetrisk kryptering strengt tatt unngås, da enhver angriper som er genial og vedvarende nok vil kunne bryte dem.
Det eneste foreslåtte alternativet er asymmetriske (eller «enveis») krypteringsalgoritmer for lagring av passord. På den måten vil verken en angriper eller noen utvikler eller systemadministrator i selskapet få lese kundepassord.
Sterk autentisering 💪
Nå har nesten alle APIer en form for autentisering, men etter min mening fungerer OAuth2-systemet best. I motsetning til andre autentiseringsmetoder, deler den kontoen din inn i ressurser og tillater kun begrenset tilgang til autentiseringstokenbæreren.
Samtidig er en annen veldig god praksis for å angi tokens til å utløpe hver, for eksempel, 24 timer, slik at de må oppdateres. På denne måten, selv om tokenet ditt blir lekket, er det en sjanse for at 24-timers fristen vil redusere virkningen av bruddet.
Bruk satsbegrensning
Med mindre du har et API som brukes av millioner av mennesker hvert minutt, er det en veldig god idé å håndheve en grense for hvor mange anrop en klient kan foreta til API i et gitt tidsvindu.
Dette er mest for å motvirke roboter, som kan fortsette å sende hundrevis av samtidige forespørsler hvert sekund og få APIen din til å spise opp systemressurser uten god grunn. Alle nettutviklingsrammeverk kommer med en hastighetsbegrensende mellomvare (og hvis ikke, er det ganske enkelt å legge det til via et bibliotek) som tar bare et minutt eller så å sette opp.
Valider inndata
Dette høres ut som en enkel sak, men du vil bli overrasket over hvor mange APIer som faller for dette. Å validere inndata betyr ikke bare å kontrollere at innkommende data er i riktig format, men også at ingen overraskelser er mulig. Et enkelt eksempel er SQL-injeksjon, som kan utslette databasene dine hvis du lar søkestrengene gå forbi med liten eller ingen kontroll.
Et annet eksempel er å validere POST-forespørselsstørrelsen og returnere en riktig feilkode og melding til klienten. Å prøve å akseptere og analysere latterlig store innganger vil bare tjene til å sprenge APIen.
Håndhev IP-adressefiltrering, hvis aktuelt
Hvis du er interessert i B2B-tjenester og API-ene dine brukes av bedrifter fra angitte lokasjoner, bør du vurdere å legge til et ekstra lag med sikkerhet som begrenser IP-adresser som kan få tilgang til API-en din. For hver ny plassering og ny klient må IP-adressen kontrolleres mot den innkommende forespørselen.
Ja, det legger til plager for ombordstigning, men sluttresultatet er mye strammere sikkerhet enn det som ellers kan oppnås.
Verktøy for å øke API-beskyttelsen
Finnes det verktøy som kan hjelpe oss med å skanne sårbarhet, eller enda bedre, tilby den første forsvarslinjen når det gjelder å sikre APIer?
Heldigvis, ja. Det er flere verktøy du kan bruke, men vær oppmerksom på at på slutten av dagen er ingen sikkerhetsstrategi perfekt. Når det er sagt, kan disse verktøyene øke API-sikkerheten mange ganger, så de anbefales.
Metasploit er et ekstremt populært rammeverk med åpen kildekode for penetrasjonstesting av nettapper og APIer. Den kan skanne API-en din på flere forskjellige parametere og gjøre en uttømmende sikkerhetsrevisjon for ulike nivåer av sårbarheter.
For eksempel kan sikkerhetsskanningen utført av Metasploit fortelle deg om API-signaturene dine gir bort de underliggende teknologiene og operativsystemet eller ikke; å skjule dette er ofte halve kampen vunnet i API-sikkerhet.
Mens åpen kildekode-kjernerammeverket generelt er nok, er det utmerkede betalte produkter bygget på toppen av Metasploit som er verdt en titt. Pro-planen er flott hvis du vil ha premium-støtte og vil bruke rammeverket i dybden, men er vanligvis ikke nødvendig hvis teamet ditt er erfarent nok.
AppTrana
AppTranas dedikerte API-beskyttelse funksjoner tilbyr en omfattende risikobasert løsning for å beskytte mot et bredt spekter av API-trusler, inkludert OWASP API topp 10, API-baserte DDoS og botangrep, innebygde trusler, datalekkasje osv. Med ubegrenset automatisert API-skanning støttet med manuell penn- testing, overvåker den kontinuerlig risikopoengsummen din for å styrke sikkerhetsstillingen.
AppTranas API-beskyttelse sikrer den mest omfattende løsningen med kombinasjonen av risikodeteksjon, API-trusselsdeteksjon, API Positive Security-policyer, API-spesifikke DDoS-policyer, API-spesifikke bot-moduler og API Discovery-funksjoner.
API-oppdagelsen sikrer fullstendig innsyn i API-kall, inkludert udokumenterte og skygge-APIer, for å forstå API-angrepsoverflaten. Denne dedikerte API-beskyttelsen samler informasjon om brukerdetaljer, API-bruksatferd, trusselaktivitet, API-anropskart og mer for å vise beskyttelsesstatusen med sanntidsanalyse.
Ved å bruke Indusface AppTrana kan du generere skreddersydde API-spesifikke retningslinjer for å blokkere API-fokusert misbruk i sanntid.
Cloudflare
Ikke bare CDN men Cloudflare tilbyr mange sikkerhetsfunksjoner som WAF, hastighetsbegrensning, DDoS-beskyttelse, som vil være avgjørende for å sikre API-en din mot trusler på nettet.
Invicti
Invicti leveres med en USP for «prøvebasert skanning». I enklere termer er det ofte mulig at uregelmessige nettverksforhold eller mindre kjent API-atferd blir tolket som sikkerhetshull, som senere viser seg å være feil.
Dette sløser med ressurser, ettersom alle sårbarhetene som er rapportert, må skannes manuelt for å bekrefte at de ikke er falske positive. Invicti sier at verktøyet er i stand til å gi deg et sterkt nok proof of concept for rapportene, og fjerner tvil om de svake koblingene som er funnet.
Med selskaper som Sony, Religare, Coca-Cola, Huawei, etc., på kundelisten, kan du være sikker på at disse folkene gjør noe riktig. 🙂
SoapUI Pro
Bygget av SmartBear, SoapUI Pro er en intuitiv og enkel måte å lage API-tester og få nøyaktige, datadrevne rapporter om dem. Den integreres også pent med CI/CD-pipeline, og sørger for at ingen nye kodetilføyelser kompromitterer sikkerheten til API-en din.
SoapUI er i stand til å jobbe med Swagger, OAS og andre populære API-standarder, noe som reduserer tiden for å komme i gang betydelig. Med klienter som Microsoft, Cisco, MasterCard, Oracle, etc., og planer som starter på $659 per år, er dette et verdig verktøy for sikrere APIer.
Okta
Prøve Okta for å gjøre det mulig for utviklerne dine å konsentrere seg om å forbedre brukeropplevelsen samt sikre bedriftsdataene dine effektivt. Den tilbyr OAuth 2.0-autorisasjon og er designet for både mobil- og nettapplikasjoner. Den er også kompatibel med tredjeparts API-administrasjonstjenester.
Bruk Okta til å opprette, revidere og vedlikeholde alle policyene for API-tilgang gjennom brukervennlige og spesialbygde konsoller uten behov for tilpassede koder. Det gir deg ekstra fleksibilitet slik at du ikke trenger å sikre API-ene dine ved å bruke ekstra gateway-forekomster.
Okta omfatter identitetsdrevet policy for å kontrollere ulike typer brukere og tjenester under ett tak. Definer tilgang avhengig av brukerprofiler, nettverk, grupper, samtykke og klienter. Utvid tokens ved hjelp av dynamiske data fra dine interne systemer for å nyte raskere integrasjon og sømløs migrering.
Det letter en sentralisert administrasjon for APIer og lar deg beskytte API-ressurser. Okta fokuserer på sikkerhet ved å la deg sikre tilgang mellom ulike mikrotjenester.
Konklusjon
Det er ingen mangel av API-sikkerhetsverktøy tilgjengelig på markedet, enten det er åpen kildekode, gratis eller kommersielt, eller en kombinasjon av disse.
Prøv noen av dem fra listen og se hva som passer best for dine behov.