OWASP Top 10 har siden 2003 representert de viktigste/vanligste sårbarhetene eller angrepstypene mot internettbasert programvare. Listen har vært oppdatert med ujevne mellomrom, men i det siste stort sett hvert fjerde år. Listen er viktig ikke bare fordi den forteller oss hvilke angrepstyper som er vanligst for tiden, men også fordi den representerer angrep som utgjør utgangspunktet for mer eller mindre uerfarne angripere – dette er det de kommer til å prøve først, så sørg for at du ikke er sårbar for det! OWASP Top 10 tar utgangspunkt i Mitres Common Weakness Enumeration (CWE).
Top 10 2021 kom allerede for et halvt år siden, men ettersom neste sannsynligvis kommer i 2025, er den fortsatt som dagsfersk å regne!
Dagens liste
A01:2021-Råtten aksesskontroll
Rykker opp fra femteplass til kategorien med den mest alvorlige risikoen for vevapplikasjoner. Dataene indikerer at gjennomsnittlig 3,81% av alle applikasjoner som ble testet hadde en eller flere CWEer i denne risikokategorien (totalt ~318 000 tilfeller). De 34 CWEene som peker på denne kategorien hadde flere tilfeller i applikasjoner enn noen annen kategori.
A02:2021-Kryptografiske brølere
Flyttes opp en plass til #2, tidligere kjent som “A3:2017-Sensitive Data Exposure”, som var et bredt symptom snarere enn en rotårsak. Det nye navnet fokuserer på feil relatert til kryptografi, som har vært implisitt tidligere. Denne kategorien fører ofte til eksponering av sensitive data, eller kompromittering av systemet.
A03:2021-Injisjering
Sklir ned på tredjeplass, 94% av applikasjonene ble testet for en eller annen form for injeksjon med en maksimum insidensrate på 19%, en gjennomsnittlig insidensrate på 3.37%, og de 33 CWEene som peker på denne kategorien har det nest høyeste antall tilfeller i applikasjoner med 274k tilfeller. “Cross Site Scripting” (XSS) er nå en del av denne kategorien.
A04:2021-Usikkert Design (Ny)
Ny kategori for 2021, med fokus på risiko relatert til designfeil. Hvis vi virkelig ønsker å “flytte oss til venstre” som en bransje, må vi gjøre mer trusselmodellering, bruke sikre designmønstre, og sikre referansearkitekturer. Et usikkert design kan ikke fikses av en perfekt implementering hvis nødvendige sikkerhetsmekanismer aldri ble opprettet for å beskytte mot spesifikke angrep.
A05:2021-Feil sikkerhetskonfigurasjon
Klatrer fra #6 i forrige utgave, 90% av applikasjoner ble testet for en eller annen form for feilkonfigurering, med, en gjennomsnittlig insidensrate på 4,5%, og over ~208 000 tilfeller av CWEer som peker på denne risikokategorien. Ettersom stadig flere programvaresystemer går over til å bli ytterst konfigurerbare, er det ikke overraskende at denne kategorien beveger seg oppover på lista. Den tidligere kategorien A4:2017-XML External Entities (XXE) er nå en del av denne risikokategorien.
A06:2021-Sårbare og utdaterte komponenter
Tidligere kjent som “Bruke komponenter med kjente sårbarheter “; er på andreplass i Top 10 undersøkelsen gjort i sikkerhetsmiljøet, men hadde også tilstrekkelig med data til å havne på lista via dataanalyse. Denne kategorien rykker opp fra 9.plass i 2017, og er et kjent problem med å teste og vurdere risiko. Det er den eneste kategorien som ikke har noen CVEer som peker på de inkluderte CWEene, så en grunnleggende vekting av 5.0 er fakturert inn i utnyttelse- og konsekvens-verdiene for utregning av resultatene.
A07:2021-Identifiserings- og autentiseringsfeil
Tidligere kjent som “Råtten autentisering”; sklir ned fra andreplass, og omfatter nå CWEer som er mer koblet til identifiseringsfeil. Denne kategorien er fortsatt en viktig del av Top 10, men den økende tilgjengeligheten av standardiserte rammeverk ser ut til å ha en gunstig effekt.
A08:2021-Programvare og dataintegritetsfeil (“Ny”)
Ny kategori I 2021 som fokuserer på ulempene ved å gjøre antagelser rundt programvareoppdateringer, kritiske data, og CI/CD “rørledninger” uten å verifisere integritet. En av de høyest vektede konsekvensene fra CVE/CVSS-data pekte på de 10 CWEene i denne kategorien. A8:2017 Usikker deserialisering er nå en del av denne kategorien.
A09:2021-Sikkerhetsloggings- og monitoreringsfeil
Tidligere kjent som A10:2017-Utilstrekkelig logging og monitorering. Lagt til fra undersøkelsen gjort i sikkerhetsmiljøet (#3), klatrer fra tiendeplassen. Denne kategorien er utvidet til å inkludere flere typer feil, er utfordrende å teste, og er ikke godt representert i CVE/CVSS-dataene. Imidlertid kan feil i denne kategorien direkte påvirke synlighet, hendelsesvarsling og etterforskningsarbeid.
A10:2021-Tjener-side anmodningsforfalskning (Ny)
Lagt til fra undersøkelsen gjort i sikkerhetsmiljøet (#1). Data viser relativt lav insidensrate, med over gjennomsnittet testdekning, samt over gjennomsnittet verdier for utnyttelsespotensiale og påvirkning. Denne kategorien representerer scenarioet hvor medlemmer av sikkerhetsmiljøet uttrykker at dette er viktig, selv om det ikke er reflektert i dataene på dette tidspunktet.
Metode
Åtte av de ti kategoriene er hentet fra data som kommer fra de deltagende virksomhetene. Imidlertid er det slik at når man ser på disse dataene, så skuer man bakover i tid. To av kategoriene (A9 og A10) kommer fra en høynivå utspørring av Top 10 sikkerhetsmiljøet.
Forskjeller
Før ble respondentene spurt om ca. 30 spesifikke sårbarheter fra CWE, og deretter om de hadde noe “ytterligere” å nevne. Denne gang har det vært fokus på bredere datagrunnlag; antallet applikasjoner som er testet per år (fra 2017) er registrert, og tallet på applikasjoner som har minst en CWE er notert (uten at man bryr seg om frekvensen). Dette omfatter ca. 400 CWEer, og det er gjennomsnittlig 19,6 CWEer per Top 10 kategori, med spennet fra 1 CWE for A10 til 40 CWEer for A4. CWEer er en blanding av symptomer og rotårsaker; dette er nå mer åpenbart. Der det har vært mulig, har fokuset vært på rotårsaker.
Hvordan velge en kategori?
For å velge ut hvilke kategorier som skulle være med på lista, brukte de i 2017-utgaven insidensrate for å bestemme sannsynlighet, og diskusjon i gruppa for å rangere etter utnyttbarhet, oppdagbarhet (også sannsynlighet) og teknisk konsekvens (impact). I 2021 fokuserte de på utnyttbarhet og teknisk konsekvens hvis mulig. Ved hjelp av OWASP Dependency Check ble CVSS-verdiene ekstrahert og etter en temmelig komplisert prosess ble et overordnet gjennomsnitt beregnet, som ble avbildet på CWEer i datasettet.
Hvorfor insidensrate i stedet for frekvens?
Insidensraten er prosenten av applikasjoner som er sårbare for en gitt CWE i populasjonen testet av en gitt virksomhet for det relevante året. Frekvensen, på den annen side, vil være hvor mange ganger man finner en CWE i den samme populasjonen – kan være flere per applikasjon.
OWASP Top 10 har tre primære datakilder:
- Menneske-støttet verktøy (HaT) (høy frekvens)
- Verktøy-støttet menneske (TaH) (lav frekvens)
- Rå verktøybruk (høy frekvens)
I kraft av sin natur vil TaH finne et bredere spekter av sårbarhetstyper, men med mye lavere frekvens grunnet tidsbegrensinger (og det er mennesket som er den begrensende faktoren). Hvis man bare slår sammen frekvenstall fra HaT og rå verktøybruk med TaH, vil sistnevnte drukne.
Datainnsamling og analyse
Denne prosessen ble først brukt i 2017. OWASP gikk bredt ut via sosiale media og ba om innspill. Det kom data fra test-leverandører, “bug bounty”-leverandører og virksomheter med interne testaktiviteter. De 8 kategoriene med høyest insidensrate ble valgt ut, og i tillegg ble de to viktigste kategoriene fra utspørringen av sikkerhetsmiljøet (som ikke allerede var inkludert blant de 8).