Wat is de OWASP Top 10 kwetsbaarheden lijst?
De nu beroemde OWASP Top 10 kwetsbaarheden lijst (onderaan het artikel) is waarschijnlijk het dichtst dat de ontwikkelingsgemeenschap ooit is gekomen om een set van geboden over hoe hun producten veilig te houden.,
deze lijst vertegenwoordigt de meest relevante bedreigingen voor softwarebeveiliging vandaag volgens OWASP, voor het voorhoofd-smakken van velen die zich afvragen hoe SQL injecties zijn nog steeds zo ‘ n zorg na al die jaren. Zij beoordelen kwetsbaarheidstypen op basis van vier criteria:
- gemak van exploiteerbaarheid
- prevalenties
- detecteerbaarheid
- bedrijfsimpact
interessant genoeg stelt OWASP dat zij in hun vergelijking geen rekening houden met de waarschijnlijkheid dat aanvallers een bepaalde kwetsbaarheid zullen proberen uit te buiten.,
toen het begon, besloten de schrijvers dat de beste manier om het meest terrein te bestrijken was om soortgelijke kwetsbaarheden die zij het meest zorgwekkend achtten in groepen te plaatsen. Ze erkenden dat het ontbreken van de juiste statistieken er altijd een vraag kan zijn over welke kwetsbaarheden noodzakelijkerwijs de top zorgen waren, vooral omdat dit een subjectieve vragen kan zijn volgens het dreigingsmodel van elke organisatie.
na veel discussie boden zij echter hun lijst aan van wat volgens hen de breedste groep organisaties betrof, zij het niet in een bepaalde volgorde.,
met de tijd werd de OWASP Top 10 kwetsbaarheden lijst aangenomen als een standaard voor best practices en vereisten door tal van organisaties, het instellen van een standaard in een zin voor ontwikkeling. Een bekende adopter van de lijst is de payment processing standards van PCI-DSS.
helaas, omdat de OWASP Top 10 kwetsbaarheden lijst een breder publiek heeft bereikt, zijn de echte bedoelingen als gids verkeerd geïnterpreteerd, waardoor ontwikkelaars worden gekwetst in plaats van te helpen. Dus hoe moeten we het doel van deze lijst begrijpen en ontwikkelaars eigenlijk aanmoedigen om veiliger te coderen?,
updates van de lijst 2017 begrijpen
in de jaren daarna hebben ze de items vernieuwd en opnieuw geordend, waarbij enkele nieuwe kwetsbaarheidstypen werden toegevoegd naarmate ze relevant werden, zelfs toen andere uit de lijst werden geschrapt. Nieuwe versies zijn uitgegeven in 2010, 2013 en 2017. De nieuwe lijst werd samengesteld na een lange en moeizame studie die keek naar meer dan 50.000 toepassingen en geanalyseerd ongeveer 2,3 miljoen kwetsbaarheden.,
regelmatige volgelingen van de lijst zullen gemerkt hebben dat samen met enkele veranderingen in de volgorde — ondanks het feit dat injectie aanvallen blijven op de top — er een aantal nieuwkomers in de 2017 bijgewerkte versie van de OWASP Top 10 kwetsbaarheden familie.
Het verslaan van de concurrentie om inch zijn weg naar het veld door het aftrappen van niet-gevalideerde redirects en forwards is de kwestie van onbeschermde API ‘ s., De opname op de lijst op het nummer A10 plek is waarschijnlijk het gevolg van het feit dat ontwikkelaars zijn gewoon veel meer afhankelijk van API ‘ s dan ze gewend zijn, interactie met veel meer componenten en externe producten dan voorheen. Coming in at the A7 spot is onvoldoende attack protection, die slaat ontwikkelaars voor niet uitgebreid genoeg in het toevoegen van beveiligingen voor het detecteren, loggen, en natuurlijk reageren op pogingen om hun producten te schaden.,
de andere belangrijke verandering hier in de 2017 versie is de combinatie van A4 ‘ s onveilige lijdend voorwerp verwijzingen en A7 ontbrekende functie niveau Toegangscontrole, het creëren van een uniforme gebroken Toegangscontrole kwetsbaarheid en de nadruk op de noodzaak van het goed instellen van controles voor wie wel en niet toegang tot de accounts en gegevens.,
het verkeerd interpreteren van de OWASP Top 10 kwetsbaarheden lijst
een kracht voor het Goede, deze lijst is helaas veranderd in een tool voor het beschamen van ontwikkelaars die niet aan de leringen volgen, gebruikt als een club om hen te berispen omdat ze niet perfect zijn als het gaat om veiligheid. Deze aanpak is contraproductief en mist OWASP ‘ s missie om ontwikkelaars aan te moedigen en uit te rusten om veiliger te coderen. Bovendien, het niet in slaagt om de prestaties van de scores van ontwikkelaars die duwen enorme hoeveelheden nieuwe software op een nooit eerder gezien tarief te herkennen.,in een recent interview uitte OWASP ‘ s voorzitter Martin Knobloch zijn teleurstelling over het feit dat de lijst wordt gebruikt als een soort checklist voor een laatste doorloop voor een release, en meer als een validatiemechanisme dan een gids.
als iemand die sterk gelooft in een shift-left benadering van veiligheid, ben ik het niet verwonderlijk dat ik het overweldigend eens ben met Knobloch ‘ s frustratie over hoeveel mensen de OWASP Top 10 lijst als een instrument van FUD hebben genomen, en niet de set van leidende principes die het bedoeld was te zijn.,
uitdagende industriële benaderingen van beveiliging
organisatorische beveiligingsstrategieën die afhankelijk zijn van het verwachten van falen van de menselijke elementen in hoe ze Software beveiligen ten gunste van glanzende tools zijn gebonden aan falen.
in de afgelopen jaren is het bericht van veel te veel leveranciers, vooral aan de netwerkzijde, dat “de perimeter dood is” en dat bedrijven beveiliging op diepte moeten zoeken om de slechteriken te vinden die al in hun netwerk zitten., Veel te veel krantenkoppen op conferenties hebben geprobeerd om CISOs te overtuigen dat teams van elite hackers schieten voor hen met rarified 0-day exploits die hen weerloos zal verlaten, tenzij ze hun product dat een of andere manier zal ze onneembaar om deze anders niet te stoppen aanvallen te kopen.
Deze kijk op de staat van veiligheid is onnodig fatalistisch, druipt van marketing hype, en mist enkele basisconcepten van hoe beveiligingsprofessionals over risico ‘ s zouden moeten denken.,
een uitgebreide benadering van beveiliging zou niet moeten prediken om de menselijke ontwikkelaars uit het proces te verwijderen, alleen om de beveiligingstools van een leverancier in te voeren om te repareren nadat ze hun werk hebben voltooid. Dit veronderstelt dat de ontwikkelaars niet kunnen worden vertrouwd, is beledigend, en doet niets om uw team sterker te maken als het gaat om veiligheid en risicobeheer.
wat de OWASP Top 10 kwetsbaarheden lijst is en is niet
een paar keer per jaar is er de verplichte blog post vragen hoe het mogelijk is dat in 2017 we nog steeds praten over script kiddie niveau aanvallen., Ik heb er waarschijnlijk zelf een paar geschreven, waarvoor mijn excuses.
de OWASP Top 10 is niet ingesteld om elke aanval in het Boek op te lossen, maar om teams te helpen de veel voorkomende fouten te voorkomen die veel waarschijnlijker zijn dat hun applicaties worden geschonden. Een vastberaden aanvaller kan vele manieren vinden om hun doel te doorbreken. Echter, de smart risk management advisories richten zich niet op de minderheid van de gevallen, maar in plaats daarvan proberen om de problemen aan te pakken waarmee het breedste publiek.,
om uit de concepten van het fysieke beveiligingsveld te putten, zou de gemiddelde risicomanager veel meer bezorgd moeten zijn dat haar cliënt een ongeluk krijgt op de weg dan ninja ‘ s die zijn opgeleid door Seal Team 6 die door de ramen komen, geleid door AI (en blockchain).
echte veiligheid gaat over het opleiden van mensen over hoe veilig te werken en hen de technologieën, kennis en processen te geven om het voor hen gemakkelijker te maken veilig te blijven., Hoewel het altijd belangrijk is om QA en definitieve veiligheidscontroles uit te voeren voor een release, moet de beveiliging beginnen in de vroegste stadia van hoe uw team werkt, gedurende het hele proces van het ontwikkelen van het product. Fouten zullen gebeuren, maar het is veel kosteneffectiever en ronduit slimmer om te proberen zoveel mogelijk problemen te vermijden in de eerste plaats.
voor veel ontwikkelaars draait het doel om het product aan het werk te krijgen, waarbij minder wordt gekeken of het veilig is of niet. Dit is niet hun schuld.,
gedurende hun opleiding leerden ze dat als ze een product produceren met een minimale hoeveelheid bugs, dan kregen ze een A. beveiliging zou sowieso door een andere afdeling worden afgehandeld. In plaats daarvan, managers nodig hebben om de gelegenheid te nemen om hen te laten zien een betere manier om te werken dat omvat overwegen hoe ze code, en de componenten die ze werken met, invloed hebben op de veiligheid van hun product.,
haal 451 onderzoeksrapport over het beveiligen van OPEN SOURCE SOFTWARE Download Free
praktische stappen om betere beveiligingspraktijken mogelijk te maken
een veel voorkomende valkuil die uit de dagen van de ontwikkeling van Waterval kwam, was om te wachten tot het einde van de ontwikkelingscyclus om beveiligingscontroles uit te voeren, waarbij de ontwikkelaars een waslijst van kwetsbaarheden zouden ontvangen om op te lossen, waardoor de release werd vertraagd en de wrijving tussen hen en het beveiligingsteam toenam.,
in de hoop de versnellingen in te vetten en gelijke tred te houden met de snelheid van DevOps, zijn organisaties op zoek naar nieuwe manieren om hun code vanaf het begin te beveiligen en de harmonie tussen hun afdelingen te behouden.
een steeds populairder methode om beveiliging in de eerdere stadia van productontwikkeling te brengen is het kruisbestuiven van teams met een mix van ontwikkelaars en beveiligers, waardoor elke kant input kan geven en van elkaar kan leren., Dit kan een uitstekende gelegenheid zijn voor security experts om veel van de problemen die de OWASP Top 10 probeert aan te pakken in een minder confronterende omgeving, in een fase die daadwerkelijk een impact zou kunnen hebben.
als het gaat om tools die kunnen helpen bij het bevorderen van een betere implementatie van beveiliging, moeten we niet alleen nadenken over hoe technologie onze fouten of inbreuken achteraf kan opvangen, maar ons ook helpen slimmer en veiliger te werken vanaf de vroegste stadia., Dit perspectief is een essentieel onderdeel van de shift-left mentaliteit, op zoek naar mogelijkheden om problemen aan te pakken voordat ze dure problemen worden.
technologieën integreren om ontwikkelaars meer mogelijkheden te bieden
een duidelijk voorbeeld van hoe technologieën voor links verschuiven ontwikkelaars kan helpen om de OWASP Top 10 te gebruiken wordt geleverd met het nummer 9 item dat waarschuwt voor het gebruik van componenten met bekende kwetsbaarheden. Een van de meest voorkomende problemen die zich voordoen in deze ruimte is het verkrijgen van inzicht over wat er in de open source componenten die ze hebben toegevoegd aan hun product.,
ontwikkelaars wenden zich bijna altijd tot open source-componenten om hen te helpen hun product sneller en efficiënter te bouwen, door krachtige functies toe te voegen zonder de nieuwe code zelf te hoeven schrijven.
in de meeste gevallen is het onwaarschijnlijk dat ze controleren of het onderdeel bekende kwetsbaarheden heeft voordat ze het aan hun product toevoegen. Zelfs als ze een vluchtige controle uitvoeren om te zien of het specifieke problemen heeft, zijn ze waarschijnlijk niet op de hoogte van problemen in de afhankelijkheden van de component.,
echter, als ze een software Composition Analysis tool gebruiken, kunnen ze daadwerkelijk nuttige informatie ontvangen over de vraag of een open source component bekende kwetsbaarheden heeft in verband met het gedurende de software development lifecycle (SDLC), waardoor ze tijd besparen die anders zou kunnen worden besteed aan het scheuren en vervangen van het onderdeel na een controle van het beveiligingsteam later op de regel voordat het werd gecommit aan hun code.,
be A Security Enabler Within Your Organization
Op basis van mijn lezing van de OWASP Top 10 en de opmerkingen van Knobloch, zou de lijst moeten worden genomen als een hulpmiddel om teams in staat te stellen om veiligheid te betrekken in hun denkproces over hoe ze coderen, configureren en verzenden van hun producten.
beveiligingsteams die geen contact hebben met hun ontwikkelaars en proberen te begrijpen hoe ze hen in staat kunnen stellen om beveiliging een inherent element van hun workflow te laten zijn, zullen snel buitenspel worden gezet.,
als je relevant wilt blijven, word dan een enabler, en gebruik de OWASP Top 10 lijst als een manier om gesprekken te starten, niet om te bedreigen. Uiteindelijk zul je merken dat je meer (O)wespen vangt met honing dan met azijn.
de officiële OWASP Top 10 kwetsbaarheden lijst
A1. Injectie – injectiefouten, zoals SQL, NoSQL, OS en LDAP-injectie, treden op wanneer niet-vertrouwde gegevens naar een interpreter worden verzonden als onderdeel van een opdracht of query. Vijandige gegevens van de aanvaller kan de interpreter te verleiden tot het uitvoeren van onbedoelde commando ‘ s of toegang tot gegevens zonder de juiste toestemming.
A2., Gebroken authenticatie-toepassingsfuncties met betrekking tot authenticatie en sessiebeheer worden vaak verkeerd geïmplementeerd, waardoor aanvallers wachtwoorden, sleutels of sessietokens in gevaar kunnen brengen of andere implementatiefouten kunnen uitbuiten om de identiteit van andere gebruikers tijdelijk of permanent aan te nemen.
A3. Blootstelling aan gevoelige gegevens-veel webapplicaties en API ‘ s beschermen gevoelige gegevens niet goed, zoals financiële, gezondheidszorg en PII. Aanvallers kunnen dergelijke zwak beveiligde gegevens stelen of wijzigen om creditcardfraude, identiteitsdiefstal of andere misdrijven uit te voeren., Gevoelige gegevens kunnen worden aangetast zonder extra bescherming, zoals versleuteling in rust of tijdens het transport, en vereist speciale voorzorgsmaatregelen bij uitwisseling met de browser.
A4. XML External Entities (XXE) – veel oudere of slecht geconfigureerde XML-processors evalueren externe entiteitverwijzingen binnen XML-documenten. Externe entiteiten kunnen worden gebruikt om interne bestanden bekend te maken met behulp van de bestandsurihandler, interne bestandsshares, interne poort scannen, uitvoering van externe code en denial of service-aanvallen.
A5.,Verbroken toegangscontroles-beperkingen op wat geauthenticeerde gebruikers mogen doen, worden vaak niet goed afgedwongen. Aanvallers kunnen deze gebreken benutten om toegang te krijgen tot ongeautoriseerde functionaliteit en / of gegevens, toegang tot accounts van andere gebruikers, gevoelige bestanden bekijken, gegevens van andere gebruikers wijzigen, toegangsrechten wijzigen, enz.
A6. Beveiliging Misconfiguratie-beveiliging misconfiguratie is het meest voorkomende probleem., Dit is meestal een gevolg van onveilige standaardconfiguraties, onvolledige of ad-hocconfiguraties, open cloudopslag, verkeerd geconfigureerde HTTP-headers en uitgebreide foutmeldingen met gevoelige informatie. Niet alleen moeten alle besturingssystemen, frameworks, bibliotheken en applicaties veilig zijn geconfigureerd, maar ze moeten ook tijdig worden gepatcht/bijgewerkt.
A7.,Cross Site Scripting (XXS)-XSS gebreken optreden wanneer een toepassing bevat niet-vertrouwde gegevens in een nieuwe webpagina zonder de juiste validatie of ontsnappen, of updates van een bestaande webpagina met door de gebruiker geleverde gegevens met behulp van een browser API die HTML of JavaScript kan maken. XSS stelt aanvallers in staat om scripts uit te voeren in de browser van het slachtoffer die gebruiker sessies kan kapen, websites beschadigen, of de gebruiker omleiden naar kwaadaardige sites.
A8. Onveilige deserialisatie-onveilige deserialisatie leidt vaak tot uitvoering van externe code., Zelfs als deserialisatiefouten niet leiden tot uitvoering van externe code, kunnen ze worden gebruikt om aanvallen uit te voeren, waaronder replay-aanvallen, injectie-aanvallen en privilege-escalatie-aanvallen.
A9. Met behulp van componenten met bekende kwetsbaarheden-componenten, zoals bibliotheken, frameworks en andere softwaremodules, worden uitgevoerd met dezelfde rechten als de toepassing. Als een kwetsbare component wordt uitgebuit, kan een dergelijke aanval ernstige gegevensverlies of overname van de server vergemakkelijken., Toepassingen en API ‘ s die componenten met bekende kwetsbaarheden gebruiken, kunnen applicatieverdediging ondermijnen en verschillende aanvallen en effecten mogelijk maken.
A10. Onvoldoende Logging & Monitoring – onvoldoende logging en monitoring, in combinatie met ontbrekende of ineffectieve integratie met incident response, stelt aanvallers in staat om systemen verder aan te vallen, persistentie te behouden, naar meer systemen te draaien, en data te saboteren, extraheren of vernietigen., De meeste inbreukstudies tonen aan dat de tijd om een inbreuk te detecteren meer dan 200 dagen is, meestal gedetecteerd door externe partijen in plaats van interne processen of monitoring.