Wellicht heb je het voorbij zien komen op onze socials of wellicht op een ander platform. Wat is OWASP precies? Waar staat het voor? Wat doen ze? Wat is de top 10 van OWASP? In dit artikel leggen we je daar alles over uit.

Wat is OWASP?

OWASP stond voor Open Web Application Security Project. Dit is een internationale non-profitorganisatie die zich focust op computerbeveiliging. Het is ontstaan in 2001, maar in 2004 werd het officieel. Tegenwoordig heeft OWASP ongeveer 200 afdelingen in honderd landen en heet het Open Wordwide Application Security Project, aangezien het niet meer alleen om het web gaat.

Beschikbaar en toegankelijk

Het is één van de kernprincipes van OWASP om al hun materiaal vrij beschikbaar op hun website te hebben, waar het ook nog eens gemakkelijk toegankelijk is. Hiermee maken ze het mogelijk dat iedereen de beveiliging van hun eigen webapplicaties kan verbeteren. Hun bekendste project is de OWASP Top 10.

De OWASP Top 10

Zoals al gezegd is, is de OWASP Top 10 wellicht het bekendste project van de OWASP. Dit is, zoals de naam al deels zegt, een top 10 van de meest kritieke beveiligingsrisico’s en -problemen van webapplicaties. Deze top 10 wordt regelmatig bijgewerkt en verschillende versies van verschillende jaartallen worden ook in meerdere talen vertaald.

Hieronder is de top 10 van 2023 opgesomd. Let wel op, deze termen zijn in het Engels, maar we zullen ze in het Nederlands verder uitdiepen.

• Broken Access Control
  
• Cryptographic Failures
• Injection
• Insecure Design
• Security Misconfiguration
• Vulnerable and Outdated Components
• Identification and Authentication Failures
• Software and Data Integrity Failures
• Security Logging and Monitoring Failures
• Server-Side Request Forgery (SSRF)

Broken access control

Een toegangscontrole, ofwel access control, beperken gebruikers tot bronnen en functionaliteiten binnen een systeem. Zie dit als de controle bij de deur door een beveiliger bij een nachtclub. Ben je te jong? Dan kom je er niet in en kan je dus geen drankje bij de bar halen.

Wanneer een systeem er niet in slaagt om gebruikers passende beperkingen af te dwingen, spreken we van een toegangsbeheer die kapot of gebroken is. Het kan dus zo zijn dat je in bepaalde systemen dingen kunt inzien, die je helemaal niet zou mogen inzien en dat kan heel gevaarlijk zijn. Wellicht niet als jij het ziet, maar de data kan wel in verkeerde handen vallen.

Waarom kan dit gebeuren?

Er zijn verschillende redenen waarom dit kan gebeuren. Het kan simpelweg om een verkeerde configuratie gaan, onveilige sessiebeheer, IDOR en nog andere redenen.

Onveilige sessiebeheer

De sessie van een gebruiker wordt door vrijwel alle applicaties voor de gebruiker bijgehouden. Als je inlogt bij een nieuwssite naar keuze, kan je de nieuwsartikelen die je voor het laatst hebt bekeken, terugzien. Hetzelfde geldt voor een webwinkel met de producten. Bijna overal wordt er wel op een bepaalde manier een sessie bijgehouden, al is het maar om ervoor te zorgen dat je niet bij iedere pagina die je bezoekt, opnieuw moet inloggen.

Wanneer deze sessiebeheer onveilig is door fouten, kunnen aanvallers in staat zijn om jouw gebruikerssessie over te nemen en hierop voort te borduren. Dan kan je denken, ik heb niets te verbergen en wellicht is het voor een gewone gebruiker van een nieuwssite ook niet zo interessant. Echter, wanneer deze gebruiker een medewerker is van een financiële afdeling van een groot bedrijf en toegang heeft tot een heleboel gevoelige data, dan kan je je wellicht voorstellen dat deze sessie beter beschermd kan blijven.

IDOR

Nog zo’n afkorting, IDOR. IDOR staat voor Insecure Direct Object References, vrij vertaald: onveilige directe objectreferenties. Wat is dat dan nou weer? Even terug naar de nieuwssite. Een nieuwsartikel bestaat uit teksten, afbeeldingen, wellicht een video. Om, bijvoorbeeld, een afbeelding in te laden, wordt er een verwijzing of referentie gegeven naar waar de afbeelding te vinden is op de server van waar het nieuwsplatform zich bevindt. Deze wordt vervolgens opgehaald en getoond aan de gebruiker. Het kan wel eens voorkomen dat deze verwijzing stuk is en dat het naar een compleet verkeerde plek verwijst of gevoelige informatie bloot legt.

Een voorbeeld hiervan is, welke wij persoonlijk wel eens voorbij hebben zien komen, is dat een linkje in de tekst van een nieuwsartikel niet verwees naar het andere artikel in kwestie, maar dat het gegevens blootlegde van de auteur van het artikel, inclusief werk e-mail. Dat kan niet de bedoeling zijn.

Wat kunnen we hieraan doen?

Ontwikkelaars en systeembeheerders worden geacht het principe van de minste privileges te volgen. Dit houdt simpel gezegd in dat een gebruiker niet meer mag kunnen zien en doen, dan wat de gebruiker nodig heeft om zijn of haar taken uit te voeren. Als ik geen factuur aan hoef te maken, dan moet ik daar ook niet bij kunnen komen.

Daarnaast dient alle gebruikersinvoer te worden gevalideerd en gesaneerd (opruimen, verbeteren, zuiveren, voorkomen dat schadelijke invoer het systeem kan breken). Tevens moet er een autorisatie worden gedaan op elke aanvraag die de gebruiker doet (dit wordt, wanneer een gebruiker is ingelogd, vaak op de achtergrond gedaan met de gegevens uit de sessie).

Regelmatige beveiligingsaudits en codebeoordelingen zijn essentieel om toegangsbeheerproblemen te identificeren en op te lossen, en multi-factor authenticatie (ook wel 2FA) moet worden afgedwongen om ongeautoriseerde toegang te beperken.

Cryptographic Failures

Dit klinkt ontzettend ingewikkeld, maar valt eigenlijk wel mee. De cryptografie wordt gebruikt om zeer gevoelige gegevens te beschermen of versleutelen. Je hoort wellicht wel eens dat er “encryptie” op uw wachtwoorden staat. Jouw wachtwoord is dan op een bepaalde manier versleuteld, waardoor een aanvaller deze niet zomaar kan ontcijferen.

Waarom kan dit gebeuren?

Het kan zijn dat een aanvaller een versleutelde dataset kan decoderen. Hoe dan? Nou, het is mogelijk dat het algoritme dat wordt gebruikt voor het versleutelen, verzwakt is of al in het verleden is gekraakt. Een voorbeeld hiervan is de MD5 encryptie. Er zijn meerdere sites die gebruikt kunnen worden, die ook gewone (niet-technische) internetgebruikers kunnen vinden met behulp van Google, om teksten te encrypten en decrypten met MD5-hashes. Als deze tooltjes zo vrij beschikbaar zijn, dan weet een aanvaller hier natuurlijk ook van.

Andere voorbeelden waarbij de cryptografie faalt, zijn onder meer het onveilig opslaan van wachtwoorden, onvoldoende beveiliging van transportlagen of zwakke SSL/TLS-protocollen (Tip: lees vooral ook dit artikel dat wij hierover hebben geschreven).

Wat kunnen we hieraan doen?

Het is belangrijk dat er regelmatig veiligheidstests worden uitgevoerd op jouw webapplicatie(s). Hiermee kunnen zwakke plekken in het systeem, ook binnen de code zelf, worden geïdentificeerd en opgelost. Overweeg ook het gebruik van veilige cryptografische bibliotheken en houd de huidige ontwikkelingen met bekende bibliotheken in de gaten. Wellicht is er in de tussentijd al eentje gekraakt.

Uiteraard kunnen wij ons heel goed voorstellen dat je geen kaas hebt gegeten van welke crypografische bibliotheek je systeem gebruikt of hoe je dit moet verbeteren. Onze specialisten staan daarom altijd voor je klaar om je vragen te beantwoorden. Als je vragen hebt, neem dan gerust contact op via onze klantenservice met het mailadres [email protected]

Injection

Hetgeen wat je je voor moet stellen bij injection, ofwel injectie, lijkt eigenlijk veel op de term die we kennen bij het injecteren van bijvoorbeeld een vaccin via een spuit. Wanneer wij als gebruiker, bijvoorbeeld, ergens inloggen, voeren wij onze gebruikersnaam (of wellicht e-mail) en wachtwoord in in de daarvoor bestemde invoervelden. Dit doen we ook, weliswaar met andere gegevens, wanneer we een bestelling ergens plaatsen online en zo zijn er nog talloze voorbeelden.

Wanneer een kwaadwillende doormiddel van injectie een aanval uitvoert, zal deze persoon (of het gebeurt automatisch via een scriptje) een stukje code plaatsen binnen deze invoervelden en deze meesturen naar de server. Wanneer de server onvoldoende beschermd is hiertegen, kunnen daar problemen ontstaan. 

De meest bekende voorbeelden hiervan zijn: een SQL-injectie, waarbij een database commando wordt doorgegeven aan de server en waardoor de aanvaller, bijvoorbeeld, de database kan verwijderen, wanneer deze onvoldoende beschermd is, of cross-site-scripting (XSS). Bij XSS worden er aanvallen gepleegd via geïnfecteerde webpagina's, die onder andere kunnen leiden tot het kapen van de sessie (zoals hierboven ook is besproken), cookie-diefstal of andere aanvallen op gebruikers.

Waarom kan dit gebeuren?

Wanneer de bouwers van het systeem onvoldoende op de hoogte zijn van deze technieken, kunnen ze onvoldoende beveiliging inbouwen in de invoervelden van hun webapplicatie. Het ligt er ook maar net aan welk systeem je gebruikt. Sommige frameworks (bestaande systemen waar een developer op voort kan bouwen) hebben al de nodige validatie hiertegen ingebouwd, maar dat is niet altijd en overal het geval.

Wat kunnen we hieraan doen?

Net als hierboven is benoemd, is het belangrijk dat er regelmatig veiligheidstests worden uitgevoerd op jouw webapplicatie(s). Hiermee kunnen zwakke plekken in het systeem, ook binnen de code zelf, worden geïdentificeerd en opgelost. 

Wil je meer weten over hoe jouw applicatie beschermd is tegen deze injecties? Onze specialisten staan altijd voor je klaar om je vragen te beantwoorden en kunnen ook in de code meekijken. Wij hebben namelijk de technische vakkennis in huis om hier met een kritische blik naar te kijken. Als je vragen hebt, neem dan gerust contact op via onze klantenservice met het mailadres [email protected]

Insecure Design

De ontwerpfase van een (web)applicatie is heel belangrijk. Dit is namelijk de fase waarin er bij voorbaat al nagedacht moet worden over eventuele problemen en/of kwetsbaarheden van het systeem. Het komt helaas geregeld voor dat hier onvoldoende tijd en/of budget aan besteed wordt, waardoor potentiële gevoeligheden in een systeem niet (op tijd) worden belicht en kunnen worden gebruikt door kwaadwillenden.

Waarom kan dit gebeuren?

Hier kunnen verschillende redenen voor zijn. Tijdgebrek om hier goed over na te denken, maar ook een team die onvoldoende op de hoogte is van verschillende kwetsbaarheden. Je kunt hier eigenlijk niet één specifieke oorzaak aan hangen, want ook een combinatie van verschillende pijnpunten is mogelijk.

Wat kunnen we hieraan doen?

Het is belangrijk dat er de tijd genomen wordt om een (web)applicatie te ontwerpen en dat de betrokkenen op de hoogte zijn van, in ieder geval, de meest bekende aanvalsmethoden. Daarnaast is het van belang dat de betrokkenen zich blijven oriënteren op eventuele nieuwe aanvalsmethoden en deze in het team delen, zodat de (web)applicatie er uiteindelijk beter van wordt.

Wij van Janssen Websolutions kunnen jou helpen bij de ontwerpfase van jouw project. Al onze technische specialisten zijn op de hoogte van verschillende aanvalsmethoden en modelleertechnieken om deze kwetsbaarheden in kaart te brengen. Deze kunnen wij ook overdragen aan jouw development team of zelf inbouwen. Wij zijn van alle markten thuis! Als je vragen hebt, neem dan gerust contact op via onze klantenservice met het mailadres [email protected]

Security Misconfiguration

In de OWASP Top 10 van 2017 heette dit XML External Entities ofwel XEE. Dit klinkt heel erg omslachtig en moeilijk, maar komt eigenlijk neer op het volgende: fouten in de configuratie van de beveiliging die kwetsbaarheden blootleggen.

Waarom kan dit gebeuren?

Er zijn verschillende configuratiefouten mogelijk, welke ieder ook verschillende kwetsbaarheden hebben. Een aantal veelvoorkomende issues zijn:

• Bekende kwetsbaarheden die niet gepatched/opgelost zijn;
• Het gebruiken van de standaardconfiguratie van het systeem;
• Onbeschermde mappen en bestanden;
• Onnodig gebruik van bepaalde services.

Wat kunnen we hieraan doen?

Zoals ook al eerder is benoemd, heeft ieder issue een eigen manier om dit op te lossen. Een veelvoorkomende fout die webmasters maken, is het aanhouden van de standaardconfiguratie van een systeem. Echter, ook kwaadwillende personen kennen deze standaardconfiguraties en kunnen (vaak geautomatiseerde) aanvallen uitvoeren om deze bekende kwetsbaarheden in het systeem te gebruiken voor hun uiteindelijke doel.

Een oplossing hiervoor is, hoe logisch het ook klinkt (en toch wordt het vaak vergeten), af te wijken van de standaardconfiguratie. Het risico kan je wellicht niet volledig wegwerken, maar je kunt het aanvallers een stuk moeilijker maken, waardoor ze eerder voor een slachtoffer zullen kiezen die hier minder energie in heeft gestoken.

Als je hier behoefte aan hebt, kunnen wij kritisch naar jouw systemen kijken. Wij zijn op de hoogte van bekende standaardconfiguraties en kwetsbaarheden binnen systemen en kunnen je passend advies geven over de veiligheid van jouw systeem. Neem gerust contact op via onze klantenservice met het mailadres [email protected]

Vulnerable and Outdated Components

Ofwel gevoelige en niet up-to-date componenten. Ieder systeem gebruikt wel iets van een framework (zoals we al eerder hebben besproken) of een bestaand systeem. Is jouw website een WordPress website of heb je een systeem dat ontworpen en gemaakt is door een partij, dan heb jij hier ook geheid mee te maken.

Waarom kan dit gebeuren?

Wanneer we systemen, plugins, frameworks, bibliotheken of andere dingen van een andere partij gebruiken, kan het zijn dat deze al een geruime tijd niet meer een update heeft gehad. Wellicht wordt het systeem niet eens meer onderhouden. Hierdoor kunnen allerlei beveiligingsrisico's ontstaan.

Aanvallers zijn continu op zoek naar kwetsbaarheden in systemen om deze te gebruiken en deze worden ook gedeeld met andere aanvallers op daarvoor bestemde platformen. Sommige aanvallers doen dit voor het goede doel, ook wel ethische hackers genoemd. Zij zullen de risico's doorgeven aan de desbetreffende partij, zodat het opgelost kan worden.

Echter, niet iedereen valt onder deze groep hackers en er zijn meer dan genoeg aanvallers die een minder positief doel voor ogen hebben. Ja, positief voor zichzelf, maar niet voor jou als slachtoffer.

Wat kunnen we hieraan doen?

Een simpel antwoord is: zorg ervoor dat alle systemen die je gebruikt up-to-date zijn. Houd ook een inventarisatie bij van welke systemen, frameworks of wat dan ook je gebruikt. Hierdoor weet je ook waar je moet kijken voor updates.

Wil je dat er eens mee wordt gekeken naar jouw systemen? Dat kan! Onze technische specialisten hebben kennis van veelgebruikte systemen onder systeemontwikkelaars en gebruikers en kunnen met je meekijken, een inventarisatie maken van de door jou gebruikte systemen en eventueel adviseren en helpen om jouw systeem up-to-date en veilig te laten draaien. Neem gerust contact op via onze klantenservice met het mailadres [email protected] voor meer informatie.

Identification and Authentication Failures

Dit zijn fouten in de authenticatie van gebruikers en hun identiteitsbeheer, ofwel, iemand kan zich voordoen als iemand anders en daarbij gegevens vergaren die helemaal niet voor deze daadwerkelijke persoon zijn. Denk maar eens terug aan het voorbeeld van de persoon van de financiële afdeling van een groot bedrijf. Iemand kan als deze persoon inloggen en, wellicht, facturen bekijken, terwijl deze niet voor de ogen van de aanvaller bedoeld zijn.

Waarom kan dit gebeuren?

Dit kan zowel te wijten zijn aan de gebruiker zelf als dat van de systeemontwikkelaars. Een gebruiker kan een simpel, kort en makkelijk te onthouden wachtwoord gekozen hebben. Dit wachtwoord kan vervolgens ook gemakkelijk gekraakt worden en dan zit je al met de gebakken peren.

Aan de andere kant kunnen de ontwikkelaars onvoldoende gedaan hebben om ervoor te zorgen dat er een veilig, sterk wachtwoord gemaakt wordt. Je hebt het waarschijnlijk wel eens voorbij zien komen:  je wilt een wachtwoord aanmaken, maar dit wachtwoord moet minstens x tekens bevatten, hoofdletters, cijfers en een bijzonder teken, zoals #. Er is dus wederom niet één oorzaak aan te wijzen.

Wat kunnen we hieraan doen?

Voor jou als gebruiker is het van belang om geen simpele wachtwoorden te gebruiken, geen wachtwoorden te herhalen en deze veilig op te slaan. Dit helpt ook om jouw website beter te beveiligen tegen brute force attacks. Daar kun je in dit artikel meer over lezen. Tevens kun je gebruik maken van 2FA om jouw account beter te beschermen.

Als ontwikkelaar is het van belang om je gebruikers af te dwingen sterke wachtwoorden te maken en het aantal inlogpogingen te beperken. Denk ook aan het implementeren van een 2FA-mogelijkheid. 

Wil je, als gebruiker of ontwikkelaar, hier hulp bij krijgen. Geen punt, onze technische specialisten staan voor je klaar om met je mee te kijken. Neem gerust contact op via onze klantenservice met het mailadres [email protected] voor meer informatie.

Software and Data Integrity Failures

Dit zijn fouten die vooral ontstaan in de ontwikkelfase van een project. Terwijl de ontwikkelaars bezig zijn met het ontwikkelen van een systeem, kunnen ze erachter komen dat ze bepaalde functionaliteiten, bibliotheken of andere bronnen nodig hebben om te gebruiken. Het is natuurlijk superhandig als jij niet zelf het wiel opnieuw hoeft uit te vinden! Tegenwoordig kunnen deze bronnen heel snel en gemakkelijk worden ingeladen in een project.

Waarom kan dit gebeuren?

Dat het zo makkelijk is om externe bronnen binnen te halen, zorgt het ook dat het vaak wordt vergeten om de integriteit van deze specifieke bron te controleren en dat eventuele kwetsbaarheden niet worden opgemerkt en dus ook het project binnensluipen.

Wat kunnen we hieraan doen?

Het is van belang dat er een inventarisatie is van welke bronnen er in het systeem gebruik worden gemaakt. Zijn deze veilig? Worden deze nog regelmatig bijgewerkt of zijn ze ondertussen al heel lang niet meer bijgewerkt? Als er een duidelijke inventarisatie is, kan de eventuele dreiging beter gemonitord worden.

Security Logging and Monitoring Failures

Het is belangrijk dat er in een systeem logging wordt ingebouwd. Dit houdt in, dat incidenten worden opgeslagen en door systeembeheerders kunnen worden nageslagen om te kijken wat er op een bepaald moment is gebeurd. Misschien ken je het wel: "Het systeem doet het niet!" Als ontwikkelaar of beheerder van het systeem kan je daar vrij weinig mee. Wat doet het niet? Wat probeerde je te doen? Wanneer is het gebeurd? Dit zijn vragen die jij als gebruiker kan beantwoorden om onze zoektocht een beetje makkelijker te maken.

Daarna kunnen we de logs erbij pakken. Wat is er precies gebeurd en welke foutmelding heeft het systeem gegeven? Als wij deze informatie hebben, kunnen we eventuele problemen oplossen of je te begeleiden.

Waarom kan dit gebeuren?

Problemen kunnen ontstaan als een systeem onvoldoende logging heeft ingebouwd. Hierdoor wordt het heel ingewikkeld voor ontwikkelaars om te kijken wat er precies is gebeurd, om het probleem na te bootsen en eventueel op te lossen.

Op deze manier worden incidenten gemist en kunnen kwetsbaarheden blijven bestaan, zonder dat deze worden opgemerkt. Het is daarom belangrijk dat er goede logging aanwezig is.

Wat kunnen we hieraan doen?

Sowieso kunnen de ontwikkelaars van je systeem logging inbouwen. Alle inlogpogingen (inclusief de mislukkingen) dienen in ieder geval te worden gelogd en alle logs dienen in een back-up worden opgeslagen, voor het geval er een probleem op de server optreedt.

De logs die worden opgeslagen moeten zo nauwkeurig en met zo veel mogelijk details worden uitgewerkt. Daarnaast moeten er waarschuwingen worden gegeven bij specifieke logs die kwetsbaarheden van het systeem kunnen aangeven. Ze moeten daarom ook beschermd worden tegen manipulatie en er moeten kopieën van worden opgeslagen.

Server-Side Request Forgery (SSRF)

Weer zo'n moeilijk begrip. Kort door de bocht is dit een aanval op de serversite, die leidt tot het vrijgeven van gevoelige informatie van wat er op de achtergrond gebeurd, die eigenlijk niet beschikbaar is op de voorgrond (dus voor wat jij kunt zien). Dit zijn heel kritieke aanvallen met ernstige gevolgen.

Waarom kan dit gebeuren?

Wederom is hier niet één oorzaak aan te wijzen en jij als gebruiker zal hier niet zo veel mee kunnen. Een aanvaller kan via invoervelden in je systeem bepaalde parameters of invoervelden manipuleren om op deze manier de server te misleiden en verzoeken naar willekeurige URL's te sturen, zonder dat jij als gebruiker hiervan op de hoogte bent.

Ze zullen dit doen om toegang te krijgen tot gevoelige gegevens, om te kunnen communiceren met interne bronnen of bepaalde handelingen namens de server uit te voeren, met alle gevolgen van dien.

Wat kunnen we hieraan doen?

Om kwetsbaarheden te voorkomen, is het van belang dat de ontwikkelaars een aantal best practices volgen:

• Het valideren en opschonen van de data uit invoervelden;
• Een whitelist implementeren;
• Het implementeren van firewallregels;
• Veilige API's gebruiken;
• Rechten van de server beperken, zodat het niet meer kan dan nodig.

Uiteraard, als gebruiker is het moeilijk om hier enige invloeden op te hebben, maar je kunt wel navraag doen bij de ontwikkelaars.

Ook wij kunnen je helpen om jouw (web)applicatie te beveiligen tegen SSRF-aanvallen. Onze specialisten staan altijd voor je klaar om je vragen te beantwoorden en kunnen ook in de code meekijken. Wij hebben namelijk de technische vakkennis in huis om hier met een kritische blik naar te kijken. Als je vragen hebt, neem dan gerust contact op via onze klantenservice met het mailadres [email protected]

Heb je aanvullende vragen over dit onderwerp?

Dat kunnen we ons heel goed voorstellen! Neem contact op met onze klantenservice via [email protected], via whatsapp of telefonisch op +31 (0)658853730.