API-sikkerhed er et af de vigtigste aspekter, du skal tage dig af i næsten enhver applikation.
I dag er API’er den bedste måde at integrere din applikation med andre applikationer. De giver en gateway til din applikation, og derfor skal API’erne være sikre nok, så du ikke får uønskede besøgende.
Lad os se på nogle API-sårbarheder, som kan være en trussel mod din applikation.
Indholdsfortegnelse
Almindelige API-sårbarheder
#1. Cross-site scripting (XSS)
XSS-angreb er almindelige i webapplikationer, men kan også forekomme gennem API’er, hvis de indgående brugerdata ikke er korrekt renset. Angribere kan køre ondsindede scripts på serveren og få adgang til følsomme data.
#2. Takstbegrænsende overtrædelse
Overtrædelsen af den hastighedsbegrænsende funktion i API’et kan give angribere chancen for at bombardere din server med et stort antal anmodninger. Til sidst kan serveren gå ned, og din kundebase kan have svært ved at nå dig.
#3. Forkert godkendelse
Hvis API’en ikke er korrekt konfigureret ved hjælp af en pålidelig godkendelsesmetode, kan enhver tredjepart få adgang til dit system via API’en. Godkendelse er også vigtig, fordi den definerer, hvem der kan få adgang til hvilken API-ressource indtil et bestemt tidsrum.
#4. Usikker dataoverførsel
De data, der sendes til forbrugerne af din API, skal krypteres undervejs. Hvis det ikke er det, så er der chancer for, at dataene kan blive lækket af angribere, der bruger et mand-i-midten-angreb. Det er derfor, det altid anbefales at bruge en sikker protokol såsom HTTPS til at overføre data.
#5. Forældede/forældede afhængigheder
API’er har mange eksterne afhængigheder, der bruges til at udføre komplekse opgaver og til at aflaste noget kompleks logik. Hvis disse afhængigheder har en sårbarhed, så bliver din API indirekte også sårbar. Sørg altid for at opdatere afhængighedsversionerne.
Nu hvor du kender API-sårbarheder, lad os se på nogle bedste fremgangsmåder til at sikre din API.
Læs også: Bedste Postmand-alternativer til at teste API for udviklere
API-sikkerhed – bedste praksis
API-versionering
Det er afgørende at regelmæssigt overvåge og opdatere dine API’er med opdaterede afhængigheder, da disse afhængigheder kan indeholde store sårbarheder. Du kan underrette API-brugerne ved at frigive en patchversion af API’en i henhold til semantisk versionering.
At holde din API opdateret er det mindste, du kan gøre for at forhindre, at den bliver udnyttet af angribere.
Godkendelse
Der er en masse måder, hvorpå du kan godkende en API-bruger. Den enkleste måde er at bruge brugernavn/adgangskode-tilgangen, men det er for grundlæggende og afhænger kun af, hvor stærkt adgangskoden er.
En anden måde er at bruge API-nøgler til at få adgang til API’en. Du kan give hver API-bruger en unik nøgle, som de kan bruge.
JWT-godkendelse er en teknik, hvor brugerlegitimationsoplysningerne konverteres til et digitalt signeret token og derefter sendes til brugeren. Brugeren sender derefter det samme token tilbage på hver anmodning til serveren for serveren at validere. JWT’er har også en udløbstid.
Den mest effektive løsning er OAuth. Det giver tredjepartsadgang til API med allerede eksisterende login-legitimationsoplysninger. For eksempel, hvis du allerede er logget ind på Google, kan en applikation bruge disse legitimationsoplysninger til at logge ind på din konto uden at skulle bruge en adgangskode. Din Google-konto bliver adgangskoden.
Bemyndigelse
Autorisation er en anden ting end godkendelse. Mens du autoriserer en bruger, er de allerede godkendt til at bruge din API, og det er kun den API-ressource, de har adgang til.
For eksempel kan en universitetsprofessor have adgang til alle studerende i en batch, men en enkelt studerende kan kun få adgang til deres data. I dette tilfælde er den studerende og professoren godkendt til det samme system, men har kun tilladelse til at udføre visse handlinger.
At sikre, at API-godkendelsen fungerer godt, kan forhindre uautoriseret adgang til en ressource.
Redaktion af data
Dataredigering er processen med selektivt at afsløre oplysninger til brugere og beskytte følsomme oplysninger. Korrekt autorisation kan føre til bedre dataredigering. Databeskyttelsesforordninger såsom GDPR er også baseret på dataredigering. Enhver uønsket tredjepart bør ikke være i stand til at kigge ind i personlige eller følsomme data.
Du kan implementere datareaktion ved at implementere en middleware eller en gateway-manager.
Kryptering
Dette er blevet det vigtigste sikkerhedstjek i dagens verden. Kryptering er et must, hvis du har med nogen form for følsom information at gøre. Den mindste kryptering, du kan gøre, er ved at bruge HTTPS-protokol, som bruger TLS (Transport Layer Security) håndtryk og SSL (Secure Socket Layer).
End-to-end-kryptering er en anden måde at sikre dataene i transit tæt på. De data, der er gemt i databasen, bør også krypteres i tilfælde af, hvor en angriber kan være i stand til at bryde ind i databasen og få adgang til dataene.
Fejlhåndtering
Oplysninger om applikationens infrastruktur kan blive lækket til angribere via detaljerede fejlmeddelelser. For at undgå det skal du holde fejlmeddelelserne generiske og implementere tilpasset fejlhåndtering. Sørg for, at ingen følsomme systemoplysninger er logget på fejldetaljerne.
Inputvalidering og datasanering
Inputvalidering er meget afgørende, når man har med API’er at gøre, fordi man ikke kender inputtet, før brugeren sender det ind.
Sanering er processen med at fjerne enhver uønsket eksekverbar kode fra nyttelasten. En angriber kan indtaste et Javascript-script, og hvis du ikke renser det, før du sender det til din HTML, vil det køre som et script og hente data.
Forkert desinficering kan føre til Cross-site scripting (XSS) angreb.
Systemer til registrering af indtrængen
Også kendt som IDS, Intrusion Detection Systems hjælper med at overvåge og detektere netværkstrafik, der kommer til API’en. Hvis den finder usædvanlig adfærd i trafikken, kan den logge og advare de berørte myndigheder.
Generelt er der to typer systemer: netværksbaserede og værtsbaserede. I netværksbaserede systemer er systemet fordelt på forskellige kontrolpunkter for at overvåge trafikken på flere punkter. I et værtsbaseret system er det implementeret til en enkelt vært.
Sådanne systemer er en fantastisk måde at afgøre, hvem der forsøger at få adgang til dit netværk, før de hæmmer dine data.
IP Whitelisting
IP whitelisting er en måde at tillade kun udvalgte IP-adresser at få adgang til din API og dit netværk. Denne teknik virker muligvis ikke, hvis du har en offentlig API, fordi det er for komplekst at liste hver IP.
Det er en fordel, hvis du ved, at kun nogle af systemapplikationerne vil få adgang til din API.
JSON Web-tokens
JWT’er bruges generelt til at autentificere en bruger ved at sende brugeren et digitalt signeret token, der er oprettet ud fra deres legitimationsoplysninger. Det virker, fordi det skjuler brugerens faktiske legitimationsoplysninger, og du behøver heller ikke at gemme legitimationsoplysningerne i databasen eller på brugersiden.
JWT kan opdeles i tre sektioner: overskrift, nyttelast og signatur. Nyttelastsektionen indeholder brugerlegitimationsoplysningerne, og overskriften kan indeholde oplysninger såsom den anvendte algoritme. Signaturafsnittet signeres digitalt af serveren og klienten ved hver efterfølgende anmodning.
JWT’er har generelt en udløbsdato, hvorefter et nyt token genereres af serveren og derefter sendes til brugeren.
Logning og overvågning
Overvågning af trafikken til din API kan være en fordel for at opdage og identificere uønskede besøgende på forhånd. Du kan overvåge hver eneste anmodning, men sørg for, at logfilerne ikke indeholder følsomme oplysninger.
Satsbegrænsende
Hvis en API ikke implementerer hastighedsbegrænsning, er den sårbar over for DDoS-angreb på grund af den uventede tilstrømning af netværkstrafik. Angribere kan oversvømme systemet med et stort antal anmodninger på kort tid, og til sidst styrte serveren ned.
Throttling og hastighedsbegrænsende API’er undgår denial-of-service-angreb ved at begrænse strømmen af API-trafik.
Sikre afhængigheder
Sårbarheder opstår ikke kun fra din API-kode, de kan også være en del af enhver tredjepartsafhængighed, som du måske bruger i din API. Derfor er det vigtigt regelmæssigt at overvåge og scanne dine afhængigheder og opdage eventuelle sårbarheder, der kan være til stede i dem.
Du kan implementere et planlagt job til regelmæssigt at scanne og opdatere afhængigheder, hvis de kan opdateres med en patchversion, der løser sårbarheden. Vælg også afhængigheder, der er mere sikre og giver hyppige sikkerhedsopdateringer.
Sikkerhedsheadere skal returneres sammen med API-svaret for at instruere browseren om API-sikkerheden, og hvordan den skal fungere. Vigtige overskrifter, du kan sende for at forbedre sikkerheden, er:
- Cache-Control: Indstil den til no-store for at undgå at gemme følsomme oplysninger i browseren.
- Content-Security-Policy: Hvis du indstiller det til frame-ancestors ‘ingen’, undgår du at ramme API-svar i en iframe.
- Indholdstype: Denne header er vigtig, fordi browseren uden den forsøger at gætte typen af API-svar, og det kan føre til sniffingangreb. For JSON-svar kan du indstille det til application/json.
- X-Content-Type-Options: Indstil den til nosniff for at instruere browseren i ikke at gætte svarets MIME-type og kun at søge efter den i Content-Type-headeren.
Sikkerhedsstandarder og rammer
Design din API ved hjælp af foruddefinerede sikkerhedsstandarder og rammer for at sikre, at din API er opdateret med de seneste sikkerhedsovervejelser.
Token udløb
Hvis du bruger bærer-tokens, bør token-udløbstiden være kortvarig, fordi det kræver re-autentificering af brugeren, hvilket er en god ting. I JWT er der normalt to tokens: adgangs- og refresh-tokens. Opdateringstokens er langlivede, mens adgangstokens er kortlivede. Under alle omstændigheder bør dine tokens have en udløbstid.
Web Application Firewall
En WAF, alias Web Application Firewall, er en gateway, der overvåger, filtrerer og blokerer enhver ondsindet netværkstrafik. Det er ofte den bedste måde at forhindre ondsindede angreb gennem HTTP-protokol.
Brug af API-gateways
Hvis du nemt vil opsætte API-sikkerhed og administrere API-ruter og deres adgang, kan du gå efter API-gateways. De leverer også overvågnings-, lognings- og analyseværktøjer, som du kan bruge til at overvåge din API.
Nul-tillid
Ideen bag nultillidsstrategien er ikke at stole på nogen centraliseret kilde. Sikkerheden bør være lagdelt og implementeret ved flere kontrolpunkter.
Dybest set kan ingen stole på, selv de udviklere, der arbejder på API’et. Hver eneste gateway bør overvåges og analyseres for at forhindre sikkerhedsbrud.
Automatisering er praktisk i sådanne tilfælde. Du kan bruge automatiserede værktøjer til regelmæssigt at overvåge og blokere usædvanlig eller mistænkelig aktivitet.
Afsluttende ord
Du kan kun gøre så meget for at holde dine API’er sikre. Der er altid nogle smuthuller i software, som kan udnyttes. Sådanne smuthuller resulterer i nul-dages sårbarheder. Så for at sikre dine API’er er det mindste, du kan gøre, at holde dem opdateret med de nyeste sikkerhedsstandarder.
Tag et kig på de bedste dynamiske applikationssikkerhedstestværktøjer.