OWASP Top 10 2021 – en introduktion

Denna vecka tänkte vi att det är dags att kika närmare på OWASP Top 10 2021, som publicerades nyligen. Vad är nytt, vad är gammalt, vad har hänt – och varför?

OWASP Top 10 är en samling av de 10 mest vanligt förekommande sårbarheterna (eller sårbarhetskategorierna) i webbapplikationer. Det är egentligen utformat som en typ av utbildningsmaterial för att känna till dessa vanliga sårbarheter och är väldigt bra för utvecklingsteam att ha kännedom om. Vi, som it-säkerhetsspecialister, brukar använda det som en typ av ramverk för att utföra enklare penetrationstester. Det gör det möjligt för oss som utförare att fokusera på rätt saker – de mest vanligt förekommande sårbarheterna! Dock finns det ett antal kategorier i denna uppdaterade version som är svåra att praktiskt testa i ett black-box test, mer om det senare.

En tidsresa

Så här har kategorierna ändrats under de 4 senaste versionerna under det senaste decenniet:

Inga kategorier har försvunnit i den senaste versionen men under åren har flera kategorier slagits ihop. Kategorierna har generellt blivit mer övergripande och över tid har topplistan (eller snarare bottenlistan?) gått från mer specifika kategorier som kan användas som grund för penetrationstester (även om det inte har varit det primära syftet) till mer fokus på säkerhetslivscykeln av webbapplikationer. För praktiska tester har OWASP i stället sin OWASP Web Security Testing Guide.

Kategorierna i OWASP Top 10 2021

Nu tittar vi närmare på kategorierna i 2021 och vad de innebär.

A01 Felaktig åtkomstkontroll (Broken Access Control)

Denna kategori har klättrat upp från 5e plats till första. Statistiken visar att 94% av testade applikationer har någon brist i denna kategori, vilket gör det till en självklar ”vinnare” på denna bottenlista.

Det är en mycket bred kategori där alla möjliga sårbarheter som kan leda till att en obehörig åtkomst till information ingår. Oavsett om det är en behörig användare som får skrivbehörighet till ett objekt som denne inte ska ha åtkomst till eller en helt obehörig användare som tillskansar sig åtkomst till information. Sökvägstraversering, CSRF (Cross Site Request Forgery), känsligt innehåll i källkod, avsaknad av åtkomstkontroll och exponering av filer i kataloglistning, är bara en bråkdel av möjliga sårbarheter.

A02 Kryptografiska fel (Cryptographic Failures)

Kategorin har fått ett nytt namn, tidigare känd som Känslig dataexponering heter nu Kryptografiska fel och klivit upp en position i listan. Det uppdaterade namnet visar tydligare på orsaken till sårbarheten; osäkra kryptografiska algoritmer, felaktig användning av kryptografi, återanvändning av kryptografiska nycklar, avsaknad av kryptografi vid överföring av känsligt data etc.

Något som vi kan använda för att snabbt detektera vissa av dessa fel är exempelvis genom en sårbarhetsskanning. Det täcker inte alla möjligt sårbarheter men det kan påvisa om exempelvis TLS används felaktigt.

A03 Injektion (Injection)

Injektion har trillat ner från första plats till tredje. Det är fortfarande en väldigt hög förekomst av injektionssårbarheter i testade applikationer enligt OWASPs statistik. Injektionsangrepp är möjliga då data från användare inte valideras, filtreras eller sanera korrekt av applikationen och därefter processeras av applikationen. Vanliga förekomster av injektionssårbarheter är databasinjektioner, kodinjektioner, externa objektreferenser i XML och ORM (Object-relational mapping) injektioner. Detta kan resultera i utdrag av databasen som annars inte ska vara åtkomligt, exekvering av kod på servern eller exekvering av kod i en användares webbläsare (exempelvis i form av ett XSS angrepp). Vid testning kontrolleras alla typer av indata för sårbarheter, vilket även inkluderar URL:er, http-fält och cookies. En bra metod för att identifiera denna typ av sårbarheter är att göra en kodgranskning. Det kan vara svårt att hitta alla möjliga injektionsmöjligheter via ett test av gränssnittet. Här kompletterar automatiserad och manuell testning varandra väl.

A04 Osäker design (Insecure Design)

En ny kategori – men ack så viktig. Vi har idag många paradigmer om att bygga rätt från grunden – Security by design och Privacy by design etc. Det är dock väldigt svårt att specificera vad som egentligen ingår i denna kategori och andra kategorier är symptom för denna ”sårbarhetskategori”. Säkerhet måste ingå i hela utvecklingslivcykeln, från design till utveckling och test ända fram till produktion och vidareutveckling. Från en testares perspektiv kan vi exempelvis observera om det finns principiella fel som används genomgående i lösningen som testas. Vi kan också granska rutiner och dokumentation för utveckling och testning av lösningen. Det är alltså väldigt svårt att utföra tester i ett black-box test för att upptäcka sårbarheter relevanta för denna kategori.

A05 Felaktig säkerhetskonfiguration (Security Misconfiguration)

Denna kategori har gått upp ett steg i rankning och en av de tidigare sårbarheterna, externa objektreferenser i XML s.k. XXE, ingår numera i denna övergripande kategori. Sårbarheterna som berörs av denna kategori beror på avsaknad av härdning eller felaktig konfiguration av system, onödiga tjänster, användning av standardkonton eller att säkerhetsfunktioner inte har konfigurerats/aktiverats.

A06 Sårbara och utdaterade komponenter (Vulnerable and Outdated Components)

Tidigare hette kategorin ”Användning av komponenter med kända sårbarheter”. Den uppdaterade kategorin täcker fler fall som kan leda till sårbarheter. Exempelvis ingår komponenter som kanske nått EOL (End of Life) och saknar support och inte längre patchas, men (ännu) inte har kända sårbarheter. Berörda komponenter kan vara operativsystem, serverprogramvara, databaser, applikationer, APIer och bibliotek som används av lösningen. Återigen är en metod att kontrollera sårbarheter en sårbarhetsskanning och fingerprinting. Även andra kontroller kan användas för att kontrollera vilka versioner av olika komponenter som används av systemet.

A07 Identifierings- och autentiseringsfel (Identification and Authentication Failures)

Kategorin har trillat ner ett flertal positioner och var tidigare känd som Brister i autentisering (Broken Authentication). Nu ingår även sårbarheter relaterade till identifiering. I korthet är det sårbarheter som berör autentisering, så som brute force autentiseringsangrepp, tillåter svaga lösenord, avsaknad eller dålig implementation av flerfaktorautentisering och återanvändning av sessionsdata. Det mesta som har med sessioner och inloggning att göra alltså!

A08 Mjukvaru- och dataintegritetsfel (Software and Data Integrity Failures)

Detta är en ny kategori i listan och OWASP beskriver att detta handlar om antaganden kring integriteten av mjukvaror/mjukvaru-uppdateringar och kontinuerlig integration/kontinuerlig leverans (CI/CD). Lösningar litar på automatiska uppdateringar från källor som kanske inte är kontrollerade. Osäkerhet i denna leverans kan resultera i obehörig tillgång exempelvis genom skadlig kod, så kallad supply chain attack. Åtgärder som är relevanta är att försäkra att leveransen sker från behöriga källor och att signaturer kontrolleras innan de tas i bruk. Kod kan även granskas för skadliga komponenter. I likhet med A04 har denna kategori mer att göra med rutiner kring kodens och lösningens livscykel.

A09 Säkerhetsloggning och övervakningsfel (Security Logging and Monitoring Failures)

Ännu en kategori som berör hanteringen kring en lösning, denna kategori var på position 10 i föregående version. Kategorin är till stor del självförklarande, för att upptäcka säkerhetsincidenter måste det finnas loggning och övervakning av rätt saker. Avsaknad av loggar som berör inloggning (lyckade och misslyckade), fel i systemet och övervakning av viktiga anrop gör det omöjligt att identifiera vad som har hänt om en incident sker. En annan del är hur övervakning och lagring av loggar sker. Incidenter kan inte upptäckas om de inte händelser övervakas. Loggarna måste också lagras på ett sådant sätt att minimera risken att de förvanskas. Från ett testningsperspektiv är detta mer en granskningsfråga. Det är också möjligt att kontrollera om organisationen har reagerat på avvikelser under ett penetrationstest.

A10 Server Side Request Forgery (SSRF)

På plats 10 har vi en ny och möjligtvis udda kategori – denna är en ganska specifik sårbarhet. Sårbarheten innebär att en angripare har möjlighet att skicka förfrågningar från en back-end server på en sårbar webbserver. Denna sårbara servern används sedan för att angripa interna system. Angriparen har helt eller delvis kontroll över de förfrågningar som webbservern skickar. Detta kan leda till att systemet hämtar data från en extern server som angriparen kontrollerar eller möjligtvis att den gör anrop till interna system som webbservern har åtkomst till. OWASP noterar att denna typ av sårbarhet blir allt allvarligare på grund av molntjänster och ökande komplexitet av arkitektur. Det återstår och se hur denna kategori förändras över tid!

Sammanfattning

Från ett testningsperspektiv är OWASP Top 10 en miniminivå om det används som ett underlag för penetrationstest av webbapplikationer. Det finns många sårbarheter som fortfarande ligger utanför listan. Om ett penetrationstest baseras endast på OWASP Top 10 skulle eventuellt en mängd sårbarheter missas! Rent praktiskt så är det inte heller möjligt att utföra tester för alla kategorier i exempelvis ett black-box test utan vissa kräver andra typer av kontroller. Det är en bra utgångspunkt och ett test kan resultera i något som påvisar en mognadsgrad avseende säkerhetsnivån i en webbapplikation.

Något som vi hoppas se är att listan börjar användas av fler! Ett stöd för exempelvis utvecklare, administratörer, driftleverantörer och andra involverade i webbapplikationslösningar. Kategorierna berör trots allt sårbarheter relaterade till allt från design, utveckling och test till drift och övervakning!