Hvad er OWASP10?

OWASP10 er en liste over de 10 mest kritiske sikkerhedsrisici inden for webapplikationer og API'er. Den udgives af Open Web Application Security Project (OWASP), som er en global nonprofit organisation med formålet at forbedre softwaresikkerhed.

Det giver mening for udviklere at stole på OWASP Top 10, fordi den giver en standardiseret og anerkendt liste over de mest almindelige sikkerhedsrisici. Ved at følge OWASP10 kan udviklere identificere og håndtere potentielle sårbarheder i deres applikationer tidligt i deres udviklingsproces. Dette hjælper med at minimere risikoen for angreb og beskytter brugerdata og systemet.

OWASP10 fungerer som en guide til implementering af bedste praksis inden for sikkerhed for webapplikationer og API'er. Ved at følge disse retningslinjer kan udviklere minimere risikoen for nogle angreb som SQL injektion, cross-site scripting (XSS) og brud på sessionhåndtering.

Sammenfattende kan udviklere ved at stole på OWASP10 opnå en bedre sikkerheds standard i deres applikationer og beskytte både dem selv og brugere mod potentielle trusler.

Hvert fjerde år udgives en rapport der beskriver de 10 mest almindelige angreb mod webapplikationer og API'er.

Nedenfor har jeg indsat et billed af hvordan top 10 listen udviklede sig fra 2017 til 2021.

Hvordan OWASP Top 10 bliver skabt

OWASP Top 10 er en liste der viser de mest kritiske sikkerhedsrisici inden for webapplikationer. Den bliver udviklet gennem en åben, datadrevet proces med hjælp af sikkerhedseksperter og organisationer over hele verden.

Processen begynder med en omfattende indsamling data fra forskellige kilder, bl.a. sikkerheds rapporter, automatiserede scanninger og input fra OWASP’s eget community. Dataen analyseres grundigt for at identificere de mest almindelige og alvorlige sårbarheder. Analysen bruges til at finde mønstre der viser, hvilke risici der har størst indvirkning på sikkerheden i webapplikationer.

Når sårbarheder er identificeret bliver de prioriteret efter en række kriterier. Dette inkluderer, hvor alvorlige konsekvenser sårbarhederne kan have, hvor ofte de udnyttes, og hvor vanskelige de er at opdage og derefter at rette. Derudover tager OWASP også højde for hvordan disse risici kan påvirke virksomheder og deres brugere.

Et udkast af listen bliver derefter offentliggjort for at indhente feedback fra OWASP’s eget community. Ved at lade eksperter og andre interessenter kommentere og komme med forslag sikres det, at listen er så relevant som muligt. Efter at have indarbejdet denne feedback, bliver den endelige version af OWASP10 offentliggjort.

Listen er en vigtig guideline for udviklere, sikkerhedseksperter og organisationer, som ønsker at forbedre sikkerheden i deres webapplikationer. OWASP10 er anerkendt globalt og har en central rolle i at reducere sikkerhedsrisici og beskytte data. Ved at følge anbefalingerne kan udviklere og teams sikre, at deres applikationer er robuste og modstandsdygtige overfor trusler.

OWASP Top 10, seneste liste

Her er en oversigt over punkterne baseret på den seneste opdatering fra 2021:

1. Broken Access Control (Adgangskontrol der ikke virker)
   • Når adgangskontroller ikke håndhæves rigtigt, kan brugere få adgang til ressourcer som de ikke har tilladelse til, f.eks. data eller admin funktioner.
2. Cryptographic Failures (Kryptografiske fejl)
   • Fejl i håndteringen af følsomme data såsom manglende kryptering eller brug af usikre protokoller, kan fører til et databrud.
3. Injection (Injektionsangreb)
   • Når ondsindet kode (f.eks. SQL eller script) sendes til en applikation og gennemføres, hvilket kompromitterer sikkerheden.
4. Insecure Design (Usikre designprincipper)
   • En dårlig sikkerhedsarkitektur, som gør applikationen sårbar over for angreb.
5. Security Misconfiguration (Fejl i sikkerhedskonfiguration)
   • Forkerte indstillinger eller manglende opdateringer i applikationens software eller servere.
6. Vulnerable and Outdated Components (Sårbare og forældede komponenter)
   • Brug af biblioteker eller frameworks med kendte sårbarheder som aktører kan udnytte.
7. Identification and Authentication Failures (Fejl i identifikation og autentifikation)
   • Problemer som f.eks. svage adgangskoder eller manglende multifaktor autentifikation, der gør det lettere for aktører at komme igennem.
8. Software and Data Integrity Failures (Fejl i software- og dataintegritet)
   • Sårbarheder i forbindelse med supply chain angreb.
9. Security Logging and Monitoring Failures (Fejl i logning og overvågning)
   • Manglende overvågning, der gør det svært at opdage og reagere på sikkerhedshændelser.
10. Server-Side Request Forgery (SSRF)
    • Når en applikation kommunikerer med ukontrollerede eller skadelige eksterne ressourcer på vegne af brugeren.

Refleksioner

For nu og i fremtiden vil det være vigtigt at vi, som udviklere holder os opdaterede på denne liste. Helt lavpraktisk kan vi bruge denne liste som en tjekliste undervejs i hvert sprint.

Jo større systemet er, jo længere tid og ressourcer vil dette kræve. Der findes systemer til at automatisere denne slags kontroller f.eks. . Hvis man integrere Snyk i sit system, så vil man løbe en risiko om at blotte sin kodebase. Det vil være individuel vurdering om det er en risiko som er værd at løbe i forhold til hvor mange arbejdstimer man kan spare.

Omvendt så er man også afhængige af mennesker som kan lave fejl til at gennemføre de samme analyser. Der er bestemt fordele og ulemper ved begge.

Når man udvikler et nyt IT system, så vil det altid være vigtigt at starte med at vurdere sit system på baggrund af OWASP 10. Når man har gjort dette så vil jeg sige at man gjort det minimale for at sikrer sit system mod omverdenen på internettet. Herefter må man kigge indad og se efter om der er branchespecifikke angreb eller specifikke angreb i forhold til den type system man deployer som man skal være opmærksomme på. Med de overvejelser vil man vide om der er behov for at udvide sin personlige tjekliste for hvilke typer angreb man skal beskytte sig imod. Det er vigtigt at forstå at et system på internet aldrig kan være 100% sikkert, og at der bliver fundet mange tusinde sårbarheder hvert år. Så denne vurdering er nødt til at være en løbende og dynamisk proces som skal følge ens system til den dag det ikke længere skal bruges.

Kilde: OWASP10 (opens in a new tab)