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 branschstandard 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 har vissa typer av sårbarheter som inte längre utgör ett allvarligt hot ersatts med sådana som sannolikt kommer att utgöra en betydande risk.

Även om 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örsvararna se bredare över hela sin informationstekniska stack. Det innebär att IT-säkerhetspersonal måste fokusera på hela mjukvarans ekosystem och se bortom de "traditionella" källorna till sårbarheter.

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

A1: Injektion

Injektionsfel kan uppstå 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ändarens inmatning, vilket 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 en utvecklare: Fortify upptäcker injektionsbrister och ger typspecifika råd om hur de kan åtgärdas.
• Om du arbetar inom QA eller Operations: Fortify validerar kod i körtid för att hitta begränsande kontroller.
• Om du arbetar inom Operations: Fortify tillhandahåller loggning under körtid och skydd för injektionsförsök i Java och .NET.

A2: Bruten autentisering

Bruten autentisering kan införas 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 tar sig an 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 inom QA eller Operations: Fortify validerar autentiserings- och sessionshanteringssäkerhet dynamiskt.
• Om du är i Operations: Fortify övervakar händelser i Java- och .NET-applikationer under körtid.

A3: Exponering av känsliga uppgifter

Problem med exponering av känsliga data kan uppstå när applikationer får tillgång till okrypterad data, särskilt personligt identifierbar information (PII) och andra reglerade datatyper. Exempel på detta är ofta att svaga kryptografiska chiffer används i äldre applikationer, att säkra transportprotokoll implementeras på ett felaktigt sätt eller att datacentrerad säkerhet inte används. Angripare får tillgång till känsliga 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), vilket kan leda 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änslig data?

• Om du är en utvecklare: Fortify identifierar exponering av känslig data och automatiserar granskning av problem.
• Om du arbetar inom QA eller Operations: Fortify tar bort fynd som mildrats utanför applikationskontexten med hjälp av 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 en XML-inmatning 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 tillförlitliga 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, köra 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 en utvecklare: Fortify upptäcker sårbara XML-parsers och rekommenderar begränsande faktorer.
• Om du är i QA eller Operations: Fortify söker automatiskt efter sårbara XML-parsers och validerar nyttolaster för exploateringar.
• Om du arbetar inom 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 att man tvingas surfa till begränsade sidor, eller när applikationen definierar komplexa metoder för åtkomstkontroll på flera olika sätt och platser. Angripare kan ta sig igenom å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.
• Manipulering 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 åtkomstkontroll?

• Om du är en utvecklare: Fortify automatiserar granskningen och gör det möjligt att använda mallar för att ta bort problem som har åtgärdats på annat håll.
• Om du är inom QA och Operations: Fortify-agenter upptäcker dolda attackytor och trasiga system för åtkomstkontroll.
• Om du är i Operations: Fortify styr loggning av åtkomstkontroll under körning för Java- och .NET-applikationer.

A6: Felaktig säkerhetskonfiguration

Brister i säkerhetskonfigurationen kan uppstå under konfigurationen av applikationen eller dess underliggande miljö. Felkonfigurering kan inträffa på alla nivåer i en applikationsstack - från nätverkstjänster och applikationsservrar till containrar och lagring. Exempel på detta finns ofta i standardkonton och konfigurationer, "leaky" felmeddelanden eller opatchade ramverk och tjänster. Angripare kan få information om utplacering 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 förstä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 en utvecklare: Fortify identifierar programberoenden och konfigurationsfiler under genomsökningar.
• Om du arbetar inom QA och Operations: Fortify utvärderar dynamiskt program- och serverkonfigurationer för att upptäcka problem.
• Om du är i 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, icke-sanerad användarinmatning exekveras som en del av HTML, eller när användare kan påverkas att interagera med skadliga länkar. Exempel på detta är när välbekanta kodkonstruktioner från språk som JavaScript eller Flash accepteras från otillförlitliga källor eller lagras för att senare visas av en annan användaragent. Angripare kan köra fjärrkod på användarens dator, stjäla autentiseringsuppgifter 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 en utvecklare: Fortify upptäcker XSS-sårbarheter i kod och förutspår sannolikheten för utnyttjande.
• Om du är inom QA och Operations: Fortify validerar kod dynamiskt för osanitiserade inmatningar som är sårbara för XSS.
• Om du arbetar inom 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 exekvera sig själva under deserialiseringsprocessen. Angripare utnyttjar dessa "gadgetkedjor" som anropas 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 gadgets.

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 en utvecklare: Fortify upptäcker sårbarheter i källkoden och tillhandahåller komponentanalys.
• Om du är inom QA och Operations: Fortify instrument som dynamiskt kör applikationer för att validera attackvektorer.
• Om du är i Operations: Fortify instrumentloggar 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å att komponentbaserad utveckling leder till bristande förståelse för riskerna med beroenden och att komponenter eller system ä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årbarheter kan variera från applikationskompromittering till fjärrkörning av kod.

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 avsiktligt (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?

Även om vissa kända sårbarheter endast leder till mindre konsekvenser, har några av de största kända intrången, som Heartbleed och Shellshock, byggt på att man utnyttjat kända sårbarheter i delade komponenter. Om man använder komponenter med kända sårbarheter i koden kan det resultera i fjärrkörning av kod på den berörda 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-integrationer.
• Om du arbetar inom QA och Operations: Fortify automatiserar dynamisk validering av kända sårbarheter vid körning.
• Om du är 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 attackvektorer eller applikationers felaktiga beteende inte förstås väl eller när bästa praxis för övervakning av indikatorer på kompromettering inte följs. Exempel på detta finns ofta i äldre system utan loggningsfunktioner, när loggar från penetrationstestning 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 undersöka sårbarheter. Att låta sådana sonderingar fortsätta kan öka sannolikheten för framgångsrika exploateringar. Angripare kan skapa uthållighet, ta sig in i applikationer och operativsystem, stjäla data eller på annat sätt få obemärkt, 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 är inom QA och Operations: Fortify dynamiska skanningar producerar applikationsloggar för granskning av tillräcklighet, som pen-testning.
• 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 inom utveckling kräver ett skifte vänster även för hotmodellering.

A08:2021

Fel i programvaru- och dataintegritet: Fokuserar på antaganden kring programuppdateringar, kritisk 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): Den här kategorin är oftast bland de 10 bästa från community-undersökningen. De betonade verkligen denna sårbarhet på grund av den över genomsnittliga exploaterbarheten och effekten.

Ö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 applikationer som de testade 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 samhället rankade den som nummer 2 på sin lista.
• A10:2017 - Otillräcklig loggning & Ö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 gratis 15-dagars testversion av Fortify on Demand av OpenText™ Nu