Vad är OWASP Top 10?

Open Web Application Security Project (OWASP) är ett nätverk för applikationssäkerhet med öppen källkod som har som mål att förbättra säkerheten för programvara. OWASP Top 10 är en branschstandardriktlinje som listar de mest kritiska säkerhetsriskerna för applikationer för att hjälpa utvecklare att bättre säkra de applikationer de designar och distribuerar.

Eftersom säkerhetsrisker ständigt utvecklas revideras OWASP Top 10-listan med jämna mellanrum för att återspegla dessa förändringar. I den senaste versionen av OWASP Top 10 som släpptes 2021 ersattes vissa typer av sårbarheter som inte längre utgör ett allvarligt hot med sådana som mest sannolikt kommer att utgöra en betydande risk.

Medan OWASP Top 10 är ett bra ställe att börja säkra applikationer, bör det verkligen inte betraktas som ett slutmål, eftersom några av de mest citerade sårbarheterna inte kom in i OWASP Top 10 2021. För att skydda sig mot svagheter i programvaran måste försvarare se bredare över hela sin informationstekniska stack. Detta innebär att IT-säkerhetspersonal måste fokusera på hela programvarans ekosystem och se bortom de "traditionella" källorna till sårbarheter.

Vilka är OWASP Top 10 (2021) -kategorierna?

A1: Injektion

Injektionsfel kan introduceras när en icke betrodd datakälla skickas till en tolk. Exempel finns ofta i SQL-, LDAP-, XPath- eller NoSQL-dynamiska databasfrågor med användarinmatning. Angripare injicerar kod i användarinmatningen och lurar frågetolken att utföra skadliga kommandon.

Vad gör en applikation sårbar för injektionsfel?

• Användartillhandahållna data valideras inte i tillräcklig utsträckning.
• Dynamiska frågor körs utan tillräcklig rensning av indata.
• Fientliga data som används inom system för skadligt beteende.

Vad är effekten av injektionsfel?

• Kompromiss av applikationen eller den underliggande värden.
• Exponering av känsliga uppgifter.
• Förlust av produktivitet, anseende eller intäkter.

Hur kan Fortify hjälpa till med injektionsfel?

• Om du är utvecklare: Fortify upptäcker injektionsfel och ger typspecifika råd om hur du kan åtgärda dem.
• Om du arbetar inom QA eller Operations: Fortify validerar koden vid körning för att hitta riskreducerande kontroller.
• Om du arbetar i Operations: Fortify tillhandahåller loggning under körning och skydd för injektionsförsök i Java och .NET.

---

A2: Bruten autentisering

Bruten autentisering kan uppstå vid hantering av identitets- eller sessionsdata i stateful-applikationer. Exempel finns ofta när registrering, återställning av referenser och API-vägar är sårbara för oanvända sessionstoken, brute forcing eller uppräkning av konton. Angripare antar legitima användares identitet, tar kontroll över konton och äventyrar data, processer eller system.

Vad gör en applikation sårbar för bruten autentisering?

• Exponerar, ogiltigförklarar inte korrekt eller misslyckas med att rotera sessions-ID:n.
• Anpassar inte lösenordspolicyn till standarder som NIST 800-63B.
• Saknar tvåfaktorsautentisering (2FA) eller tillåter automatiserade attacker.

Vad är effekten av bruten autentisering?

• Stöld av användares identitet.
• Förlust av användarnas förtroende.
• Kompromittering av känsliga uppgifter.

Hur kan Fortify hjälpa till?

• Om du är utvecklare: Fortify upptäcker och rekommenderar åtgärder för problem med bruten autentisering.
• Om du arbetar med QA eller Operations: Fortify validerar autentisering och säkerhet för sessionshantering dynamiskt.
• Om du är i Operations: Fortify instrument runtime-övervakning för Java- och .NET-applikationshändelser.

---

A3: Exponering av känsliga uppgifter

Problem med exponering av känsliga data kan uppstå när applikationer får åtkomst till okrypterad data, i synnerhet personligt identifierbar information (PII) och andra reglerade datatyper. Exempel på detta är ofta när svaga kryptografiska chiffer används i äldre applikationer, säkra transportprotokoll implementeras på ett felaktigt sätt eller datacentrerad säkerhet inte används. Angripare får tillgång till känslig användardata som ger dem kontroll i verkliga livet.

Vad gör en applikation sårbar för exponering av känsliga data?

• Överföring av data i klartext via protokoll som HTTP, SMTP och FTP.
• Känsliga uppgifter lagras, överförs eller används i onödan i klartext.
• Användning av gamla, svaga eller icke-standardbaserade kryptografiska algoritmer.

Vilka är konsekvenserna av att känsliga uppgifter exponeras?

• Kompromittering av reglerad data (t.ex. HIPAA eller GDPR) som leder till böter.
• Identitetskapning som leder till kostnader för att rensa eller övervaka data.
• Status för bristande efterlevnad av lagar och förordningar om integritet.

Hur kan Fortify hjälpa till med exponering av känsliga uppgifter?

• Om du är utvecklare: Fortify identifierar exponering av känsliga data och automatiserar granskningen av problem.
• Om du arbetar med kvalitetssäkring eller drift: Fortify tar bort resultat som mildras utanför applikationskontexten med templating.
• Om du är i Operations: Fortify instrument loggning och skydd för applikationer i Java och .NET.

---

A4: XML externa enheter

XML External Entity-problem kan uppstå när XML-data som innehåller en referens till en extern entitet behandlas av en svagt konfigurerad parser. Exempel på detta finns ofta i applikationer som analyserar XML-data från icke betrodda källor, när DTD:er (Document Type Definitions) är aktiverade eller som använder opatchade ramverk som SOAP 1.0. XML finns överallt - från SVG- och bildfiler till nätverksprotokoll och dokumentformat som PDF och RSS. Angripare refererar till externa enheter i XML-inmatning som resulterar i processorer som utnyttjas för att extrahera data, exekvera kod på distans eller påverka nätverkstjänster.

Vad gör en applikation sårbar för externa XML-enheter?

• Programmet analyserar XML-dokument och processorerna har DTD:er aktiverade.
• Använda SAML för SSO, SOAP före v1.2 eller .NET Framework före v2.0.
• Parsern accepterar otillförlitliga källor eller infogar otillförlitliga XML-data.

Vad är effekten av XML externa enheter?

• Stöld av känsliga uppgifter.
• Laddning av angriparstyrd URL.
• Överbelastningsattacker (Denial of Service, DoS).

Hur kan Fortify hjälpa till med externa XML-enheter?

• Om du är utvecklare: Fortify upptäcker sårbara XML-parsers och rekommenderar åtgärder för att minska riskerna.
• Om du arbetar inom QA eller Operations: Fortify söker automatiskt efter sårbara XML-parsers och validerar exploateringsnyttolaster.
• Om du arbetar i Operations: Fortify tillhandahåller loggning under körning och skydd för problem i Java- och .NET-applikationer.

---

A5: Bristande åtkomstkontroll

Problem med åtkomstkontroll kan uppstå när kod- och miljörestriktioner överlappar varandra på ett ofullständigt sätt eller definieras på flera ställen för liknande funktioner. Exempel på detta är ofta när "security-by-obscurity" bryts genom tvingande surfning till begränsade sidor, eller när applikationen definierar komplexa metoder för åtkomstkontroll på flera sätt och platser. Angripare kan kompromissa med åtkomstgränser för att stjäla känsliga data eller störa verksamheten.

Vad gör en applikation sårbar för bristande åtkomstkontroll?

• Möjlighet att agera som användare utan inloggning eller som administratör när du är inloggad som användare.
• Manipulation av metadata eller tokens för obehöriga eller utökade behörigheter.
• Byzantinsk, icke genomdriven eller spridd logik för åtkomstkontroll.

Hur påverkas vi av att tillträdeskontrollen inte fungerar?

• Obehörigt röjande av information eller äventyrande av känsliga uppgifter.
• Ändring eller förstöring av uppgifter.
• Övertagande av webbplatsadministration eller användare.

Hur kan Fortify hjälpa till med trasig passerkontroll?

• Om du är utvecklare: Fortify automatiserar granskningen och gör det möjligt att använda templating för att ta bort problem som har åtgärdats på annat håll.
• Om du arbetar med kvalitetssäkring och drift: Fortify agenter upptäcker dolda attackytor och trasiga system för åtkomstkontroll.
• Om du är i Operations: Fortify instruments runtime access control logging for Java and .NET applications.

---

A6: Felaktig säkerhetskonfiguration

Säkerhetsbrister i form av felkonfigurationer kan uppstå under konfigurationen av applikationen eller dess underliggande miljö. Felkonfigurationer kan inträffa på alla nivåer i en applikationsstack - från nätverkstjänster och applikationsservrar till containrar och lagring. Exempel finns ofta i standardkonton och konfigurationer, "läckande" felmeddelanden eller opatchade ramverk och tjänster. Angripare kan få information om driftsättning och tillgång till privilegierad data för att störa verksamheten.

Vad gör en applikation sårbar för felaktig säkerhetskonfiguration?

• Onödigt aktiverade standardportar och konton eller oförändrade lösenord.
• Visning av stackspårning eller andra meddelanden vid fel och undantag.
• Att inte på lämpligt sätt stärka säkerheten för den risk som någon del av stacken utgör.

Vilka är konsekvenserna av felaktig säkerhetskonfiguration?

Konsekvenserna kan variera från att information röjs till att hela systemet äventyras.

Hur kan Fortify hjälpa till med felaktig säkerhetskonfiguration?

• Om du är utvecklare: Fortify identifierar programberoenden och konfigurationsfiler under genomsökningar.
• Om du arbetar med QA och Operations: Fortify utvärderar dynamiskt program- och serverkonfigurationer för att hitta problem.
• Om du är verksam inom Operations: Fortify tillhandahåller analys med öppen källkod för rapportering av miljörisker.

---

A7: Skript över flera webbplatser

XSS-brister (Cross-Site Scripting) kan uppstå när otillförlitlig, okontrollerad användarinmatning exekveras som en del av HTML-koden, eller när användare kan påverkas att interagera med skadliga länkar. Exempel finns ofta när välkända kodkonstruktioner från språk som JavaScript eller Flash accepteras från icke betrodda källor eller lagras för senare visning av en annan användaragent. Angripare kan köra fjärrkod på användarens dator, stjäla inloggningsuppgifter eller leverera skadlig kod från omdirigeringssidor.

Vad gör en applikation sårbar för cross-site scripting (XSS)?

Det finns tre olika former av XSS, som vanligtvis riktar sig mot användaragenter som webbläsare:

• Reflekterad XSS: Programmet eller API:et innehåller otillförlitlig indata i HTML-utdata.
• Lagrad XSS: Icke-sanerad kod som sparas på disk utlöses senare av en användaråtgärd.
• DOM XSS: Applikationer, ramverk och API:er som använder otillförlitlig indata.

Vad är effekten av cross-site scripting (XSS)?

• Övertagande av offrets konto i applikationen.
• Hämtning av data från målwebbapplikationen.
• Modifiering av innehåll på sidan.

Hur kan Fortify hjälpa till med cross-site scripting (XSS)?

• Om du är utvecklare: Fortify upptäcker XSS-sårbarheter i kod och förutspår sannolikheten för exploatering.
• Om du arbetar inom QA och Operations: Fortify validerar koden dynamiskt för osanerade inmatningar som är sårbara för XSS.
• Om du arbetar i Operations: Fortify tillhandahåller loggning för Java- och .NET-händelser, inklusive obehörig omdirigering.

---

A8: Osäker deserialisering

Osäkra deserialiseringsbrister kan uppstå när språk och ramverk tillåter att icke betrodda serialiserade data expanderas till ett objekt, ofta när webbapplikationer kommunicerar med användare eller sparar applikationsstatus. Exempel finns ofta när utvecklare inte lägger några restriktioner på metoder som kan utföra sig själva under deserialiseringsprocessen. Angripare utnyttjar dessa "gadgetkedjor" som kallas utanför applikationslogiken för att fjärrköra kod, neka service eller få obehörig åtkomst.

Vad gör en applikation sårbar för osäker deserialisering?

• Programmet deserialiserar data från icke betrodda källor.
• Programmet verifierar inte källan eller innehållet före deserialisering.
• Godtagbara klasser är inte vitlistade för att undvika onödig exponering av prylar.

Vad är effekten av osäker deserialisering?

• Dessa brister kan leda till att fjärrkod kan exekveras, vilket är en av de allvarligaste attackerna som finns.

Hur kan Fortify hjälpa till med osäker deserialisering?

• Om du är utvecklare: Fortify upptäcker sårbarheter i källkoden och tillhandahåller komponentanalys.
• Om du arbetar med QA och Operations: Fortify instrument som dynamiskt kör applikationer för att validera attackvektorer.
• Om du är i Operations: Fortify instrument loggning för Java och .NET händelser inklusive deserialisering.

---

A9: Använda komponenter med kända sårbarheter

Dessa brister kan uppstå när ramverk och bibliotek med öppen källkod eller från tredje part introduceras i en applikation och körs med samma privilegier. Det finns ofta exempel på komponentbaserad utveckling som leder till bristande förståelse för riskerna med beroenden och komponenter eller system som är svåra eller omöjliga att patcha. Angripare har utnyttjat sårbara komponenter för några av de största intrången i historien, även om sårbarheterna kan sträcka sig från applikationskompromittering till exekvering av fjärrkod.

Vad gör en applikation sårbar för ramverk och bibliotek med öppen källkod eller från tredje part?

• Dessa kan vara oavsiktliga (t.ex. kodningsfel) eller avsiktliga (t.ex. komponent med bakdörr).
• Applikationen eller miljön använder opatchade eller föråldrade komponenter (en av anledningarna till att applikationsmodernisering är nödvändig).
• Avsaknad av skanning efter sårbarheter i tredjepartskod eller kapslade beroenden.
• Otillgängliga komponentförteckningar eller ignorerade säkerhetsbulletiner.

Vilka konsekvenser får det om man använder komponenter med kända sårbarheter?

Vissa kända sårbarheter leder endast till mindre konsekvenser, men några av de största kända intrången, som Heartbleed och Shellshock, har byggt på utnyttjande av kända sårbarheter i delade komponenter. Att använda komponenter med kända sårbarheter i koden kan resultera i fjärrstyrd exekvering av kod på den drabbade servern, vilket ger angriparen total kontroll över maskinen.

Hur kan Fortify hjälpa till med säkerhet för öppen källkod?

• Om du är utvecklare: Fortify tillhandahåller analys av programvarukomponenter via Sonatype-integreringar.
• Om du arbetar med kvalitetssäkring och drift: Fortify automatiserar dynamisk validering av kända sårbarheter under körning.
• Om du befinner dig i Operations: Fortify instrument loggning och skydd för Java- och .NET-applikationskomponenter.

---

A10: Otillräcklig loggning och övervakning

Otillräcklig loggning och övervakning kan uppstå när man inte förstår attackvektorer eller applikationers felaktiga beteende eller när man inte följer bästa praxis för övervakning av indikatorer på kompromettering. Exempel på detta finns ofta i äldre system utan loggningsfunktioner, när loggar från penetrationstester av applikationer inte granskas eller när loggar inte ger tillräckligt med detaljer för att förstå vad angriparna gjorde. Angripare förlitar sig i genomsnitt på cirka 200 dagar för upptäckt som vanligtvis upptäcks externt för att etablera uthållighet och svänga till ytterligare sårbara system.

Vad är det som gör en applikation sårbar för otillräcklig loggning och övervakning?

• Varningar och fel genererar inga, otillräckliga eller otydliga loggmeddelanden.
• Loggar lagras lokalt utan manipuleringskontroll och/eller är oövervakade.
• Tröskelvärden för larm och svarsprocesser är otillräckliga eller leder inte till någon åtgärd.

Vad är effekten av otillräcklig loggning och övervakning?

De flesta framgångsrika attacker börjar med att sårbarheter undersöks. Om man tillåter att sådan sondering fortsätter kan det öka sannolikheten för framgångsrika exploateringar. Angripare kan bli långvariga, ta sig in i applikationer och operativsystem, stjäla data eller på annat sätt få obemärkt och obehörig kontroll över system. Om säkerhetskritisk information inte registreras eller lagras på lämpligt sätt finns det inget spår för kriminalteknisk analys för att upptäcka källan till attacken. Att förstå att det överhuvudtaget finns ett problem kan bli svårare, eller omöjligt, om angriparen har kontroll över loggningsfunktionerna.

Hur kan Fortify hjälpa till med otillräcklig loggning och övervakning?

• Om du är utvecklare: Fortify söker efter sårbarheter i loggningsfunktioner i applikationer och API:er.
• Om du arbetar med kvalitetssäkring och drift: Fortify dynamiska skanningar producerar applikationsloggar för granskning av tillräcklighet, som penntestning.
• Om du är i Operations: Fortify instrument loggning och skydd för Java- och .NET-applikationer.

---

Vad är nytt för OWASP (2021)?

Även om det bara har gått fyra år sedan den senaste topp 10 publicerades 2017, har det skett många förändringar i cybersäkerhetsbranschen som har fått oss att tänka två gånger om när det gäller de mest prioriterade frågorna eller vilka nya frågor som ska läggas till.

Tre nya kategorier infördes:

A04:2021

Osäker design: Denna kategori fokuserar på designfel. Detta behövs eftersom rörelsen för att skifta vänster i utvecklingen kräver ett skifte till vänster även för hotmodellering.

A08:2021

Fel i programvaru- och dataintegritet: Fokuserar på antaganden kring programuppdateringar, kritiska data och CI/CD-pipelinen utan att verifiera den integritet som de kan påverka. Detta omfattar även A08:2017 - Osäker deserialisering.

A10:2021

Förfalskning av begäran på serversidan (SSRF): Denna kategori är mestadels i topp 10 från samhällsundersökningen. De betonade verkligen denna sårbarhet på grund av exploaterbarheten och påverkan över genomsnittet.

Övriga förändringar

De övriga kategorierna har antingen bytt namn, flyttat rangordning eller slagits samman till andra kategorier:

• A01:2017 - Injektion flyttad ner till A:03.
• A02:2017 - Broken Authentication döptes om till Identification and Authentication Failures och flyttades ner till A07.
• A03:2017 - Känslig dataexponering flyttades upp till A02 och döptes om till kryptografiska fel för att i högre grad ta itu med grundorsaken, inte bara symptomen.
• A05:2017 - Broken Access Control flyttades till A01 eftersom 94% av de testade applikationerna visade exponering för någon form av Broken Access Control.
• A06:2017 - Felaktig säkerhetskonfiguration flyttades upp en placering till A05.
• A07:2017 - Cross-Site Scripting (XSS) konsoliderades till A03 Injection.
• A09:2017 - Using Components with Known Vulnerabilities flyttades upp till A06 och döptes om till Vulnerable and Outdated Components. Denna förändring berodde till stor del på att communityn rankade den som #2 på sin lista.
• A10:2017 - Otillräcklig loggning och övervakning flyttades upp från A09 och heter nu Security Logging and Monitoring Failures.

Vill du se hur Fortify kan hjälpa din organisation? Starta din kostnadsfria 15-dagars provperiod av Fortify on Demand via OpenText™ nu