{"id":7383,"date":"2021-10-13T14:06:33","date_gmt":"2021-10-13T12:06:33","guid":{"rendered":"https:\/\/jimber.io\/de-owasp-top-tien-2021\/"},"modified":"2025-09-12T15:53:30","modified_gmt":"2025-09-12T13:53:30","slug":"de-owasp-top-tien-2021","status":"publish","type":"post","link":"https:\/\/jimber.io\/nl\/blog\/de-owasp-top-tien-2021\/","title":{"rendered":"De OWASP top tien 2021"},"content":{"rendered":"
Wat is OWASP?<\/h2>\n
OWASP (Open Web Application Security Project) is een non-profit organisatie die zich richt op het verbeteren van de beveiliging van websites. Ze bieden open-source softwareontwikkelingsprogramma’s, projecten, toolkits, lokale afdelingen, conferenties, artikelen, video’s, forums, methodologie\u00ebn, documentatie en technologie\u00ebn aan hun gemeenschap. Ze bieden al deze tools en kennis gratis en gemakkelijk toegankelijk voor iedereen die ge\u00efnteresseerd is in de beveiliging van websites. Een van hun belangrijkste projecten is de OWASP top tien. Voor OWASP waren er niet veel tools of kennis beschikbaar over cyberbeveiliging. Met OWASP begon de gemeenschap te leren hoe ze hun code konden beschermen tegen kwetsbaarheden, softwareversleuteling konden versterken en het aantal bugs in hun code konden verminderen. <\/p>\n\n
<\/div>\n<\/figure>\n
Wat is OWASP top tien?<\/h2>\n
De OWASP top tien is een document waarin de top tien van meest kritieke veiligheidslekken op websites wordt weergegeven. Het toont de risico’s, gevolgen en tegenmaatregelen. Deze lijst is opgesteld door websitebeveiligingsdeskundigen van over de hele wereld. De kwetsbaarheden worden gerangschikt op basis van de ernst van de kwetsbaarheden, de frequentie van de ontdekte beveiligingsrisico’s en de omvang van de potenti\u00eble impact. OWASP raadt alle bedrijven aan om de bevindingen van het rapport en de aanbevelingen van OWASP op te nemen in hun beveiligingsprocessen voor websites om de beveiligingsrisico’s te minimaliseren. De OWASP top tien wordt elke drie tot vier jaar bijgewerkt. De laatste OWASP top tien werd uitgebracht in 2017, ze hebben onlangs ook een concept van de OWASP top tien 2021 uitgebracht. Sinds de laatste OWASP top tien is er het een en ander veranderd. Er zijn drie nieuwe categorie\u00ebn. Vier categorie\u00ebn veranderden van naam of scoping en sommige zijn nu gecombineerd.De OWASP top tien 2021 kwetsbaarheden zijn: <\/p>\n
\n
Gebroken toegangscontrole<\/strong><\/li>\n
Cryptografische storingen<\/strong> (vroeger: blootstelling aan gevoelige gegevens)<\/li>\n
Injectie<\/strong><\/li>\n
Onveilig ontwerp<\/strong> (Nieuw)<\/li>\n
Verkeerde configuratie van beveiliging<\/strong><\/li>\n
Kwetsbare en verouderde componenten<\/strong> (was vroeger: componenten gebruiken met bekende kwetsbaarheden)<\/li>\n
Fouten bij identificatie en authenticatie<\/strong> (was vroeger: Gebroken authenticatie)<\/li>\n
Fouten in software en gegevensintegriteit<\/strong> (nieuw) <\/li>\n
Beveiligingslogboek en bewakingsfouten<\/strong> (was vroeger: Onvoldoende logboekregistratie en bewaking)<\/li>\n
Elke kwetsbaarheid wordt uitgelegd met een voorbeeld en OWASP-aanbevelingen.<\/p>\n\n
<\/div>\n<\/figure>\n
De top tien van OWASP-kwetsbaarheden voor 2021<\/h2>\n
Cryptografische fouten<\/h3>\n
Wat is het?<\/h4>\n
Cryptografische mislukkingen zijn gecompromitteerde gegevens die beschermd hadden moeten worden. Dit is vooral een probleem met gegevens die onder de privacywetgeving vallen. <\/p>\n
Voorbeelden:<\/h4>\n
\n
Wachtwoorden<\/li>\n
Creditcardnummers<\/li>\n
Medische informatie<\/li>\n
Geloofsbrieven<\/li>\n
Burgerservicenummers<\/li>\n
Persoonlijk identificeerbare informatie<\/li>\n
Andere persoonlijke informatie<\/li>\n
Bedrijfsgeheimen<\/li>\n<\/ul>\n
OWASP-aanbevelingen:<\/h4>\n
\n
Classificeer gegevens die worden gebruikt door een applicatie en identificeer welke gegevens gevoelig zijn.<\/li>\n
Sla gevoelige gegevens niet onnodig op.<\/li>\n
Versleutel alle gevoelige gegevens in rust. Versleutel alle gegevens onderweg met veilige protocollen. Gebruik geverifieerde versleuteling. <\/li>\n
Gebruik goed sleutelbeheer. Genereer cryptografisch willekeurige sleutels en sla ze op in het geheugen als byte-arrays. <\/li>\n
Schakel caching uit voor reacties die gevoelige gegevens bevatten.<\/li>\n
Vereiste beveiligingscontroles toepassen volgens gegevensclassificatie.<\/li>\n
Gebruik geen oude protocollen zoals FTP en SMTP voor gevoelige gegevens.<\/li>\n
Gebruik sterke adaptieve en salted hashingfuncties met een werkfactor om wachtwoorden op te slaan.<\/li>\n
Kies initialisatievectoren voor de juiste werkingsmodus.<\/li>\n
Gebruik waar nodig cryptografische willekeurigheid op een niet-voorspelbare manier met lage entropie.<\/li>\n
Vermijd verouderde cryptografische functies en opvulschema’s.<\/li>\n
Controleer onafhankelijk de effectiviteit van de configuratie en instellingen.<\/li>\n<\/ul>\n\n
<\/div>\n<\/figure>\n
Injectie<\/h3>\n
Wat is het?<\/h4>\n
Deze kwetsbaarheid treedt op wanneer een webapplicatie ongeldige gegevens ontvangt van een hacker om het iets te laten doen waarvoor het niet is geprogrammeerd. <\/p>\n
Voorbeeld:<\/h4>\n
SQL-injectie is een van de meest voorkomende injectiefouten. SQL-injectie wordt veroorzaakt door het gebruik van niet-vertrouwde gegevens bij de constructie van een kwetsbare SQL-aanroep. Het gebrek aan validatie en opschoning van de gegevens die door webapplicaties worden gebruikt, maakt de gegevens niet-vertrouwd. Dit betekent ook dat de kwetsbaarheid voor code-injectie aanwezig kan zijn op bijna elk type technologie met betrekking tot websites. <\/p>\n
OWASP-aanbevelingen:<\/h4>\n
\n
Houd gegevens gescheiden van commando’s en query’s. <\/li>\n
Het gebruik van een veilige API verdient de voorkeur. <\/li>\n
Gebruik positieve of “whitelist” server-side invoervalidatie.<\/li>\n
\t<\/li>\n
Escape speciale tekens met een specifieke escape syntaxis.<\/li>\n
\t<\/li>\n
LIMIT en andere SQL-besturingselementen binnen query’s gebruiken.<\/li>\n<\/ul>\n\n
<\/div>\n<\/figure>\n
Onveilig ontwerp (Nieuw)<\/h3>\n
Wat is het?<\/h4>\n
Een onveilig ontwerp betekent een controleontwerp dat ontbreekt of niet effectief is. Onveilig ontwerp en onveilige implementatie zijn niet hetzelfde. Ze hebben verschillende oorzaken en oplossingen. <\/p>\n
Voorbeeld:<\/h4>\n
Het falen om te bepalen welk niveau van beveiligingsontwerp nodig is.<\/p>\n
OWASP-aanbevelingen:<\/h4>\n
\n
Vereisten- en middelenbeheer, veilig ontwerp en een veilige ontwikkelingslevenscyclus implementeren.<\/li>\n
Een veilige ontwikkelingslevenscyclus implementeren om privacy- en beveiligingscontroles te helpen instellen. <\/li>\n
Gebruik een bibliotheek met veilige ontwerppatronen of kant-en-klare componenten.<\/li>\n
\t<\/li>\n
Gebruik bedreigingsmodellering voor kritieke authenticatie, bedrijfslogica, toegangscontrole en sleutelstromen.<\/li>\n
\t<\/li>\n
Beveiligingstaal en -controles integreren in gebruikersverhalen. <\/li>\n
\t<\/li>\n
Integreer plausibiliteitscontroles op elk niveau van je applicatie. <\/li>\n
\t<\/li>\n
Schrijf unit- en integratietests om te valideren dat alle kritieke flows bestand zijn tegen het bedreigingsmodel. Maak use-cases en misuse-cases. <\/li>\n
\t<\/li>\n
Segregeer lagen op de systeem- en netwerklaag. Segregeer huurders robuust door het ontwerp in alle lagen. <\/li>\n
\t<\/li>\n
Verbruik van bronnen beperken per gebruiker of dienst.<\/li>\n<\/ul>\n
Verkeerde configuratie van beveiliging<\/h3>\n
Wat is het?<\/h4>\n
De zwakke plek in de beveiligingsconfiguratie treedt op wanneer een applicatie geen geco\u00f6rdineerd, herhaalbaar configuratieproces voor applicatiebeveiliging heeft. Het kan worden aangevallen door zoveel mogelijk combinaties te proberen. <\/p>\n
Voorbeeld:<\/h4>\n
Een van de meest voorkomende fouten bij de beveiliging van websites is het aanhouden van de standaardconfiguraties van het CMS.<\/p>\n
Zet een andere omgeving in die goed vergrendeld is.<\/li>\n
\t<\/li>\n
Verwijder ongebruikte frameworks en functies. <\/li>\n
\t<\/li>\n
Controleer en werk de configuraties bij voor alle updates, beveiligingsmeldingen en patches. <\/li>\n
\t<\/li>\n
Controleer de machtigingen voor cloudopslag.<\/li>\n
\t<\/li>\n
Implementeer een gesegmenteerde applicatiearchitectuur, met containerisatie, segmentatie of cloudbeveiligingsgroepen.<\/li>\n
\t<\/li>\n
Stuur beveiligingsrichtlijnen naar klanten.<\/li>\n
\t<\/li>\n
Implementeer een geautomatiseerd proces om de effectiviteit van de instellingen en configuraties in alle omgevingen te controleren.<\/li>\n<\/ul>\n\n
<\/div>\n<\/figure>\n
Kwetsbare en verouderde onderdelen<\/h3>\n
Wat is het?<\/h4>\n
Tegenwoordig hebben zelfs eenvoudige websites veel kwetsbaarheden. Als je niet elk stukje software van een website bijwerkt, introduceer je vroeg of laat beveiligingsrisico’s voor je website. <\/p>\n
OWASP-aanbevelingen:<\/h4>\n
\n
Implementeer een patchbeheerproces:<\/li>\n
Verwijder ongebruikte afhankelijkheden. <\/li>\n
Maak een inventarisatie van zowel server-side als client-side componenten en hun afhankelijkheden. <\/li>\n
\t<\/li>\n
Controleer algemene bronnen over kwetsbaarheden. <\/li>\n
\t<\/li>\n
Koop alleen onderdelen van offici\u00eble bronnen. <\/li>\n
\t<\/li>\n
Controleer op componenten en bibliotheken die niet worden onderhouden of die geen beveiligingspatches maken voor oudere versies.<\/li>\n
Zorg voor een doorlopend plan voor triaging, monitoring en het toepassen van configuratiewijzigingen of updates gedurende de levensduur van de applicatie.<\/li>\n<\/ul>\n
Fouten bij identificatie en verificatie<\/h3>\n
Wat is het?<\/h4>\n
Een zwakke authenticatie kan worden aangevallen met automatische of handmatige methoden. Op deze manier kan een aanvaller de controle krijgen over elk account dat hij wil of zelfs over het hele systeem. <\/p>\n
Voorbeelden:<\/h4>\n
\n
Onjuiste validatie van certificaat met host mismatch<\/li>\n
Onjuiste verificatie<\/li>\n
Sessie fixatie<\/li>\n<\/ul>\n
OWASP-aanbevelingen:<\/h4>\n
\n
Implementeer waar mogelijk multi-factor authenticatie.<\/li>\n
Implementeer of lever geen standaard referenties.<\/li>\n
Stem het beleid voor de complexiteit en rotatie van wachtwoorden af op het op feiten gebaseerde wachtwoordbeleid.<\/li>\n
Gebruik dezelfde berichten voor alle uitkomsten om er zeker van te zijn dat je registratie, credential recovery en API-trajecten zijn beveiligd tegen aanvallen op accounttelling.<\/li>\n<\/ul>\n\n
<\/div>\n<\/figure>\n
Fouten in software en gegevensintegriteit (nieuw)<\/h3>\n
Wat is het?<\/h4>\n
Fouten in de integriteit van software en gegevens zijn kwetsbaarheden die te maken hebben met code en infrastructuur die geen bescherming bieden tegen integriteitsschendingen.<\/p>\n
Voorbeelden:<\/h4>\n
\n
Wanneer plugins, bibliotheken, modules uit repositories, niet-vertrouwde bronnen of content delivery netwerken worden gebruikt in de applicatie. <\/li>\n
Wanneer er een onveilige pijplijn is, kan dit leiden tot de mogelijkheid van kwaadaardige code, systeemcompromittering of ongeautoriseerde toegang.<\/li>\n
Updates worden gedownload zonder voldoende integriteitsverificatie en worden toegepast op de eerder vertrouwde toepassing.<\/li>\n
…<\/li>\n<\/ul>\n
OWASP-aanbevelingen:<\/h4>\n
\n
Gebruik digitale handtekeningen of vergelijkbare mechanismen.<\/li>\n
Zorg ervoor dat afhankelijkheden en bibliotheken vertrouwde opslagplaatsen gebruiken.<\/li>\n
Controleer of componenten geen bekende kwetsbaarheden bevatten door ervoor te zorgen dat een tool voor de beveiliging van de softwareketen wordt gebruikt.<\/li>\n
Zorg voor een beoordelingsproces voor configuratie- en codewijzigingen om de kans op kwaadaardige code te minimaliseren.<\/li>\n
Zorg ervoor dat de pijplijn de juiste configuratie, scheiding en toegangscontrole heeft om de integriteit van de code te waarborgen.<\/li>\n<\/ul>\n\n
<\/div>\n<\/figure>\n
Beveiligingslogboek en falende bewaking<\/h3>\n
Wat is het?<\/h4>\n
Beveiligingslogging en -monitoring falen wanneer er onvoldoende logging, detectie en monitoring is. Zonder voldoende logging en monitoring kunnen inbreuken niet worden gedetecteerd. <\/p>\n
Voorbeelden:<\/h4>\n
\n
Gebeurtenissen die gecontroleerd kunnen worden, worden niet gelogd.<\/li>\n
Waarschuwingen en fouten genereren onduidelijke of geen logberichten.<\/li>\n
Logs van applicaties en API’s worden niet gecontroleerd.<\/li>\n
Logs worden alleen lokaal opgeslagen.<\/li>\n
Geen geschikte waarschuwingsdrempel en reactie-escalatieprocessen aanwezig<\/li>\n
Penetratietests en scans door dynamische tools voor het testen van applicatiebeveiliging triggeren geen waarschuwingen.<\/li>\n
De applicatie kan actieve aanvallen niet in real-time detecteren.<\/li>\n<\/ul>\n
OWASP-aanbevelingen:<\/h4>\n
\n
Zorg ervoor dat alle fouten bij toegangscontrole, aanmelden en invoervalidatie aan de serverkant kunnen worden gelogd met voldoende gebruikerscontext.<\/li>\n
Zorg ervoor dat logs worden gegenereerd in een formaat dat oplossingen voor logboekbeheer gemakkelijk kunnen gebruiken.<\/li>\n
Voorkom aanvallen op de logboek- of monitoringsystemen door de logboekgegevens correct te coderen.<\/li>\n
Voorkom geknoei of verwijdering door ervoor te zorgen dat transacties van hoge waarde een controlespoor met integriteitscontroles hebben.<\/li>\n
Zorg voor effectieve bewaking en waarschuwingen.<\/li>\n
Stel een respons- en herstelplan op voor incidenten.<\/li>\n<\/ul>\n\n
Een aanvaller kan een aangepast verzoek met de applicatie meesturen wanneer een webapplicatie een bron op afstand ophaalt zonder de door de gebruiker opgegeven URL te valideren.<\/p>\n
OWASP-aanbevelingen:<\/h4>\n
\n
De impact van SSRF verminderen. Functionaliteit voor toegang tot externe bronnen segmenteren in afzonderlijke netwerken. <\/li>\n
Dwing “standaard weigeren” firewallbeleid of regels voor netwerktoegangsbeheer af. Blokkeer alles behalve essentieel verkeer. <\/li>\n
Saniteer en valideer alle door de klant geleverde invoergegevens. Gebruik een positieve toestemmingslijst om het URL-schema, de poort en de bestemming af te dwingen. Stuur geen onbewerkte antwoorden naar cli\u00ebnten. Schakel HTTP-omleidingen uit. Wees bewust van de URL-consistentie. <\/li>\n
Implementeer geen andere beveiligingsrelevante diensten op front-systemen. <\/li>\n
Gebruik netwerkversleuteling op onafhankelijke systemen voor frontends met specifieke en beheerbare gebruikersgroepen.<\/li>\n<\/ul>\n
Ontdek Jimber Web Application Isolation<\/h2>\n
De Jimber Web Application Isolation beschermt je bedrijfsapplicaties met behulp van een container. Je gegevens worden ge\u00efnterpreteerd in de container en alleen de grafische visualisatie van die gegevens bereikt de eindgebruiker. Aanvallers kunnen alleen communiceren met de Jimber-laag, maar niet meer rechtstreeks met de API’s van de applicatie. Onze Web Application Isolation voldoet aan de hoogste eisen en garandeert de veiligheid van websites. De Jimber Web Application Isolation vermindert veel van de OWASP top tien 2021 kwetsbaarheden, doordat de API’s niet direct worden blootgesteld. Houd er rekening mee dat Jimber Web Application Isolation bovenop je huidige beveiligingsmaatregelen komt. Het kan niet alle mogelijke kwetsbaarheden tegenhouden. Het zal echter wel bestaande beveiligingsmaatregelen versterken en een sterke laag extra bescherming bieden. <\/p>\n\n
<\/div>\n<\/figure>\n
Gebroken toegangscontrole<\/h2>\n
Omdat applicatie-isolatie niet binnen de app zelf werkt, kunnen we verbroken toegangscontrole niet voorkomen. Schermopnames kunnen echter wel laten zien wie de toegangscontrole heeft gebruikt. <\/p>\n
Cryptografische fouten<\/h2>\n
Onze applicatie-isolatie kan niet beschermen tegen het lekken van gevoelige gegevens. Schermopname maakt het echter mogelijk om een spoor te achterhalen van de gegevens die door de gebruiker zijn benaderd. <\/p>\n
Injectie<\/h2>\n
Door te voorkomen dat de gebruiker direct toegang heeft tot API’s, zal onze web app isolatie de meeste injectiemogelijkheden voorkomen. Het zal ook buffer overflow aanvallen voorkomen. Frontend bescherming \/ invoercontrole is nu beveiliging. We kunnen XSS niet volledig voorkomen. We kunnen echter wel voorkomen dat XSS toegang krijgt tot externe bronnen, en zo het lekken van gegevens voorkomen. We kunnen ook afwijkingen in het gegevensverkeer detecteren. Verder scannen we URL’s op scripting. <\/p>\n
Verkeerde configuratie van beveiliging<\/h2>\n
Door niet toe te staan dat XML rechtstreeks naar de backend service wordt gestuurd, is XXE vrijwel onmogelijk. Het oppervlak voor beveiligingsfouten wordt veel kleiner, omdat optische beveiliging beveiliging beveiliging is.<\/p>\n
Kwetsbare en verouderde onderdelen<\/h2>\n
Veel kwetsbare en verouderde componenten worden misbruikt door API’s rechtstreeks te benaderen. Deze specifieke invalshoek om kwetsbare en verouderde componenten aan te vallen wordt onmogelijk met Jimber Web Application Isolation. <\/p>\n
Fouten bij identificatie en verificatie<\/h2>\n
Door oAuth of publieke\/private sleutelauthenticatie te implementeren op je SaaS-applicatie of intranet kunnen we authenticatie met de hoogst mogelijke beveiliging beschermen.<\/p>\n
![\"webtoepassingen](\"https:\/\/jimber.io\/wp-content\/uploads\/2025\/04\/owasp-web-applications-300x188.jpeg\" "\\"\\"")
<\/div>\n<\/figure>\n![\"kwetsbaarheden](\"https:\/\/jimber.io\/wp-content\/uploads\/2025\/04\/owasp-vulnerabilities-300x183.jpeg\" "\\"\\"")
<\/div>\n<\/figure>\n![\"cryptografische](\"https:\/\/jimber.io\/wp-content\/uploads\/2025\/04\/cryptographic-failures-300x143.jpeg\" "\\"\\"")
<\/div>\n<\/figure>\n![\"code-injectie\"](\"https:\/\/jimber.io\/wp-content\/uploads\/2025\/04\/code-injection-300x169.jpeg\" "\\"\\"")
<\/div>\n<\/figure>\n![\"veiligheidsfoutconfiguratie\"](\"https:\/\/jimber.io\/wp-content\/uploads\/2025\/04\/security-misconfiguration.jpeg\" "\\"\\"")
<\/div>\n<\/figure>\n![\"identificatie-](\"https:\/\/jimber.io\/wp-content\/uploads\/2025\/04\/identification-and-authentication-failures-300x225.jpeg\" "\\"\\"")
<\/div>\n<\/figure>\n![\"storingen](\"https:\/\/jimber.io\/wp-content\/uploads\/2025\/04\/software-and-data-integrity-failures-300x163.jpeg\" "\\"\\"")
<\/div>\n<\/figure>\n![\"storingen](\"https:\/\/jimber.io\/wp-content\/uploads\/2025\/04\/security-logging-and-monitoring-failures-300x162.jpeg\" "\\"\\"")
<\/div>\n<\/figure>\n![\"owasp](\"https:\/\/jimber.io\/wp-content\/uploads\/2025\/04\/owasp-website-security.jpeg\" "\\"\\"")
<\/div>\n<\/figure>\n