2024-11-04 OWASP
I sidste uge designede jeg denne model, der muliggør, at en bruger i vores system kan oprette en video ved at indsætte et link til en YouTube-video og gemme den. Samtidig bliver brugeren notificeret om handlingen.
Jeg har allerede implementeret nogle basale foranstaltninger, som fx load balancing samt autentifikation og autorisation, der styres via vores API-Gateway for at håndtere systemets flow.
Fokus på OWASP-sårbarheder
Nu vil jeg analysere vores system i forhold til OWASP's opdaterede trusselsbillede for API'er. I 2023 opdaterede OWASP deres liste over de mest kritiske sikkerhedsrisici, som udviklere bør være opmærksomme på. Du kan finde listen her: OWASP Top 10 API Security Risks - 2023.
I vores nuværende system er sikkerheden meget basal og begrænser sig til autentifikation og load balancing. Som en del af denne øvelse vil jeg tage hvert punkt fra OWASP Top 10 API-risici og vurdere, hvordan vi forholder os til dem i vores model.
NB: Dette er et tænkt eksempel og bruges primært som en læringsøvelse.
Gennemgang af OWASP Top 10 API-sårbarheder
Jeg vil starte med det første punkt og fokusere på vores API:
Klik på overskrifterne nedenfor for at se, hvordan jeg vurderer og håndterer hver risiko i konteksten af vores system:
1
Broken Object Level Authorization
Vores system
På nuværende tidspunkt er vores sårbart overfor dette. Da vi har meget basale bruger niveau. Og vi som hold/team ikke har været i dialog om hvad den enkelte rolle skal have adgang til.
Forbedringer
Det vi ville kunne gøre for at forbedre sikkerheden her er at, vi som team skulle have været i dialog om hvordan vi vil forholde os til de forskellige roller i vores system skal være og hvad de har brug for.
2
Broken Authentication
Vores system
Vores systemet er sårbart overfor dette da vi burde have bedre beskyttelse på den personlige information der vil florere i vores system.
Forbedringer
Det vi ville kunne gøre for at forbedre sikkerheden her er at, vi kunne lave en bedre rate limiting på vores system.
3
Broken Object Property Level Authorization
Vores system
Dette er slet ikke implementeret i vores system, da fokus har været rettet andet steds.
Forbedringer
Vi kunne starte med at lave en validering på vores bruger input.
4
Unrestricted Resource Consumption
Vores system
Vores system har en meget basal API-Gateway, som kun lige opfylder de meget grundlæggende krav. Derfor er dette sårbart.
Forbedringer
5
Broken Function Level Authorization
Vores system
I forhold til dette har vi en basal autentifikation på vores system der kun kontrollere om man er den man er. Ikke om hvilken rolle brugeren har.
Forbedringer
Enten lave den bedre eller udlicitere den del af systemet til en tredjepart som vi har gjort med Supabase.
6
Unrestricted Access to Sensitive Business Flows
Vores system
Vi har implementeret en default rate limiter.
Forbedringer
Vi kunne implementere en custom rate limiter der ville gøre det svære for en ondsindet aktør at udnytte den del af systemet.
7
Server Side Request Forgery
Vores system
I Tilfælde af at vores system havde meget personlige eller sensitive oplysninger ville dette have haft en højere prioritet
Forbedringer
En liste over forventede URL'er i vores system vil helt sikker kunne skabe et meget mere lukket miljø i forholdt il at det var et intranet vi skulle lave.
8
Security Misconfiguration
Vores system
Vi burde afvige fra normen for ikke at gøre os sårbart over for fx brute force.
Forbedringer
Implementering af andet end en default vil gøre det lidt mere vanskeligt for en ondsindet aktør.
9
Improper Inventory Management
Vores system
Vores systems dokumentation er ikke tilgængelig offentlig.
Forbedringer
På sigt kan det godt være en ide at have dokumentation online og kunne tilgå denne alle steder fra. Når denne skal laves vil det være en ide at gøre denne lukket.
10
Unsafe Consumption of APIs
Vores system
Dette ville have haft en højere prioritet hvis vi havde haft mere tid.
Forbedringer
At oprette TLS forbindelser på vores api kald og iterne forbindelser vil kunne tilføje en væsenlig forbedring.