vad är OWASP Top 10 sårbarheter lista?
först utfärdades 2004 av Open Web Application Security Project, den nu berömda OWASP Top 10 sårbarheter lista (ingår längst ner i artikeln) är förmodligen det närmaste att utvecklingsgemenskapen någonsin har kommit till en uppsättning bud om hur man håller sina produkter säkra.,
den här listan representerar de mest relevanta hoten mot mjukvarusäkerhet idag enligt OWASP, till pannan-smacking av många som undrar hur SQL-injektioner fortfarande är en sådan oro efter alla dessa år. De bedömer sårbarhetstyper baserat på fyra kriteriepunkter:
- enkel exploatering
- prevalenser
- detekterbarhet
- affärseffekt
intressant nog säger OWASP att de inte faktiskt faktor i deras ekvation sannolikheten för att angripare kommer att försöka utnyttja en viss sårbarhet.,
När det började bestämde författarna att det bästa sättet att täcka mest mark var att sätta liknande sårbarheter som de trodde var mest oroade i grupperingar. De erkände att brist på korrekt statistik kan det alltid finnas en fråga om vilka sårbarheter som nödvändigtvis var de bästa bekymmerna, särskilt eftersom detta kan vara en subjektiv fråga enligt varje organisations hotmodell.
men efter mycket debatt erbjöd de sin lista över vad de trodde att ta itu med den bredaste uppsättningen organisationer, om än inte i någon särskilt ordning.,
med tiden antogs OWASP Top 10 Sårbarhetslistan som standard för bästa praxis och krav från många organisationer och satte en standard i en mening för utveckling. En välkänd användare av listan är betalningshanteringsstandarderna för PCI-DSS.
tyvärr, eftersom OWASP Top 10 sårbarheter listan har nått en bredare publik, dess verkliga avsikter som en guide har misstolkats, skada utvecklare i stället för att hjälpa. Så hur ska vi förstå syftet med denna lista och faktiskt uppmuntra utvecklare att koda säkrare?,
förstå uppdateringar till 2017-listan
under åren sedan har de uppdaterat och omordnat posterna och lagt till några nya sårbarhetstyper när de blir relevanta, även om andra släpptes från listan. Nya versioner har utfärdats 2010, 2013 och 2017. Den nya listan samlades efter en lång och mödosam studie som tittade på mer än 50 000 applikationer och analyserade några 2,3 miljoner sårbarheter.,
regelbundna efterföljare av listan kommer att ha märkt att tillsammans med vissa ändringar i ordern — trots att injektionsattacker kvarstår — finns det några nykomlingar till 2017-uppdaterade versionen av OWASP Top 10 sårbarheter familj.
slå ut tävlingen för att tum sin väg ut på fältet genom att sparka av ovaliderade omdirigeringar och framåt är frågan om oskyddade API: er., Dess införande på listan på nummer A10-platsen är sannolikt resultatet av det faktum att utvecklare helt enkelt är mycket mer beroende av API: er än de brukade, interagera med mycket fler komponenter och externa produkter än tidigare. Att komma in på A7-platsen är otillräckligt attackskydd, vilket slår utvecklare för att inte vara tillräckligt omfattande för att lägga till skydd för att upptäcka, loggning och naturligtvis reagera på försök att skada sina produkter.,
den andra stora förändringen här i 2017-versionen är kombinationen av A4: s Osäkra direkta objektreferenser och A7-åtkomstkontroll som saknas, vilket skapar en enhetlig sårbarhet för bruten åtkomstkontroll och belyser behovet av att korrekt upprätta kontroller för vem som kan och inte kan komma åt konton och data.,
feltolkar OWASP Top 10 Sårbarhetslistan
en kraft för gott, den här listan har tyvärr förvandlats till ett verktyg för att skämma utvecklare som inte följer sina läror, som används som en klubb för att bereda dem för att inte vara perfekt när det gäller säkerhet. Detta tillvägagångssätt är kontraproduktivt och missar OWASP uppdrag att uppmuntra och utrusta utvecklare att koda säkrare. Dessutom, det misslyckas med att erkänna prestationer av poängen av utvecklare som driver ut massiva mängder av ny programvara på en aldrig tidigare sett hastighet.,
i en intervju nyligen uttryckte OWASPS ordförande Martin Knobloch sin besvikelse över att listan användes som en slags checklista för en slutlig körning före en release, som tjänar mer som en valideringsmekanism än en guide.
som någon som tror starkt på en shift-left – inställning till säkerhet är jag inte överraskande i överväldigande överenskommelse med Knoblochs frustration över hur många som har tagit OWASP Top 10-listan som ett instrument för FUD, och inte uppsättningen vägledande principer som den var avsedd att vara.,
utmanande Branschstrategier för säkerhet
organisatoriska säkerhetsstrategier som beror på att man förväntar sig misslyckande från de mänskliga elementen i hur de skyddar programvara till förmån för glänsande verktyg kommer säkert att misslyckas.
under de senaste åren har meddelandena från alltför många leverantörer, särskilt på nätverkssidan, varit att ”omkretsen är död” och att företag måste söka säkerhet på djupet för att hitta skurkarna som redan finns i deras nätverk., Alltför många rubriker på konferenser har försökt att övertyga CISOs att lag av elithackare Gunnar för dem med rarifierade 0-dagars exploater som kommer att lämna dem försvarslösa om de inte köper sin produkt som på något sätt kommer att göra dem ointagliga för dessa annars ostoppbara attacker.
denna syn på säkerhetsläget är onödigt fatalistisk, droppande med marknadsföring hype, och missar några av de grundläggande begreppen om hur säkerhetspersonal bör tänka på risk.,
en övergripande strategi för säkerhet bör inte predika att ta bort de mänskliga utvecklarna från processen, bara för att ta in en leverantörs säkerhetsverktyg för att fixa efter att de har avslutat sitt arbete. Detta förutsätter att utvecklarna inte kan lita på, är förolämpande och gör ingenting för att göra ditt lag starkare när det gäller säkerhet och riskhantering.
vad OWASP Top 10 Sårbarhetslistan är och är inte
några gånger om året finns det obligatoriska blogginlägget som frågar hur det är möjligt att vi i 2017 fortfarande pratar om script kiddie level-attacker., Jag har förmodligen skrivit några av dem själv, som jag ber om ursäkt för.
OWASP Top 10 är inte inställd för att lösa varje attack i boken, men för att hjälpa lag att undvika de vanliga misstagen som är mycket mer benägna att få sina applikationer överträdda. En bestämd angripare kan hitta många vägar att bryta sitt mål. De smarta riskhanteringsrådgivningarna fokuserar dock inte på minoriteten av fallen utan försöker i stället ta itu med de problem som den bredaste publiken står inför.,
för att dra av begreppen fysiskt säkerhetsfält, bör den genomsnittliga riskhanteraren vara mycket mer orolig för att hennes klient kommer in i en olycka på vägen än ninjas utbildade av SEAL Team 6 som kommer genom fönstren, styrd av AI (och blockchain).
verklig säkerhet handlar om att utbilda människor om hur man arbetar säkert och ge dem teknik, kunskap och processer för att göra det lättare för dem att vara säkra., Även om det alltid är viktigt att köra QA och slutliga säkerhetskontroller före en release, måste säkerheten börja i de tidigaste stadierna av hur ditt team fungerar, kör hela processen att utveckla produkten. Misstag kommer att hända, men det är mycket mer kostnadseffektivt och rent smartare att försöka undvika så många problem som möjligt i första hand.
För många utvecklare, drivande mål centrerar runt att få produkten att fungera, med fokus mindre på om det är säkert eller inte. Detta är inte deras fel.,
under hela sin utbildning lärde de sig att om de producerar en produkt med en minimal mängd buggar, så fick de en A. säkerhet skulle hanteras av en annan avdelning ändå. Istället måste chefer ta tillfället i akt att visa dem ett bättre sätt att arbeta som inkluderar att överväga hur de kodar, och de komponenter som de arbetar med, påverkar säkerheten för sin produkt.,
få 451 forskningsrapport om att säkra programvara med öppen källkod ladda ner gratis
praktiska steg för att möjliggöra bättre säkerhetsrutiner
en gemensam fallgrop som kom ut ur dagarna av vattenfallsutveckling var att vänta tills slutet av utvecklingscykeln för att utföra säkerhetskontroller, där utvecklarna skulle få en tvättlista över sårbarheter att fixa, fördröja frisläppandet och öka friktionen mellan dem och säkerhetsgruppen.,
i hopp om att smörja växlarna och hålla jämna steg med hastigheten på DevOps, organisationer letar efter nya sätt att säkra sin kod från början och upprätthålla harmoni mellan sina avdelningar.
en alltmer populär metod för att föra säkerhet i de tidigare stadierna av produktutveckling är i korsbestämande lag med en blandning av utvecklare och säkerhetsfolk, så att varje sida kan ge input och lära av varandra., Detta kan vara ett utmärkt tillfälle för säkerhetsexperter att ta upp många av de frågor som OWASP Top 10 försöker ta itu med i en mindre konfrontationsmiljö, i ett skede som faktiskt kan ha en inverkan.
När det gäller verktyg som kan bidra till att främja bättre säkerhetsgenomförande måste vi inte bara tänka på hur tekniken kan fånga våra misstag eller överträdelser efter det faktum, utan hjälpa oss att arbeta smartare och säkrare från de tidigaste stadierna., Detta perspektiv är en del av shift-left mentalitet, letar efter möjligheter att ta itu med problem innan de blir dyra problem.
integrerande teknik för att öka Utvecklarfunktionerna
ett tydligt exempel på hur teknik för att flytta vänster kan hjälpa utvecklare att utnyttja OWASP Top 10 kommer med nummer 9-posten som varnar för att använda komponenter med kända sårbarheter. Ett av de vanligaste problemen som uppstår i detta utrymme är att få synlighet över vad som finns i de öppna källkomponenterna som de har lagt till i sin produkt.,
Utvecklare vänder sig nästan alltid till Open source-komponenter för att hjälpa dem att bygga sin produkt snabbare och effektivare och lägga till kraftfulla funktioner utan att behöva skriva den nya koden själva.
i de flesta fall är det osannolikt att de kontrollerar om komponenten har några kända sårbarheter innan den läggs till i sin produkt. Även om de utför en snabbkontroll för att se om det har några specifika problem, är det osannolikt att de är medvetna om några problem i komponentens beroenden.,
om de använder ett Programkompositionsanalysverktyg kan de faktiskt få användbar information om huruvida en öppen källkodskomponent har några kända sårbarheter som är förknippade med den under hela mjukvaruutvecklingens livscykel (SDLC), vilket sparar tid som annars kan spenderas riva och ersätta komponenten efter en kontroll från säkerhetsteamet senare nerför linjen innan den släpptes efter att den hade åtagit sig att deras kod.,
Be a Security Enabler Within your Organization
baserat på min läsning av OWASP Top 10 och Knoblochs kommentarer, bör listan tas som ett verktyg för att ge lag möjlighet att inkludera säkerhet i sin tankeprocess om hur de kodar, konfigurerar och skickar ut sina produkter.
säkerhetsteam som inte samarbetar med sina utvecklare, vilket gör ansträngningen att förstå hur de kan ge dem möjlighet att få säkerhet att vara en inneboende del av deras arbetsflöde, kommer snabbt att hitta sig åt sidan.,
om du vill vara relevant, bli en möjliggörare och använd OWASP Top 10-listan som ett sätt att starta konversationer, för att inte hota. I slutändan kan du finna att du fånga mer (O)getingar med honung än vinäger.
den officiella OWASP Top 10 Sårbarhetslistan
A1. Injektion-injektion brister, såsom SQL, NoSQL, OS och LDAP injektion, inträffar när opålitliga data skickas till en tolk som en del av ett kommando eller Fråga. Angriparens fientliga data kan lura tolken att utföra oavsiktliga kommandon eller komma åt data utan korrekt tillstånd.
A2., Brutna autentisering-applikationsfunktioner relaterade till autentisering och sessionshantering implementeras ofta felaktigt, vilket gör det möjligt för angripare att äventyra lösenord, nycklar eller sessionstoken eller att utnyttja andra implementeringsfel för att anta andra användares identiteter tillfälligt eller permanent.
A3. Känslig Dataexponering-många webbapplikationer och API: er skyddar inte känsliga data på rätt sätt, till exempel finansiella, hälso-och sjukvård och PII. Angripare kan stjäla eller ändra sådana svagt skyddade data för att genomföra kreditkortsbedrägerier, identitetsstöld eller andra brott., Känsliga uppgifter kan äventyras utan extra skydd, t.ex. kryptering i vila eller i transit, och kräver särskilda försiktighetsåtgärder när de utbyts med webbläsaren.
A4. XML External Entities ( XXE) – många äldre eller dåligt konfigurerade XML-processorer utvärderar externa entitetsreferenser inom XML-dokument. Externa enheter kan användas för att avslöja interna filer med hjälp av filen Uri-hanteraren, interna filandelar, intern portskanning, fjärrkodkörning och överbelastningsattacker.
A5.,Broken Access Controls-begränsningar för vad autentiserade användare får göra är ofta inte korrekt verkställas. Angripare kan utnyttja dessa brister för att komma åt obehörig funktionalitet och / eller data, komma åt andra användares konton, visa känsliga filer, ändra andra användares data, ändra åtkomsträttigheter etc.
A6. Felkonfiguration av säkerhet-felkonfiguration av säkerhet är det vanligaste problemet., Detta är vanligtvis ett resultat av osäkra standardkonfigurationer, ofullständiga eller Ad hoc-konfigurationer, öppen molnlagring, felaktiga HTTP-rubriker och verbose-felmeddelanden som innehåller känslig information. Inte bara måste alla operativsystem, ramar, bibliotek och applikationer vara säkert konfigurerade, men de måste lappas/uppgraderas i tid.
A7.,Cross Site Scripting (XXS) – XSS brister uppstår när ETT program innehåller opålitlig data i en ny webbsida utan korrekt validering eller flyr, eller uppdaterar en befintlig webbsida med användartillförda data med hjälp av en webbläsare API som kan skapa HTML eller JavaScript. XSS tillåter angripare att köra skript i offrets webbläsare som kan kapa användarsessioner, deface webbplatser, eller omdirigera användaren till skadliga webbplatser.
A8. Osäker deserialisering-osäker deserialisering leder ofta till fjärrkörning av kod., Även om deserialiseringsbrister inte resulterar i fjärrkörning av kod, kan de användas för att utföra attacker, inklusive Replay-attacker, injiceringsattacker och utökning av privilegier.
A9. Använda komponenter med kända sårbarheter-komponenter, till exempel bibliotek, ramar och andra programmoduler, kör med samma privilegier som programmet. Om en sårbar komponent utnyttjas kan en sådan attack underlätta allvarlig dataförlust eller serverövertagande., Applikationer och API: er som använder komponenter med kända sårbarheter kan undergräva applikationsförsvar och möjliggöra olika attacker och effekter.
A10. Otillräcklig loggning & övervakning-otillräcklig loggning och övervakning, i kombination med saknas eller ineffektiv integration med incidentsvar, tillåter angripare att ytterligare attacksystem, upprätthålla uthållighet, pivot till fler system, och manipulera, extrahera eller förstöra data., De flesta brott studier visar tid att upptäcka ett brott är över 200 dagar, vanligtvis upptäcks av externa parter snarare än interna processer eller övervakning.