top of page
Search

Uge 36: OWASP API

  • Writer: Kenneth H Sørensen
    Kenneth H Sørensen
  • Sep 8
  • 9 min read
ree

De 10 mest udbredte trusler mod API'er


API'er er en central del af moderne systemer, men de udgør også et oplagt mål for angreb.


Det koster tid, penge og troværdighed, hvis ikke man tænker over risici fra start og skal lappe huller efter skaden er sket.


OWASP

Open Worldwide Application Security Project 


Har lavet en særskilt API Security Top 10 (2023), der kan supplere den generelle OWASP Top 10 (2021) for webapplikationer. Jeg gennemgår API-versionen, fordi vores semesterprojekt bygger på microservices, hvor synkron kommunikation med API'er vil blive benyttet.


Senere i projektet, når jeg arbejder med message brokers, vil jeg se på sikkerhed i forhold til asynkron event-drevet kommunikation..



API Security



Broken Object Level Authorization (API1:2023)


Broken Object Level Authorization

  • API'er eksponerer ofte endpoints, der modtager objekt-ID'er fra klienten.

    Uden objekt-niveau autorisationskontrol kan en angriber manipulere ID'et og få uautoriseret adgang (CRUD) til andre objekter og i visse tilfælde fuld kontoovertagelse.


Typiske sårbarheder

  • ID-manipulation - angriberen ændrer objekt-ID i path, query, header eller payload

  • Forudsigelige/lette ID'er - sekventielle heltal, UUID'er eller generiske strenge (gættes let)

  • Manglende objekt-niveau tjek - endpoint udfører handling uden at verificere brugerens rettigheder

  • Server stoler på klientparametre - stateless implementeringer, der bruger klientleverede ID'er til at afgøre adgang


Undgås ved

  • Objekt-niveau autorisation - håndhæv politikker/roller/hierarki for hver funktion, der bruger klientinput til at tilgå et objekt

  • Konsistent check pr. endpoint - verificér bruger har tilladelse til handlingen på det specifikke objekt

  • Uforudsigelige ID'er - brug tilfældige, ikke-forudsigelige identifikatorer (f.eks GUIDs)

  • Test - skriv automatiske tests, der forsøger ID-skift mellem brugere/tenants

    • deploy ikke ændringer, som får disse tests til at fejle


Note: Adskil fra Broken Function Level Authorization (BFLA) - Sørg for at der er autorisation på både funktions- og objekt-niveau.



Broken Authentication (API2:2023)


Broken Authentication

  • Fejl i autentifikationsmekanismer gør det muligt for angribere at kompromittere tokens eller udnytte implementeringsfejl til at overtage andre brugeres identitet.

    Kan give fuld kontrol over konti og følsomme data.


Typiske sårbarheder

  • Credential stuffing - API tillader brute force med lister af kendte brugernavne og passwords

  • Brute force mod samme konto  - ingen lockout eller captcha ved gentagne forsøg

  • Svage passwords  - tilladelse af simple eller forudsigelige passwords

  • Følsomme data i URL  - auth tokens eller passwords sendes i klar tekst i URL'er

  • Manglende re-autentifikation  - følsomme operationer (f.eks email eller password ændring) kræver ikke genindtastning af password

  • Tokenvalidering mangler  - API accepterer ugyldige, usignerede eller svagt signerede JWTs (f.eks {"alg":"none"} ) eller ignorerer udløbsdato

  • Svag lagring af credentials  - passwords lagres i klartekst eller med svage hashes

  • Svage nøgler  - krypteringsnøgler er forudsigelige eller for korte

  • Microservice uden auth

    • Interne services kan tilgå uden autentifikation

    • Svage tokens  - brug af simple, forudsigelige tokens til autentifikation


Undgås ved

  • Kend alle auth-flows  - kortlæg alle måder brugere kan logge ind (web, mobil, deep links ...)

  • Brug standarder (IKKE genopfind)  - Anvend etablerede mekanismer til autentifikation, tokenhåndtering og passwordlagring

  • Kend anvendte værktøjer - Eks.: OAuth er autorisation for apps, IKKE autentifikation

  • Beskyt credential recovery  - Lav pass reset som login-endpoints med brute force- og rate limiting-beskyttelse

  • Re-autentifikation  - kræv login igen for følsomme ændringer (f.eks email / 2FA)

  • MFA  - implementer multi-faktor autentifikation hvor muligt

  • Anti-brute force  - indfør mekanismer mod credential stuffing, dictionary attacks og brute force, på autentifikations-endpoints, ud over normal rate limiting

  • Konto lockout/captcha  - begræns brute force mod specifikke brugere og afvis svage passwords

  • Brug API-nøgler til at identificere kaldende projekter IKKE bruger autentifikation (link)


Note: OWASP Authentication Cheat Sheet (link)



Broken Object Property Level Authorization (API3:2023)

Inkl. Excessive Data Exposure (API3:2019) og Mass Assignment (API6:2019)


Broken Object Property Level Authorization

  • Opstår når API'er ikke validerer autorisation på objektets egenskabs-niveau

    Kan føre til at brugere læser eller ændrer følsomme felter, hvilket kan give datalæk, datatab eller privilegieeskalering


Typiske sårbarheder

  • Excessive data exposure - API returnerer flere egenskaber end nødvendigt, inkl. følsomme felter

  • Mass assignment  - API tillader ændring af interne egenskaber som ikke burde være tilgængelige for brugeren


Undgås ved

  • Property-level autorisation  - verificér at brugeren må se eller ændre de specifikke felter

  • Selektiv eksponering  - returnér kun nødvendige felter, undgå generiske metoder som to_json() eller to_string()

  • Begræns mass assignment  - tillad kun ændringer på properties som klienten eksplicit må opdatere

  • Schema-validering  - implementér validering af svarstrukturer og definer præcist hvilke data der må returneres

  • Minimer data  - hold eksponerede datastrukturer på et minimum ift. forretningskrav



Unrestricted Resource Consumption (API4:2023)


Unrestricted Resource Consumption

  • Opstår når API'er ikke begrænser brug af ressourcer som CPU, hukommelse, netværk, lager eller tredjepartsservices.

    Kan føre til Denial of Service eller øgede driftsomkostninger.


Typiske sårbarheder

  • Execution timeouts - ingen eller forkerte grænser for eksekveringstid

  • Maximum allocable memory  - ingen eller forkerte grænser for hukommelse pr. request

  • Maximum number of file descriptors  - ingen begrænsning på åbne filer eller forbindelser

  • Maximum number of processes  - ingen grænse på antal samtidige processer

  • Maximum upload file size  - tillader ubegrænset uploadstørrelse

  • Number of operations pr. request  - f.eks GraphQL batching uden grænse for antallet af operationer

  • Number of records pr. page  - ingen grænse på hvor mange records en klient kan hente i et enkelt svar

  • Third-party spending limit - ingen grænse eller overvågning på API-kald til eksterne leverandører (f.eks SMS, email, cloud storage)


Undgås ved

  • Ressourcebegrænsning  - brug teknologier som containere eller serverless til at sætte grænser for CPU, hukommelse, processer og file descriptors

  • Inputbegrænsning  - definer maksimum for strenglængde, array-størrelse og upload-filer

  • Rate limiting  - begræns hvor ofte en klient kan interagere med API'et, finjustér per endpoint efter behov

  • Throttling  - begræns hvor ofte en bruger kan udføre en specifik operation (f.eks password reset, OTP-validering)

  • Server-side validering  - tjek query-parametre og body-parametre, især dem der styrer antal records i svaret

  • Spending limits  - konfigurer forbrugstærskler eller billing alerts hos eksterne leverandører og cloud-services



Broken Function Level Authorization (API5:2023)


Broken Function Level Authorization

  • Opstår når API'er ikke korrekt adskiller adgang til funktioner på baggrund af roller, grupper eller hierarkier.

  • Kan give angribere adgang til følsomme funktioner, herunder administrative endpoints, hvilket kan føre til datalæk, datatab, manipulation eller fuld systemovertagelse.


Typiske sårbarheder

  • Administrative endpoints - en almindelig bruger kan tilgå endpoints, der kun burde være for administratorer

  • Manglende funktionskontrol  - en bruger kan udføre følsomme handlinger (f.eks create, update, delete) ved at ændre HTTP-metoden (f.eks fra GET til DELETE)

  • Gruppeadgang  - en bruger fra gruppe X kan tilgå funktioner tiltænkt gruppe Y ved at gætte endpoint-URL eller parametre

  • Fejlplaceret admin-funktioner  - administrative endpoints er placeret sammen med almindelige endpoints (f.eks /api/users) uden ekstra autorisationskontrol


Undgås ved

  • Konsistent autorisationsmodul - brug et centralt modul til autorisation, som kaldes fra alle forretningsfunktioner (kan ligge udenfor applikationskoden)

  • Deny by default - nægt al adgang som udgangspunkt, og giv kun eksplicit adgang til specifikke funktioner baseret på rolle

  • Review endpoints - gennemgå API'et for funktionsniveau-sårbarheder ift. forretningslogik og gruppestruktur

  • Arv fra admin-controller - sørg for at alle administrative controllers arver fra en abstrakt controller med autorisationskontrol baseret på brugerens rolle/gruppe

  • Autorisation i almindelige controllers - hvis administrative funktioner findes i normale controllers, skal de have særskilte autorisationskontroller baseret på rolle/gruppe



Unrestricted Access to Sensitive Business Flows (API6:2023)


Unrestricted Access to Sensitive Business Flows

  • Opstår når et API eksponerer forretningsflows (f.eks køb af billet eller oprettelse af kommentar) uden at begrænse hvordan funktionen kan misbruges ved automatiseret eller overdreven brug.

    Kan skade forretningen ved f.eks spam, udsolgte produkter, reservationer der blokerer legitime brugere eller misbrug af interne økonomier.


Typiske sårbarheder

  • Purchasing flow - angriber køber hele lageret af et produkt med høj efterspørgsel og videresælger det dyrere (scalping)

  • Comment/post flow  - angriber spammer systemet med automatiserede opslag

  • Reservation flow  - angriber reserverer alle tilgængelige tider/pladser og forhindrer legitime brugere i at gennemføre reservation

  • Referral/bonus flow  - angriber automatiserer tilmeldinger for at optjene belønninger eller kredit


Undgås ved

  • Forretningslag  - identificér forretningsflows der kan skade virksomheden ved overdreven brug

  • Teknisk lag  - vælg passende tekniske mekanismer for at mitigere risikoen

    • Device fingerprinting  - blokér uventede klienter (f.eks headless browsers) for at øge angriberens omkostninger

    • Human detection  - brug captcha eller biometriske metoder (f.eks taste-mønstre)

    • Adfærdsmønstre  - analyser brugerflow for at opdage ikke-menneskelige / urealistiske mønstre (f.eks “add to cart” + “complete purchase” på under 1 sekund)

    • Netværkskontrol  - overvej at blokere IP’er fra Tor exit nodes og kendte proxies

    • Begræns maskine-til-maskine API'er  - sikre og begræns adgang til developer- og B2B-API'er, da de ofte mangler fulde beskyttelsesmekanismer


Note: forretningsafhængigt  - hvad der er misbrug i én branche eller forretning kan være accepteret i en anden



Server Side Request Forgery (API7:2023)

Her med fokus på API - findes også i OWASP Top 10:2021 (A10:2021) om webapplikationer


Server Side Request Forgery

  • Opstår når et API henter en ekstern ressource uden at validere en URL leveret af brugeren

    Kan give angribere mulighed for at få applikationen til at sende forespørgsler til interne eller uventede destinationer, hvilket kan føre til portscanning, informationslæk, firewall-bypass, DoS eller misbrug af serveren som proxy


Typiske sårbarheder

  • Manglende URL-validering - API henter ressourcer fra brugerleverede adresser uden kontrol

  • Webhooks  - brugerdefinerede URL’er til integration kan udnyttes til SSRF

  • Filhentning via URL  - API tillader at filer hentes fra eksterne kilder uden begrænsning

  • Custom SSO og URL-previews  - funktioner der baserer sig på brugerinput-URL’er uden korrekt filtrering

  • Cloud management endpoints  - moderne teknologier (cloud, Kubernetes, Docker) eksponerer styringskanaler på kendte HTTP-paths, som kan nås via SSRF


Undgås ved

  • Isolering  - adskil mekanismer der henter ressourcer, så de ikke kan nå interne systemer

  • Allow lists  - tillad kun bestemte kilder (f.eks Google Drive, Gravatar), URL-skemaer, porte og medietyper

  • Deaktiver redirection  - følg ikke HTTP-redirects automatisk

  • Robust URL-parser  - brug testede biblioteker for at undgå fejl i URL-fortolkning

  • Inputvalidering  - valider og saniter alle brugerleverede URL’er og parametre

  • Ingen rå svar  - returnér ikke direkte svar fra hentede ressourcer til klienten



Security Misconfiguration (API8:2023)

Her med fokus på API - findes også i OWASP Top 10:2021 (A05:2021)


Security Misconfiguration

  • Opstår når API'er eller understøttende systemer har forkerte eller manglende sikkerhedskonfigurationer

  • Kan give angribere uautoriseret adgang, eksponering af følsomme data eller fuld serverkompromittering


Typiske sårbarheder

  • Manglende hardening - utilstrækkelig sikring af dele af API-stakken eller forkerte tilladelser i cloud-services

  • Manglende patches  - seneste sikkerhedsopdateringer mangler eller forældede systemer

  • Unødvendige features  - aktiverede funktioner som ikke er nødvendige (f.eks HTTP-verbs, logging)

  • Inkonsekvent request-håndtering - forskellig behandling af requests i HTTP-serverkæden (load balancer, proxy, backend)

  • Manglende TLS - kommunikation sker uden kryptering

  • Manglende security/cache headers - sikkerheds- eller cache-control direktiver sendes ikke til klienter

  • Manglende eller forkert CORS-politik - politik mangler eller er fejlagtigt konfigureret

  • Informationslæk i fejlmeddelelser - fejlmeddelelser viser stack traces eller andre følsomme detaljer


Undgås ved


Proces

  • Gentagelig hardening - fast proces til hurtigt at deploye et godt beskyttet miljø

  • Review og opdatering - gennemgå og opdatér konfigurationer i hele API-stakken inkl. orkestreringsfiler, API-komponenter og cloud-services (f.eks S3 tilladelser)

  • Automatiseret validering - brug automatiserede processer til at vurdere effektiviteten af konfigurationer i alle miljøer


Teknisk

  • Kryptering  - sørg for at al kommunikation mellem klient, API-server og downstream/upstream-komponenter sker via TLS (internt og eksternt)

  • Begræns HTTP-verbs  - tillad kun de nødvendige verbs pr. endpoint og deaktiver resten (f.eks HEAD)

  • Browser-baserede API'er  - implementér korrekt CORS-politik og tilføj relevante security headers

  • Content-type kontrol  - tillad kun indholdstyper/dataformater der er nødvendige ift. forretningskrav

  • Konsistens i serverkæden  - sørg for at alle servers i HTTP-kæden håndterer requests ensartet for at undgå desync

  • Skemadefinition  - definer og håndhæv payload-schemas inkl. fejlmeddelelser, så exception traces og systeminfo ikke lækkes



Improper Inventory Management (API9:2023)


Improper Inventory Management

  • Opstår når API'er og understøttende systemer ikke er korrekt dokumenteret eller vedligeholdt

    Kan give adgang til gamle, usikre eller uovervågede endpoints, hvilket kan føre til datalæk, kompromittering eller serverovertagelse


Typiske sårbarheder

  • Et API har et "documentation blindspot" hvis:

    • Formålet med en API-host er uklart, og der ikke er svar på spørgsmål som miljø (f.eks produktion, test), adgang (f.eks offentlig, intern, partner) og version

    • Dok mangler eller er ikke opdateret

    • Ingen retirement-plan for API-versioner

    • Oversigt over API-hosts mangler eller er forældet

  • Et API har et "data flow blindspot" hvis:

    • API'et deler følsomme data med en tredjepart uden forretningsmæssig begrundelse eller godkendelse

    • Ingen oversigt eller synlighed af dataflow

    • Der mangler detaljeret viden om hvilke typer følsomme data der deles


Undgås ved

  • Oversigt over API-hosts  - dokumentér miljø (f.eks produktion, staging, test), adgang (f.eks offentlig, intern, partner) og version

  • Oversigt over services  - dokumentér integrerede services, deres rolle, hvilke data de udveksler, og datasensitivitet

  • Dokumentér API'et  - inkl. autentifikation, fejl, redirects, rate limiting, CORS-politik, endpoints, parametre, requests og responses

  • Automatisér dokumentation  - brug åbne standarder og byg dok ind i CI/CD-pipelinen

  • Begræns adgang til dok  - kun autoriserede brugere skal kunne se API-dok

  • Beskyt alle versioner  - brug API-sikkerhedsløsninger på alle eksponerede versioner, ikke kun den nyeste produktion

  • Undgå produktionsdata i test  - hvis uundgåeligt, behandl non-prod endpoints med samme sikkerhed som produktion

  • Risikoanalyse ved nye versioner  - vurder om sikkerhedsforbedringer kan backportes til gamle versioner, eller om de skal lukkes hurtigt og brugere flyttes til den nyeste



Unsafe Consumption of APIs (API10:2023)


Unsafe Consumption of APIs

  • Udviklere stoler ofte mere på data fra (kendte) tredjeparts-API'er end på brugerinput og anvender derfor også ofte svagere sikkerhedskrav her.

    Kan føre til datalæk, injection-angreb eller DoS, hvis angribere kompromitterer integrerede API'er i stedet for at angribe det primære API direkte


Typiske sårbarheder

  • Ukrypteret kommunikation - API'et interagerer med tredjeparts-API'er over ukrypterede forbindelser

  • Manglende validering/sanitering  - data fra tredjeparts-API'er valideres ikke før det behandles eller sendes videre

  • Blind redirect  - API'et følger automatisk tredjeparts-redirects uden kontrol

  • Ubegrænset ressourcetræk  - ingen grænse for mængden af data der hentes fra tredjeparts-API'er

  • Manglende timeouts  - ingen timeout på kald til tredjeparts-API'er


Undgås ved

  • Vurdering af serviceudbydere  - vurder sikkerheden i tredjeparts-API'er før integration

  • Krypteret kommunikation  - sørg for at alle interaktioner sker via TLS

  • Inputkontrol  - valider og saniter altid data fra integrerede API’er før brug

  • Allowlist for redirects  - oprethold en liste over godkendte destinationer og følg aldrig redirects blindt




Refleksion


OWASP API Security Top 10 (2023) overlapper med OWASP Top 10 (2021), men har et skærpet fokus på integrationer, dataflows og autorisation på objekt- og funktionsniveau.


Jeg har derofr fået bedre forståelse for de trusler, som er særligt relevante for API'er og microservices.


Jeg tænker jeg er klar til at begynde high level design af den microservice jeg har ansvar for i projektet. Her vil jeg forsøge at indarbejde de mest relevante sårbarheder i designet, både high level og low level, inden jeg begynder at kode.



Videre plan


Vi er startet på analyse og modellering i projektet, og jeg har udarbejdet use cases til den microservice, jeg skal stå for. Efter et fokus på IT-sikkerhed de første uger, vil jeg arbejde med Backend-udvikling & API-design, kombineret med high level design efter secure-by-design principperne.


Fokus nu

  • Projekt: High Level Design (HLD)

  • IT-sikkerhed

    • HLD med secure-by-design principper

  • Backend & API-design:

    • Microservice vs monolit

    • Hexagonal arkitektur


Senere

  •  IT-sikkerhed / Backend & API-design

    • GraphQL (nyt) vs REST API (kendt)

    • Message brokers (RabbitMQ vs Kafka)



Ressourcer


OWASP



Evt. videre læsning

OWASP Microservice Security - Cheat Sheet


Message broker sikkerhed (LinkedIn Advice)


RabbitMQ Security - Complete Guide



bottom of page