Slik Sikrer DU REST API-Sikkerhet

Web application programming interfaces (Apier) gir bakenden for moderne web-og mobilapplikasjoner. WEB API-kall står for over 80% av all nettrafikk, og nettkriminelle retter seg i økende grad mot Api-er, så det er avgjørende å sikre web API-sikkerhet. REST-Api-Er er den vanligste TYPEN WEB-API for webtjenester. La oss se hva DU kan gjøre for Å sikre REST API-sikkerhet.

Hva ER EN REST API?

REST (forkortelse For REpresentational State Transfer) er en programvarearkitekturstil for webutvikling, vanligvis brukt MED HTTP-kommunikasjon. RESTful Apier (ELLER BARE REST Apier) er programmeringsgrensesnitt som følger REST-prinsippene, slik at webklienter og servere kan samhandle med et stort utvalg av webressurser. REST-Apier bruker STANDARD HTTP-verb (metoder) og statuskoder for å gi et visst nivå av standardisering. DE er tilgjengelige VIA HTTP-Nettadresser og er mye brukt for webtjenester.

Notat: REST-Apier er statsløse som HTTP-protokollen selv, noe som betyr at DE ikke lagrer informasjon om nåværende tilkoblinger eller økter. RESTful web services gir måter å få tilgang til og manipulere ressurser, mens øktbehandling skal håndteres av programmet.

TO Nivåer AV REST API-Sikkerhet

Før vi kommer inn i de tekniske detaljene, er det en viktig ting å merke seg. En WEB API eksponerer et grensesnitt til et webprogram, så du må tenke på sikkerhet på to nivåer: tilgang TIL API og deretter tilgang til programmet.

PÅ API-nivå trenger du riktig godkjenning, autorisasjon, tilgangsrettigheter og så videre for å sikre at kun tillatte klienter kan bruke grensesnittet og bare utføre tillatte operasjoner. På applikasjonsnivå må du sørge for at applikasjonsendepunktene dine (Nettadressene som brukes til å få tilgang til grensesnittet) ikke er sårbare for angrep som kommer gjennom grensesnittet eller omgår det.

La oss se hvordan DU kan sikre REST API-sikkerhet på disse to nivåene. HVIS DU VIL ha en detaljert diskusjon om BESTE PRAKSIS FOR API-sikkerhet, kan DU se Jukselapp FOR OWASP REST Security.

Sikre Sikker API-Tilgang

De fleste Web-Api-Er er eksponert For Internett, så de trenger egnede sikkerhetsmekanismer for å forhindre misbruk, beskytte sensitive data og sikre at bare godkjente og autoriserte brukere kan få tilgang til Dem.

Tilkoblingssikkerhet

Sikkerhet starter MED SELVE HTTP-tilkoblingen. Sikre REST-Api-Er bør bare gi HTTPS-endepunkter for å sikre at ALL API-kommunikasjon er kryptert MED SSL / TLS. Dette gjør det mulig for klienter å godkjenne tjenesten og beskytter API-legitimasjonene og overførte data.

API Access Control

Mange Web-Apier er bare tilgjengelige for godkjente brukere, for eksempel fordi de er private eller krever registrering eller betaling. FORDI REST-Api-Er er statsløse, håndteres tilgangskontroll av lokale endepunkter. DE vanligste REST API-autentiseringsmetodene er:

• HTTP Enkel Godkjenning: Legitimasjon sendes direkte I HTTP-overskrifter I Base64-koding uten kryptering. Dette er den enkleste autentiseringsmetoden og den enkleste å implementere. Det er også minst sikkert, siden konfidensielle data overføres som ren tekst, så det bør bare brukes i kombinasjon med HTTPS.
• Json Web Tokens (JWT): Legitimasjon og andre tilgangsparametere sendes SOM json datastrukturer. Disse tilgangstokenene kan signeres kryptografisk og er den foretrukne måten å kontrollere tilgangen til REST-Api-Er på. SE OWASP JWT Cheat Sheet for en rask oversikt OVER JSON Web Tokens, OG RFC 7519 for full spesifikasjon.
• OAuth: Standard oauth 2.0 mekanismer kan brukes til autentisering og autorisasjon. OpenID Connect tillater sikker autentisering Over OAuth 2.0. Googles Api-Er bruker For eksempel OAuth 2.0 til autentisering og autorisasjon.

Brukerautorisasjon med API-Nøkler

API-nøkler gir en måte å kontrollere tilgang til offentlige REST-tjenester. Operatører av offentlige webtjenester kan bruke API-nøkler til å håndheve hastighetsbegrensning FOR API-kall og redusere tjenestenektangrep. For tjenester som tjener penger, kan organisasjoner bruke API-nøkler til å gi tilgang basert på den kjøpte tilgangsplanen.

API-Klientbegrensninger

FOR å minimere sikkerhetsrisikoer bør REST-tjenesteoperatører begrense tilkobling av klienter til de minste funksjonene som kreves for tjenesten. Dette starter med å begrense STØTTEDE HTTP-metoder for å sikre at feilkonfigurerte eller ondsinnede klienter ikke kan utføre handlinger utover API-spesifikasjonen og tillatt tilgangsnivå. FOR EKSEMPEL, HVIS API-EN bare tillater GET-forespørsler, BØR POST og andre forespørselstyper avvises med svarkode 405-Metoden ikke tillatt.

Beskytte Programmer Som Eksponerer Apier

når klienten har legitim tilgang, må du beskytte det underliggende webprogrammet mot feilformede og skadelige innganger. REST API-anrop og svar kan også inneholde konfidensielle data som må kontrolleres.

Sensitive Data i API-Kommunikasjon

API-kall inkluderer ofte legitimasjon, API-nøkler, økttokener og annen sensitiv informasjon. Hvis inkludert direkte I Nettadresser, kan disse detaljene lagres i webserverlogger og lekket hvis loggene åpnes av nettkriminelle. For å unngå lekkasje av konfidensiell informasjon, Bør RESTful web services alltid sende DEN I HTTP-forespørselshoder eller forespørselsorganet (FOR POST-og PUT-forespørsler).

Validering Av Innholdstype

VED å fortsette TEMAET API-klientrestriksjoner bør REST services nøyaktig definere tillatte innholdstyper og avvise forespørsler som ikke har de riktige deklarasjonene i HTTP-overskriftene. Dette betyr nøye å spesifisere tillatte typer i både Content-Type og Accept header, sammen med charset (der det er mulig). Hvis tjenesten inkluderer JavaScript( eller annen skriptkode), bør den sørge for at innholdstypen i overskriften er den samme som i forespørselsorganet, for eksempel application/javascript. Dette bidrar til å hindre header injeksjon angrep.

Response Security Headers

Flere HTTP security headers kan settes til å begrense typen og omfanget av forespørsler ytterligere. Disse inkluderer X-Content-Type-Options: nosniff for å forhindre xss-angrep basert PÅ MIME-sniffing og X-Frame-Options: deny for å forhindre klikkforsøk i eldre nettlesere.

hvis tjenesten ikke støtter anrop på tvers av domener, bør DEN deaktivere CORS (ressursdeling på tvers av opphav) i svaroverskriftene. Hvis slike samtaler forventes, BØR CORS-overskriftene nøyaktig angi den tillatte opprinnelsen.

Inndatavalidering

Apier er utformet for automatisert tilgang uten brukerinteraksjon, så det er spesielt viktig å sikre at alle innganger er gyldige og forventede. Forespørsler som ikke samsvarer MED API-spesifikasjonen, må avvises. Typiske retningslinjer for beste praksis for validering av inndata gjelder:

• Behandle alle parametere, objekter og andre inndataene som uklarert.
• Bruk innebygd valideringsfunksjonalitet der det er tilgjengelig.
• Kontroller forespørselens størrelse og innholdslengde og-type.
• Bruk sterk skriving FOR API-parametere(hvis støttet).
• unngå å bygge spørringer manuelt hvis DU vil forhindre SQL-injeksjon.
• hviteliste parameterverdier og strenginnganger der det er mulig.
• Logg alle inndatavalideringsfeil for å oppdage påloggingsforsøk.

HVORFOR REST API-Sikkerhet Er Viktig

Web-Api-Er er ryggraden i moderne web-og mobilutvikling. De gjør det mulig for applikasjoner og tjenester å kommunisere og utveksle data på tvers av maskinvare-og programvareplattformer. MENS ANDRE API-formater fortsatt er i bruk (FOR EKSEMPEL SOAP), ER REST-Api-Er nå den dominerende typen, og står for over 80% av alle offentlige Web-Api-Er. De gir bakenden for de fleste mobile applikasjoner og iot-enheter og tillater enkel integrasjon på tvers av systemer og applikasjoner.

FORDI DE bruker samme teknologi som webapplikasjoner, KAN REST-Api-Er være sårbare for de samme angrepene. Samtidig Er Api-Er ikke laget for manuell tilgang, så De kan være vanskelige å teste, spesielt hvis enkelte endepunkter og funksjoner ikke er dokumentert. API – sikkerhetstesting krever nøyaktige automatiserte verktøy for å sikre fullstendig dekning. Netsparker gir full støtte FOR rest API sårbarhet skanning med en rekke autentiseringsmetoder og automatisk URL omskriving.

Se dokumentasjonen For Netsparker REST API test site for fullstendige tekniske detaljer og les hele artikkelen vår om skanning AV REST Api-Er for sårbarheter Med Netsparker.

Om Forfatteren

Zbigniew Banach

Teknisk Innhold Skribent På Netsparker. Med sin erfaring SOM IT-journalist og teknisk oversetter, gjør Han sitt beste for å bringe websikkerhet til et bredere publikum på Netsparkers blogg og nettside.