Hvad er OWASP Top 10 Sårbarheder liste?
Først blev udgivet i 2004 af Open Web Application Security Project, den nu berømte OWASP Top-10 Sårbarheder liste (inkluderet i bunden af artiklen) er sandsynligvis det nærmeste, at den udvikling samfundet har nogensinde kommer til et sæt af bud på hvordan at holde deres produkter sikker.,
Denne liste repræsenterer de mest relevante trusler mod software-sikkerhed i dag i henhold til OWASP, at panden-afklapsning af mange, der spekulerer på, hvordan SQL-injektioner er stadig sådan en bekymring efter alle disse år. De vurderer, at sårbarhed typer, der er baseret på fire kriterier punkter:
- nem exploitability
- prævalenserne
- sporbarhed
- business impact
det er Interessant nok, OWASP stater, at de faktisk ikke faktor i deres ligning sandsynligheden for, at hackere vil forsøge at udnytte en vis sårbarhed.,
da det begyndte, besluttede forfatterne, at den bedste måde at dække mest jorden på var at sætte lignende sårbarheder, som de troede var mest om i grupperinger. De erkendte, at de mangler den rette statistikker der kan altid være et spørgsmål over, hvilke sårbarheder, nødvendigvis toppen bekymringer, især da dette kan være et subjektivt spørgsmål, som pr den enkelte organisations trussel model.
men efter megen debat tilbød de deres liste over, hvad de troede at adressere det bredeste sæt organisationer, omend ikke i nogen særlig rækkefølge.,
Med tiden blev O .asp Top 10-Sårbarhedslisten vedtaget som en standard for bedste praksis og krav af adskillige organisationer, der satte en standard på en måde for udvikling. En velkendt adopter af listen er betalingsbehandlingsstandarderne for PCI-DSS.Da O .asp Top 10-Sårbarhedslisten desværre har nået et bredere publikum, er dens virkelige intentioner som vejledning blevet fortolket forkert, hvilket skader udviklere i stedet for at hjælpe. Så hvordan skal vi forstå formålet med denne liste og faktisk opfordre udviklere til at kode mere sikkert?,
forståelse af opdateringer til 2017-listen
i årene siden har de Opdateret og ombestilt posterne og tilføjet nogle nye sårbarhedstyper, når de bliver relevante, selvom andre blev droppet fra listen. Nye versioner er blevet udgivet i 2010, 2013 og 2017. Den nye liste blev samlet efter en lang og besværlig undersøgelse, der kiggede på mere end 50.000 applikationer og analyserede nogle 2,3 millioner sårbarheder.,
Regelmæssige tilhængere af listen, vil have bemærket, at der sammen med nogle ændringer i den rækkefølge, der — på trods af det faktum, at injektion angreb er fortsat på toppen — der er nogle tilflyttere til 2017 opdateret version af OWASP Top-10 Sårbarheder familie.
at slå konkurrencen ud for at tommer sin vej på banen ved at sparke uvalgte omdirigeringer og fremad er spørgsmålet om ubeskyttede API ‘ er., Dens optagelse på listen på nummer A10 stedet er sandsynligvis resultatet af det faktum, at udviklere er simpelthen langt mere afhængige af API ‘ er, end de plejede at, interagere med langt flere komponenter og eksterne produkter end før. At komme ind på A7-stedet er utilstrækkelig angrebsbeskyttelse, som banker udviklere for ikke at være omfattende nok til at tilføje beskyttelse til at opdage, logge og selvfølgelig reagere på forsøg på at skade deres produkter.,
Den anden store ændring her i 2017 version er en kombination af A4 ‘ s usikker direkte objekt referencer og A7 manglende funktion niveau adgangskontrol, at skabe en samlet brudt adgangskontrol sårbarhed og fremhævelse af nødvendigheden af korrekt oprettelse af kontrol for, hvem der kan og ikke kan få adgang til konti og data.,
Fejlfortolke OWASP Top 10 Sårbarheder List
En kraft for det gode, denne liste har desværre forvandlet til et redskab for at hænge nogen ud-udviklere, der undlader at følge dens lærdomme, der anvendes som en klub at skælde dem ud for ikke at være perfekt, når det kommer til sikkerhed. Denne tilgang er kontraproduktiv og savner O .asps mission om at opmuntre og udstyre udviklere til at kode mere sikkert. Desuden, det undlader at anerkende resultaterne af snesevis af udviklere, der skubber ud massive mængder af ny soft .are på en aldrig før set Sats.,
i et nyligt intervie.udtrykte o .asps formand Martin Knobloch sin skuffelse over, at listen blev brugt som en slags tjekliste til en endelig gennemgang før en udgivelse, der tjener mere som en valideringsmekanisme end en vejledning.
Som en person, der tror fuldt og fast på en shift-venstre tilgang til sikkerhed, jeg er ikke overraskende i overvældende aftale med Knobloch ‘ s frustration over, hvor mange har taget OWASP Top-10 liste, som et instrument af FUD, og ikke de vejledende principper, som det var tiltænkt.,
udfordrende Branchetilgange til sikkerhed
organisatoriske sikkerhedsstrategier, der afhænger af at forvente fiasko fra de menneskelige elementer i, hvordan de sikrer soft .are til fordel for skinnende værktøjer, vil helt sikkert mislykkes.
I de seneste år beskeder fra alt for mange leverandører, især i netværket side, har været, at “omkredsen er død” og at virksomhederne er nødt til at søge sikkerhed i dybden for at finde de slemme fyre, der allerede er inde i deres netværk., Alt for mange overskrifter på konferencer er forsøgt at overbevise CISOs at hold af elite hackere er gunning for dem med fortyndet 0-day exploits, der vil forlade dem forsvarsløse, medmindre de køber deres produkt, som på en eller anden måde vil gøre dem uovervindelige at disse ellers ustoppelige angreb.
dette syn på sikkerhedstilstanden er unødigt fatalistisk, drypper af marketinghype og savner nogle af de grundlæggende begreber om, hvordan sikkerhedspersonale skal tænke på risiko.,
en omfattende tilgang til sikkerhed bør ikke prædike at fjerne de menneskelige udviklere fra processen, bare for at bringe en leverandørs sikkerhedsværktøjer til rette, når de er færdige med deres arbejde. Dette forudsætter, at udviklerne ikke kan stole på, er fornærmende og ikke gør noget for at gøre dit team stærkere, når det kommer til sikkerhed og risikostyring.
Hvad OWASP Top 10 Sårbarheder Liste Er Ikke
Et par gange om året, der er obligatorisk blog-indlæg spørger, hvordan det er muligt, at der i 2017, og vi taler stadig om script kiddie niveau angreb., Jeg har sandsynligvis skrevet et par af dem selv, som jeg undskylder.o .asp Top 10 er ikke sat op til at løse ethvert angreb i bogen, men for at hjælpe hold med at undgå de almindelige fejl, der er langt mere tilbøjelige til at få deres applikationer overtrådt. En bestemt angriber kan finde mange muligheder for at bryde deres mål. Smart risk management advisories fokuserer dog ikke på mindretallet af sager, men søger i stedet at tackle de problemer, som det bredeste publikum står overfor.,
for at trække fra begreberne fysisk sikkerhedsfelt, bør den gennemsnitlige risikostyring være langt mere bekymret for, at hendes klient kommer i en ulykke på vejen end ninjaer trænet af SEAL Team 6, der kommer gennem vinduerne, styret af AI (og blockchain). reel sikkerhed handler om at træne folk i at arbejde sikkert og give dem teknologier, viden og processer for at gøre det lettere for dem at forblive sikre., Mens det altid er vigtigt at køre QA og endelige sikkerhedskontrol før en udgivelse, sikkerhed skal starte på de tidligste stadier af, hvordan dit team fungerer, kører hele processen med at udvikle produktet. Fejl vil ske, men det er langt mere omkostningseffektivt og ligefrem smartere at forsøge at undgå så mange problemer som muligt i første omgang.
for mange udviklere er det drivende mål centreret omkring at få produktet til at fungere og fokusere mindre på, om det er sikkert eller ej. Dette er ikke deres skyld.,
under hele deres uddannelse lærte de, at hvis de producerer et produkt med en minimal mængde fejl, så fik de en A. sikkerhed ville blive håndteret af en anden afdeling alligevel. I stedet skal ledere benytte lejligheden til at vise dem en bedre måde at arbejde på, der inkluderer at overveje, hvordan de koder, og de komponenter, de arbejder med, påvirker sikkerheden for deres produkt.,
FÅ 451 FORSKNING ER REPORTON SIKRING af OPEN SOURCE SOFTWARE Download Gratis
Praktiske Skridt til At Muliggøre en Bedre Sikkerhed Praksis
det er En almindelig faldgrube, der kom ud af de dage af vandfald udvikling var at vente, indtil enden af udviklingsprocessen, til at udføre sikkerhedstjek, hvor udviklere vil modtage et vaskeri liste af sårbarheder til at fastsætte, at forsinke frigivelsen og øge friktionen mellem dem og den sikkerhed team.,
i håb om at smøre gearene og holde trit med DevOps hastighed søger organisationer nye måder at sikre deres kode fra starten og opretholde harmoni mellem deres afdelinger.en stadig mere populær metode til at bringe sikkerhed ind i de tidligere stadier af produktudvikling er i krydsbestøvende teams med en blanding af udviklere og sikkerhedsfolk, så hver side kan give input og lære af hinanden., Dette kan være en glimrende mulighed for sikkerhedseksperter til at bringe op mange af de spørgsmål, som O .asp Top 10 forsøger at løse i en mindre konfronterende miljø, på et tidspunkt, der rent faktisk kunne have en indvirkning.
Når det kommer til værktøjer, der kan hjælpe med at fremme bedre sikkerhedsimplementering, er vi nødt til at tænke ikke kun på, hvordan teknologi kan fange vores fejl eller brud efter faktum, men hjælpe os med at arbejde smartere og mere sikkert fra de tidligste stadier., Dette perspektiv er en del af skift-venstre mentalitet, på udkig efter muligheder for at løse problemer, før de bliver dyre problemer.
Integrere Teknologier til At Forøge Udvikler Evner
Et klart eksempel på, hvordan teknologier til at flytte til venstre kan hjælpe udviklere med at udnytte OWASP Top-10 leveres med 9 indlæg som advarer mod at bruge komponenter med kendte sårbarheder. Et af de mest almindelige problemer, der opstår i dette rum, er at få synlighed over, hvad der er i open source-komponenterne, som de har føjet til deres produkt.,
udviklere henvender sig næsten altid til open source-komponenter for at hjælpe dem med at opbygge deres produkt hurtigere og mere effektivt og tilføje kraftfulde funktioner uden at skulle skrive den nye kode selv.
i de fleste tilfælde er det usandsynligt, at de kontrollerer, om komponenten har kendte sårbarheder, før de føjes til deres produkt. Selvom de udfører en kortvarig kontrol for at se, om det har specifikke problemer, er det usandsynligt, at de er opmærksomme på problemer i komponentens afhængigheder.,
Men hvis de bruger en Software, Sammensætning, Analyse-redskab, de kan faktisk modtage nyttige oplysninger om, hvorvidt en open source komponent har nogen kendte sårbarheder, der er forbundet med det hele software development lifecycle (SDLC), hvilket sparer dem tid, som ellers kunne være brugt til at rive og erstatte den komponent, efter at en check fra den sikkerhed team senere ned på linjen før udgivelse, efter at den var forpligtet til deres kode.,
Være En Sikkerhed Katalysator I Din Organisation
Baseret på min læsning af OWASP Top-10 og Knobloch kommentarer, listen skal tages som et redskab til styrkelse af teams til at omfatte sikkerhed i deres tankeproces af, hvordan de kode, skal du konfigurere, og skibet ud af deres produkter.sikkerhedsteams, der ikke samarbejder med deres udviklere og gør en indsats for at forstå, hvordan de kan give dem mulighed for at få sikkerhed til at være et iboende element i deres arbejdsgang, vil hurtigt finde sig sidelined.,
Hvis du vil forblive relevant, skal du blive en enabler og bruge O .asp Top 10-listen som en måde at starte samtaler på, for ikke at true. I sidste ende kan du opleve, at du fanger flere (O)hveps med honning end eddike.
den officielle O .asp Top 10 sårbarheder liste
A1. Injektion-Injektionsfejl, såsom s .l, nos .l, OS og LDAP-injektion, opstår, når data, der ikke er tillid til, sendes til en tolk som en del af en kommando eller forespørgsel. Angriberens fjendtlige data kan narre tolken til at udføre utilsigtede kommandoer eller få adgang til data uden ordentlig tilladelse.A2., Broken Authentication-applikationsfunktioner relateret til godkendelse og sessionsstyring implementeres ofte forkert, så angribere kan kompromittere adgangskoder, nøgler eller sessionstokens eller udnytte andre implementeringsfejl til at påtage sig andre brugers identiteter midlertidigt eller permanent.
A3. Eksponering for følsomme Data-mange applicationsebapplikationer og API ‘ er beskytter ikke følsomme data korrekt, såsom finansielle, sundhedsydelser og PII. Angribere kan stjæle eller ændre sådanne svagt beskyttede data for at udføre kreditkortsvindel, identitetstyveri eller andre forbrydelser., Følsomme data kan blive kompromitteret uden ekstra beskyttelse, såsom kryptering i hvile eller i transit, og det kræver særlige forholdsregler, når de udveksles med browseren.
A4. Externalml eksterne enheder (External .e) – mange ældre eller dårligt konfigurerede .ml-processorer evaluerer eksterne enhedsreferencer i .ml-dokumenter. Eksterne enheder kan bruges til at afsløre interne filer ved hjælp af filen URI handler, interne fil aktier, intern port scanning, fjernkørsel af programkode, og Denial of service-angreb.A5.,Ødelagte adgangskontroller-begrænsninger for, hvad autentificerede brugere har lov til at gøre, håndhæves ofte ikke korrekt. Angribere kan udnytte disse fejl for at få adgang til uautoriseret funktionalitet og / eller data, få adgang til andre brugeres konti, se følsomme filer, ændre andre brugers data, ændre adgangsrettigheder osv.
A6. Security Misconfiguration-sikkerhed fejlkonfiguration er den mest almindeligt set problem., Dette er ofte et resultat af usikre standardkonfigurationer, ufuldstændige eller ad hoc-konfigurationer, åben skyopbevaring, fejlkonfigurerede HTTP-overskrifter og verbose fejlmeddelelser, der indeholder følsomme oplysninger. Ikke kun skal alle operativsystemer, rammer, biblioteker og applikationer konfigureres sikkert, men de skal patches/opgraderes rettidigt.
A7.,Cross Site Scripting (XXS) – XSS-fejl opstår, når en ansøgning omfatter ikke er tillid til data i en ny web-side uden ordentlig validering eller undslippe, eller opdaterer en eksisterende web-side med brugerleverede data ved hjælp af en browser API, der kan oprette HTML eller JavaScript. XSS gør det muligt for angribere at udføre scripts i ofrets bro .ser, som kan kapre bruger sessioner, skamfere webebsteder, eller omdirigere brugeren til ondsindede .ebsteder.
A8. Usikker deserialisering-usikker deserialisering fører ofte til fjernkørsel af programkode., Selv hvis deserialisering fejl ikke resultere i fjernkørsel af programkode, de kan bruges til at udføre angreb, herunder replay angreb, injektion angreb, og rettighedsforøgelse angreb.
A9. Brug af komponenter med kendte sårbarheder – komponenter, såsom biblioteker, rammer og andre soft .aremoduler, kører med de samme privilegier som applikationen. Hvis en sårbar komponent udnyttes, kan et sådant angreb lette alvorligt datatab eller serverovertagelse., Applikationer og API ‘ er, der bruger komponenter med kendte sårbarheder, kan undergrave applikationsforsvar og muliggøre forskellige angreb og påvirkninger.
A10. Utilstrækkelig logning &